为什么项目估算偏差如此之大？

10顶
1踩

2013-09-16 17:11 by 副主编 wangguo 评论(21) 有14012人浏览

估算开发敏捷

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

在软件开发过程中，估算是一个非常重要的环节，对于项目计划、进度控制等都具有重要的意义。但是估算也是一个比较难的“技术活”，因为是“估”，所以往往会存在一些偏差，而这些偏差对于一个项目来说，有时可能会导致多花费一些不必要的金钱，还有可能影响公司的声誉和员工的积极性。

而哪些因素会导致估算偏差呢？开发者Alex E. Fish给出了以下提示。

没有充分考虑需求

如果你没有充分考虑到所有的需求，那么估算一个任务将花费多长时间是毫无意义的。更多的需求意味着更复杂的实现，这当然也需要更多的时间来完成。

估算了测试时间，但没有估算修复时间

估算应该考虑到所有的测试时间以及修复bug的时间。单元测试、BDD（Behavior Driven Development，行为驱动开发）测试、测试人员进行手工测试，这都是需要花费时间的。并且，开发人员查找和修复bug同样也需要时间。更复杂的任务有可能会包含更多的bug，这意味着需要花费更多的时间来跟踪和修复它们。

假定开发者每天8小时都在编码

就算开发者每天上班8个小时（不加班情况下），但是这不代表8个小时都在编码，其他一些琐事往往会令生产率大大降低，比如会议、电子邮件、同事之间的IM消息、询问问题等。开发者从工作中断恢复到工作状态，往往也需要15分钟时间。有些时候，开发者一天只有2个小时的时间用于编码。

按天估算，没有按小时估算

所有的任务都应该被分解成2~16小时的块任务。这是一个很好的规则，可以让你独立地看待每个任务，并能够把所有因素都考虑在内，减少估算偏差的机会。

让非项目人员来估算

应该由参与编写软件的开发者们来进行估算。他们可以根据自身经验、开发速度对项目有一个更准确的把握。这也避免了由于A设置的进度过快，而导致B被追究责任。

忘记过去

George Santayana曾说：“忘记过去的人注定要重蹈覆辙。”如果这不是你的第一个项目，那么最好回头看看过去的项目。查找你以前曾参与过的同一领域中的类似规模/要求的项目，并将它作为一个参考点。

忽略停工期

如果项目是一个长期项目，或者开发者在夏季需要有一个假期，那么在估算时也应该考虑在内。必要时，考虑设置一个适当的缓冲期。

过于确切

将项目估算在一个确切的期限内或小时数内是不现实的，这也是无法实现的，最好的办法是估算一个范围，包括最好的情况下、最有可能的情况下、最坏的情况下的范围。

总结：要认真看待估算

估算是一个应该认真对待的工作，也是每一个开发者必备的技能。你和你的同事都应该掌握并进行实践。一个好的估算的做法是人人参与。

估计没有人喜欢估算，我个人认为这是软件开发工作中最糟糕的部分。而估算也从来都不会真正可靠或者完全准确，但还是希望上文这些内容可以为你带来一些帮助。

英文原文：Poor developer estimations AKA Guesstimation

分享到：

10
顶

1
踩

评论共 21 条请登录后发表评论

21 楼 damoqiongqiu 2013-09-22 11:11

phantomxf 写道

人家总结这些目的只是给大家在做实现的项目中一点启发而已，也没让你们照做。。。。。。。。瞧下面评论喷的那样，程序员屌丝的语气，真就一点前途都没有！

土豪你好，我们做朋友吧，求前途

20 楼 phantomxf 2013-09-22 10:43

19 楼 damoqiongqiu 2013-09-22 09:30

毫无意义的一堆正确的屁话
可能老外的环境和我朝不同
原谅你了

18 楼 tuti 2013-09-21 10:01

