猫读《软件估算》三

08-01-31 wlmouse
  猫咪继续发自己的感想。《Grails权威指南》还没有送到。继续读《软件估算》。

  喵。大家有做我上一篇文章的测试题吗?我会在本篇的最后公布答案,以免有人通过预览之类的功能作弊。当然,也许有人已经通过搜索引擎找到了正确答案和自己的对比。那么你得了多少分?

  你的得分很低的话,那么你就要好好想想为什么会这样了。人们为什么会低估呢?低估的压力来自于哪里?是否是因为怕因为自己估值估的太宽了让别人笑话?是否是自己的荣誉感、自尊心作祟?因为你会想,太阳表面温度?我不知道。不过把从宇宙绝对零度到1亿度都估算进去,总能包上。呵呵,这当然正确。但是你会觉得自己会成为别人的笑柄。书上这里给出一个忠告,如果“感觉到有进行过窄估算的压力,请确认其不是来自自身”。

  进行估算的时候,是高估好还是低估好?

  首先是高估。当然,不是漫天要价。比如把一个100W的项目要1亿的资金。而是说一个项目如果估算可能在2到3个月完成,那么我们应该取那个值比较好呢?3个月完成的可能性比较大,但是时间长。2个月完成的可能性比较小,但是如果按时完成,成本比价低(少花一个月薪水)。反对高估的理由是所谓的“帕金森法则”,用咱们的话来说就是磨洋工。1天干的活给了2天时间。所以程序员会在第一天把活干完后去玩《魔兽》、看动画片。因为给的指标是2天,到2天上我给出了产品,所以你管我怎么用时间(对管理者来说浪费一天)。还有就是“学生综合征”,程序员会在开始的时候浪费时间,最后的时候赶工。其实我们小时候放寒暑假就经常这么干。刚放假的时候尽情的玩,反正时间很长,假期作业晚点写也没关系。结果到快开学的时候发现,一点也没有动。于是点灯熬油的彻夜奋战赶作业。

  所以,很多客户和管理者都觉得程序员给出的估算是一个超乐观估算。如果要求1年的时间的话,最快6个月就可以。而且很多人喜欢看到别人每天紧张地忙碌,美其名曰“有紧迫感”。所以更加压缩时间。1年的话我压到6个月,最多再多给2个月。虽然我不相信他们能在6个月内完工,但是8个月应该够了。反正最后1年无论如何也完了。而且我还可以以此打击他们,比如要求赔偿(虽然我实际上不在乎1年开发完,但是给你们的是6-8个月,所以不能要那么多钱)、要求增加新功能(我已经给了足够宽的时间,所以要多干一些)。

  然后是低估。也就是说按照估值的低点做计划。2-3个月的估2个月,甚至1个半月。反对低估的一般情况下主要是程序员。因为人微言轻,所以很难反抗成功。反对的理由是太过乐观的假设会造成计划的有效性降低、赶工造成无法做出正常的系统。

  估算的偏差理论上最好的是正负10%,实际上能有一倍的误差就烧高香了。统计学显示,程序员的估值一般比实际低20%到30%。也就是说程序员提出的估算实际上多半都已经是估算的低点了(实际工作量可能比估算的最高点还要高很多),那么这么大的实际和计划偏差,计划也就是让客户养养眼的废纸而已。还有,低估会引发大量问题,项目团队为了赶进度无休止的加班,造成大量错误代码,而为了修正这些错误,要花费大量的时间。为了到时候能够有东西拿出来,什么分析、设计的统统一边站。单元测试、持续集成?每天连吃饭到睡觉都不够6小时了,写代码都来不及,谁还有工夫管这些。怎么写快怎么写。只要能跑起来就成,什么BUG、设计不合理、性能低下以后再说。到时候指不定是哪个倒霉蛋接手呢,反正多半不是我(已经决定项目完成后就跳,什么?你说跑不掉?这么多加班、没加班费。只要有证据,去劳动部门一告一个准,敢不放我走!)。最后的结果就是留给客户一个只能扔到垃圾箱的“半成品”。

  猫咪就当过那个倒霉蛋。维护过一段时间一个恶心的产品。这是一个从需求到完成只有2个月的中型项目。所有成员没日没夜,不眠不休制造出来的垃圾。Java的分层设计什么的根本没有。设计上到处都是BUG。数据库表乱七八糟,如果不是因为数据库第一范式违反了表就建不起来了,他们估计连第一范式也不打算遵守了。冗余字段到处都是,有时候居然一表多用。比如把新闻的分类和考试试题的分类用一张表存,班级通讯录不是去用户表读用户信息,而是单建了一张。程序里也是,重复混乱的代码到处都是。表现层的Action大家都知道,应该是一个功能一个Action(或Action中的一个方法)。他们倒好,一个Action中塞3、4个差不多的业务逻辑,而且用丑陋的if...else判断。每个分支里面的代码都是重复粘贴的。还好我那段时间没什么赶进度的事情,不然非要了猫咪的老命。

  最佳的项目结果来自最佳估算。如果估算过高,那么就会出现“帕金森法则”和“学生综合症”,过低则出现“项目计划误差”、大量缺陷和使用不成熟产品造成的损失。所以,作者提出的结论是,无论如何都不要低估。宁可高估也不要低估。因为即使高估,造成的损失是可以预期的。最多就是把预算花光、程序员比较清闲而已。这些问题可以通过积极的管理和项目控制解决。但是如果低估就不成了,大量的错误和返工、程序员的抱怨、法律风险(因项目延期的客户索赔、程序员因为加班过多的法律诉讼和罢工)等等都会找上门。你无法预测低估到底会造成多大损失。

  喵。猫咪多么希望客户和管理者能多高估而不要低估。可惜国内的客户最爱低估了。猫咪参与过一个项目,还好只是调研需求。这个项目,客户自己先进行了一年多的调研(真不知道为什么用了这么长时间)。然后是几个月的招标。最后是不到3个月的开发。领导下令,必须按期完成,不许讲条件。还好猫咪只是借调过去敷衍客户,不然不死也这身猫皮也保不住了(是谓“不死脱层皮”)。之所以是去敷衍客户,其实是因为招标结束后才开始组建开发团队。但是销售的对客户大包大揽,客户以为团队已经开始工作了,所以只好把猫咪借调过去挡枪。客户对猫咪说,不许说3个月不够。你们应该招标完成前就开始工作的(昏死,合同还八字没一撇就干活?那要是没中标不是白干了!)。

今天就说到这里了,猫咪继续看书。

  下面是上一篇测试题的答案:

1.10,000华氏度/6,000摄氏度

2.北纬31

3.17,139,000平方英里/44,390,000平方公里

4.公元前356年

5.7,199亿美元

6.5,500立方英里、23,000立方公里,24*10(22)立方英尺、6.8×10(20)立方米、

7.18.35亿美元

8.135,663公里

9.2千2百万册

10.170吨

文章引用自:

http://blog.sina.com.cn/wlmouse

[该贴被wlmouse于2008-01-31 14:03修改过]

猜你喜欢