软件项目的过程评审(转载)

我们在管理软件项目时，常常会出现在测试阶段和用户验收阶段缺陷率太高，需要投入大量的人去修bug, 但是由于时间紧，往往改好一个bug,又引入新的bug,导致恶性循环，越改bug越多。最后项目延期，成本超出预算，员工对加班意见很大，客户也对交付的软件不满意。造成这样后果的原因很多，比如需求分析没有做好，设计没有做好等等，有一个原因大家往往容易忽视，那就是过程的评审(Review)。

在设计，编码，测试各个阶段都需要做很好的review，不能走过场，比如，项目经理对Lead说，“你把设计文档review 一下”，“你把开发人员的代码review一下”，Lead点点头，结果没有下文，或者马马虎虎花个几分钟看看，就算了，根本起不到review的作用。要真正让review发挥作用，尽早发现设计和开发过程的缺陷，必须要建立严格的review流程：

1. 项目经理制定项目计划的时候需要把review的时间考虑进去，项目计划里面要体现review, rework的时间，周期。

2. 要根据项目的需要，建立review的 check list. 比如代码评审，需要根据规范建立评审项。

3. 在项目执行过程中，严格按照项目计划进行评审，安排评审会议。在会议前按照checklist 对设计文档或代码进行review，生成review报告。在评审会议中，对报告的内容进行分析和讨论，review出的缺陷要记录文档或系统。

4. 对review的缺陷进行修复

5. 定期对缺陷的原因进行分析，采取措施，避免以后发生同样的问题

6. 项目结束后，对review的效果进行统计分析，一般有两个指标衡量review的效果, 1) review efficiency 2) review effectiveness, 按照行业的标准，一般情况下，如果review找到的缺陷达到项目发现的总缺陷的60%以上( review effectiveness)，或者review 每小时能找到1.5个以上的bug. 说明review起来比较好的效果。如果没有到达，那么分析原因，采取措施，以后逐步改进。

总之，只要对过程评审足够重视，并真正地落实，才能发挥评审的作用，尽早发现项目中存在的问题和缺陷，降低总的缺陷数量，减少后期维护成本。