，如：配置管理、QA检查等。
l 维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。
根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。
把这些框架定好，并设计出估算表模板，供项目组使用。
据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。
第二步：项目组选用合适的估算表模板，进行由底而上的估算。
项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
第三步：持续完善模板，持续改进。
每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。
“傻瓜估算法”非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好？当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。CMMI也没有规定非要用什么功能点法代码行法来度量软件规模。
软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用“土方法”也可以把工作量估好估准！
如果要满足目标3，即作为组织的生产力数据，应该如何度量呢？
满足目标3之前，我们应该保证我们能满足目标1和目标2，如果目标1和目标2都没满足的情况下，我们就去追求目标3，是有点“超前”，这种“超前”对公司来说可能是“拔苗助长”。当然我们希望有一种方法能同时满足这三个目标的，但到目前为止，我还没有见到过这样的成功案例。软件规模度量还是要一步一步来，不要一开始就期望吃成个“胖子”了。
如果在“傻瓜估算法”的基础上多做一步，我们是可以满足目标三的。在第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行数。我们可以利用这些WBS得到两个输出，一个是工作量，一个是功能点或者是代码行数。如果积累了一定的数据，就可以建立功能点或者代码行数与工作量的对应关系，这样不仅可以用来衡量公司的生产力，也可以利用这些经验数据来估算以后的项目。
特别声明：
如需转载此文，请给出指向本网站的连接，如下：
作者：张传波
摘自：http://www.umlonline.cn
如不能按此要求，请不要转载此文。