评审时机不止任务完成时

说起评审的时机，几乎所有实施GJB5000的项目组制定的评审计划千篇一律都是“QA审核后”或者“入库前”，总之，就是在完成工作产品编制后进行一次评审即可（如果工作产品出现变更，变更后的验证也可能采取评审的方式）。

一个工作产品一生只进行一次评审（不考虑变更的情况）合适吗？

我们进行工作产品的评审，是希望借助这一活动来发现工作产品中存在的不规范、不标准、有疏漏、有错误的各式各样的问题，以剔除工作产品中存在的这些缺陷，这些真的只通过一次评审就能全部毫无遗漏地发现？

对于一个规模小、功能足够简单的软件，也许可以通过一次评审解决问题，而对于一个规模中等偏上、功能稍显复杂的软件，即便有较高技术水平和丰富经验的同行专家百忙之中抽出时间进行了评审，找出了一些问题，就能确保工作产品中没有遗留下来未被发现的缺陷？

就像测试没法穷尽，但是我们可以提高测试的覆盖率来减少遗漏的测试缺陷那样，评审也可以通过提高评审时间和评审次数来提高评审的覆盖率以减少评审遗漏的缺陷。

所以，我们的评审时机不应在任务完成后只进行一次。我们可以多次进行。

除了工作产品完成后的项目组内部评审、有用户参加的确认/验收评审外，还可以增加以下两类评审：

• 自己评审。顾名思义，自己评审就是自己审查自己的工作产品。评审的时机是自己任务完成时，评审的内容包括：错字、漏字，文章冗长，重复，不统一，不合适的表达图表等的检查，设计内容的一贯性检查，实现方法错误的检查，标准化遵守的检查等。

• 中间评审。所谓中间评审就是工作产品开发过程中进行的评审。评审的时机可以是开发的内容比较复杂时，或者开发任务有很多时，或者是不确定的因素有很多时；评审的内容包括小组内一贯性的检查，涉及者误解释的检查，实现方法错误的检查，标准化遵守的检查等。

通过增加以上两类评审，提高评审时间和评审覆盖率，可以有效地提高评审的质量。

这正是：

评审时机不唯一，评审形式可多样

评审次数可增加，只要评审质量高

参考书目：软件品质之完美管理实战经典，作者：颜廷吉，出版社机械工业出版社

作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。