猫读《软件估算》一

　　最近猫咪在学习Grails。但是从网上找到的《Grails入门指南》看着太累。特别是做测试的时候，要一边看书一边干活，来回切换桌面实在麻烦。就去卓越网（现在已经是亚马逊中国了）订购《Grails权威指南》。在买书的时候，发现了《软件估算-“黑匣子”揭秘》一书。是讲如何成功进行软件估算的。感觉比较新鲜，而且自己以往在开发中对应该如何估算工作量也一直没有头绪（基本上是想当然一个可能的大概值，但是基本上没有任何数据去支持这个大概值），看了一下价格，标价49，打折后36.7。觉得价格不贵，就一同买下打算闲着没事的时候看看。28号下单，卓越网给出的是《软件估算》约31日送达，《Grails权威指南》倒要2月4日送到。昏死。结果今天早上《软件估算》就来了。得了，反正《Grails权威指南》还要好几天，猫咪就先看《软件估算》好了。
　　估算，定义是：对项目将持续多长时间或者将花费多少成本的预测。
　　我们一般做项目的都是某某领导给出一个时间点，然后大家针对这个时间点开始干活。无论遇到什么问题，都要在这个点之前完成。如果不能在正常工作时间完成，那么就要不断加班加点。结果就是对老板的怨气，因为这代表每天要回去得更晚，星期六、日不能在家好好打游戏、甚至节假日也要干活。同时国内很多公司对加班费不能按时按量给付和加班时间超过正常承受能力，更是让大家的怨气冲天。消极怠工者有之、边骂边干者有之，还有到劳动部门举报的。呵呵，猫咪也是深受这种荼毒。
　　猫咪以前基本上没有写过读书心得笔记之类的东西，这里也就是一些感想，可能很混乱，大家多多包涵。
　　一般情况下，我们开发一个项目的时候，客户提出一些已知的需求。然后我们根据这些需求得到一个大概的时间。然后我们会和客户就这个时间进度进行扯皮。我说需要3个月，然后客户告诉我只能2个月。然后两边开始扯皮，互相要求对方答应自己的条件。不过国内多是买方市场。唉，谁叫中国人多呢。客户经常用“你不做有人做”的理由压缩工期、压缩报价。你呢，多半在压力下屈服，先答应下来，以拿到合同。开工后再和客户沟通，以图把压缩的时间要回来。如果要不回来，就用加班压榨程序员的办法赶时间。什么软件工程、结构分层、领域建模、足够的测试等等都尽可能不要，只要到时候能跑起来就可以。
　　客户觉得项目到时候不能用，就告诉他以这个时间就能做到这个程度，而且有证据。看，项目组的程序员已经因不堪重负而病倒若干、住院若干、辞职若干。甚至于殉职若干。而且客户到了这个地步，也不可能停下来。已经投入了这么多了，不做下去就全费了，所以只能先凑合着用，然后再改进。但是项目组又有了新项目，去加班加点干新项目去了。继续完善维护这个项目的人员大幅度缩水，而且因为开发时赶工期，没分析、没设计，代码混乱，结构乱七八糟，几乎无法继续，最后下一版只能重新开发。唯一获得的就是第二次的需求比第一次要明确得多（毕竟用过了一个半成品）。但是，如果第一次积累了大量的数据，而这些数据的结构因为当初赶工设计得不合理，结果新项目因为要保留旧数据，不得不继承原来的不合理结构。
　　说得有点跑题。但是这就是猫咪对现在国内开发的现状的看法。猫咪希望能通过读《软件估算》，学到如何计算有大量不确定因素的情况下能够合理估算需要花费的时间和资源。以免自己给出一个自己无法完成的承诺。猫咪希望能够在上面给出一个目标的时候，能够估算出一个合理的工作量。如果两者偏离太大，那么可以和对方讨价还价。就好像买办公用品，桌子、椅子、电脑、笔、纸张或者打印机什么的，需要很多。但是预算就那么多，大家就坐下来，把那些不太重要的先去掉。以在一个可以接受的预算买到最需要的东西。如果你能拿出一个有足够科学支持的理由，就很可能说服客户，修改目标。比如在时间点不能变更的时候，是否去掉一些不太重要的功能。猫咪觉得只要你能提出足够的，有依据的理由，客户还是很容易说服的。客户希望的是应用能够给他带来效益，赶工出来的半成品除了让双方承受损失之外，没有任何价值。当然，不排除遇到蛮不讲理的家伙，猫咪觉得与其到时候完不成被开掉，不如现在就另谋高就。毕竟身体是自己的，如果答应了对方的要求就是做出了承诺，多累也得去完成。结果到时候仍然完不成，钱当然也没有（没有人会为废品买单），身体也完了。
　　软件估算，首先就要把估算与目标、承诺区分开。不要随便用自己直觉估算出来的东西作为承诺。同时也要明白对方要的是对目标的估算还是对目标的承诺。还有就是估算、目标和承诺的沟通，也就是明确对方要的到底是完成这个目标的估算还是完成目标的计划。比如上面要求为3个月后的展示会完成一个软件，问你大概需要多少时间。但是你却估出了5个月的工作量。不好的沟通就是双方都没有明确对方要什么，在什么时候完成上面扯皮。其实展会并不等于软件上市，拿出一个测试版本，能够把需要展示的部分完成就可以了。但是你却总说需要5个月。其实是没搞明白对方要的是什么，对方要的是3个月的时候能拿出一个能让大家看的应用的计划，当然能够全完成就此上市更好。
　　所有估算出来的单点值不是100%的。如果说需要10个人月，那么这个值到底有多少可能性呢？100%是不存在的。书上给出的是一个理论上是钟型的曲线。如果你要告诉对方一个估算结果，最好是带有可信度的单点值，或一个多点范围。比如“70%可信度在20人月完成”或需要“15-30人月”之类的。承诺应该在估算区间内，并根据承诺指定计划。
　　一个“良好的估算”，大师提出一个好的估算可以做到正负10%。但是，这是和CMM成熟度相关的。没有良好控制的项目是无法做到的。考虑到国内的情况，能到CMM2都是烧高香了（真正达到，那些为评级而搞出来的作秀品不算）。
　　估算对项目控制会产生很大影响。只要你做出了估算，那么你就会根据估算做出承诺并制定完成这个承诺的计划。一般只要最后完成时的花费在“估算”之内，大家就会说估算是成功的。但是实际上开发过程中不确定的事情太多，而且因为需求的不断更改，可能最后完成的东西和最初定义的东西完全不是一个东西。所以估算的真正目标是确定项目目标是否足够现实，而不是预测项目的结果。
　　书中第一章的最后给出了一个“什么是良好的估算”的定义：良好的估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。

 

评论

2 楼 魔力猫咪 2008-01-30  

谢谢，如果你对这方面感兴趣，猫咪推荐你也买一般《软件估算-“黑匣子”揭秘》。绝对值。

1 楼 wangcheng 2008-01-30  

好文，期待继续