软件度量都该度个啥？（3）——软件规模的度量
摘要：
这年头IT界流行“用数据管理过程”、“用数字说话”，软件度量成为热点话题！一方面一堆专家在“哗众取宠”，而另外一方面企业在推行软件度量的实践中遇到了各式各样的问题，软件度量在软件企业中的实施效果不甚理想。一个软件企业应该从何做起度量工作呢？希望本文能给大家带来有益的启发！
大纲：
1.形形式式的度量陷阱（1）
2.什么是度量？（1）
3.首先应该度量的指标——公司的效益指标（2）
4.每个软件公司都可以并且应该做好的度量——缺陷度量（2）
5.成功的基础——软件规模度量（3）
6.项目跟踪的利器——进度度量、成本度量（4）
7.被吹得最多的六西格玛管理（5）
8.量体裁衣、身体力行（5）
我将分5篇为你分享，大纲后面的数字表示将在第几篇分享该部分内容。
成功的基础——软件规模度量
曾经有这样的一个辩论，功能点VS代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里我不想谈论这两种办法，这些方法可能仅是理论上可行，目前我也没有见到过一个成功实践这类方法的案例。
我们为什么要进行软件规模度量呢？目的无非是：
1. 作为报价或者决策的依据。
2. 安排具体的项目进度。
3. 可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。
如果是为了投标报价，建议用Delphi法，功能点法、代码行法太慢了，不能适应商战社会，投标经常是没有这么多时间让你去折腾的。Delphi法的大致方法如下：
1. 找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。
2. 全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。
3. 第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。
4. 按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。
如果是为了目标2，安排具体的项目进度，我建议用“傻瓜估算法”，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗？我们亲爱的软件工程师们认可功能点法或者代码行法吗？搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。
第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。
软件开发活动，可以分类以下几类：
l 直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。
l 项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。
l 项目支持类活动，如：配置管理、QA检查等。
l 维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。
根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。
把这些框架定好，并设计出估算表模板，供项目组使用。
据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。
第二步：项目组选用合适的估算表模板，进行由底而上的估算。
项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
第三步：持续完善模板，持续改进。
每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。
“傻瓜估算法”非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好？当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。CMMI也没有规定非要用什么功能点法代码行法来度量软件规模。
软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用“土方法”也可以把工作量估好估准！
如果要满足目标3，即作为组织的生产力数据，应该如何度量呢？
满足目标3之前，我们应该保证我们能满足目标1和目标2，如果目标1和目标2都没满足的情况下，我们就去追求目标3，是有点“超前”，这种“超前”对公司来说可能是“拔苗助长”。当然我们希望有一种方法能同时满足这三个目标的，但到目前为止，我还没有见到过这样的成功案例。软件规模度量还是要一步一步来，不要一开始就期望吃成个“胖子”了。
如果在“傻瓜估算法”的基础上多做一步，我们是可以满足目标三的。在第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行数。我们可以利用这些WBS得到两个输出，一个是工作量，一个是功能点或者是代码行数。如果积累了一定的数据，就可以建立功能点或者代码行数与工作量的对应关系，这样不仅可以用来衡量公司的生产力，也可以利用这些经验数据来估算以后的项目。
请看下一文……
作者：张传波
创新工场创业课堂讲师
软件研发管理资深顾问
《火球——UML大战需求分析》作者
www.umlonline.org 创始人