传统的项目管理方式
1. 建立WBS
2. 估算协商每个任务的计划时间
3. 制定MileStone
4. 要求每个人都要遵守自己任务的DeadLine，不准延期。
5. 谁延期就处罚谁

那么这个项目必然延迟

17 楼 rbible 2013-09-19 22:51

流水总结...

16 楼 fnet 2013-09-19 10:54

说废话的家伙是否也该像这篇文章总结一下了

15 楼 geli_hero 2013-09-18 16:59

感觉就是废话！

14 楼 21jhf 2013-09-18 16:33

基本上加上buffer时间就行了

13 楼 lucky2touch 2013-09-18 09:24

变化总是比计划快，估算也要随时调整，调整多了就疲乏了

12 楼 hhb19900618 2013-09-18 08:50

写的实实在在

11 楼 Eric_CY 2013-09-17 23:17

在国内,这些理论我觉得真是没什么用,假设一个项目在估算时,有10%的未知或无法掌控的风险,但在真正项目实施的过程中,因客户需求频繁变更、或客户方部门执行力较差,响应过慢,导致开发和测试进度延期等情况,逐渐会发现这些不可控因素,至少会占用整个团队30%以上的工作量,甚至更高,这样的话项目前期的估算就纯属扯淡了,项目早就已经失控了。

10 楼 langzhe 2013-09-17 18:20

从我个人总结来说，主要还是需求问题。需求频繁的变化，时间根本无法估计。
其实是沟通问题（积极沟通和消极沟通），需求变化没有及时传达出去或没有及时去接收。时间拖的越久越浪费时间，
最后就是责任心问题了，一个有责任心的会时不时琢磨那里不合理。否则就是些做完就不怎么管的，这样不出问题才怪呢。

9 楼魔力猫咪 2013-09-17 14:06

评论里面怎么还是有这么多人把估算和承诺等同起来。估算只能说这么多时间可能性比较高，那么多时间可能性比较低，现代建筑施工的估算也有超出好几倍的，更不要说软件了。估算是为了控制项目风险，不是说我估算了多少小时就一定能多少小时完成。

8 楼陈修恒 2013-09-17 13:45

我们估算一般是按功能点做的，估算基准是 3 人天。 2-16 小时太少了，喝杯茶就落后了

7 楼 witcheryne 2013-09-17 10:51

newboy2004 写道

这种东西都太泛泛了，没有一定的规律可循，完全靠经验来评估。

项目估算很难总结，总结出来也会让人觉得泛泛。
项目估算经验基本都是被坑出来的，一个很2b的做法，研发人员估算的时间 * 3 (至少)

6 楼 newboy2004 2013-09-17 09:37

这种东西都太泛泛了，没有一定的规律可循，完全靠经验来评估。

5 楼 hbin8668 2013-09-17 08:42

估算还是必要的，但估算的时候的确得留出缓冲期，用于合理的需求变更，难点问题的解决等，但个人时间规则也是相当相当重要的。

4 楼 pasband 2013-09-17 03:37

楼下说的都没错，但不等于可以不做估算，有度量标准是为了尽早发现项目进度问题，
另外估算参照的标准一定是这个团队的历史数据，而不能只根据个人的经验或臆断

3 楼 lobo12 2013-09-16 19:58

国内软件企业领导主义太强，动不动就改一下需求，估了也是没用的

2 楼 kanme818 2013-09-16 18:45

ansjsun 写道

真实情况是2-16个小时内的估算也是很难的.很多具有调研性的东西时间都是不定的..如果估算可以随时无范围的修改.也就没有了估算的意义...总结:估算就是扯淡..

估算在国内绝对是扯淡，你想按实际再给点buffer，结果领导说怎么这么多。于是你只能去掉buffer，结果开发的时候发生各种小问题导致超出估算。
老外倒是还好，你估多少他就相信你，就给你这么多，因为他觉得你既然估了，就能做好。

发表评论

您还没有登录,请您登录后再发表评论

10顶1踩