摘要：
这年头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，即作为组织的生产力数据，应该如何度量呢/p>
满足目标3之前，我们应该保证我们能满足目标1和目标2，如果目标1和目标2都没满足的情况下，我们就去追求目标3，是有点“超前”，这种“超前”对公司来说可能是“拔苗助长”。当然我们希望有一种方法能同时满足这三个目标的，但到目前为止，我还没有见到过这样的成功案例。软件规模度量还是要一步一步来，不要一开始就期望吃成个“胖子”了。
如果在“傻瓜估算法”的基础上多做一步，我们是可以满足目标三的。在第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行数。我们可以利用这些WBS得到两个输出，一个是工作量，一个是功能点或者是代码行数。如果积累了一定的数据，就可以建立功能点或者代码行数与工作量的对应关系，这样不仅可以用来衡量公司的生产力，也可以利用这些经验数据来估算以后的项目。
请看下一文……
作者：张传波
创新工场创业课堂讲师
软件研发管理资深顾问
《火球——UML大战需求分析》作者
www.umlonline.org 创始人
来源：张传波
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！