我们为什么要进行软件规模度量呢?目的无非是：

　　1.作为报价或者决策的依据。

　　2.安排具体的项目进度。

　　3.可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。

　　如果是为了投标报价，建议用Delphi法，功能点法、代码行法太慢了，不能适应商战社会，投标经常是没有这么多时间让你去折腾的。Delphi法的大致方法如下：

　　1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。

　　2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。

　　3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。

　　4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。

　　如果是为了目标2，安排具体的项目进度，我建议用“傻瓜估算法”，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗?我们亲爱的软件工程师们认可功能点法或者代码行法吗?搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。

　　第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。

　　软件开发活动，可以分类以下几类：

　　直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。

　　项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。

　　项目支持类活动，如：配置管理、QA检查等。

　　维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。

　　根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。

　　把这些框架定好，并设计出估算表模板，供项目组使用。

　　据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。

　　第二步：项目组选用合适的估算表模板，进行由底而上的估算。

　　项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：

　　1.最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。

　　2.负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。

　　3.做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。

　　第三步：持续完善模板，持续改进。

　　每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。