4.2.5  同行评审流程裁剪指南

　　以上介绍了正式的同行评审流程，但对于很多小型的项目或时间周期很短的项目来说，这种正式的评审流程有些过于庞大，在项目中无法真正贯彻执行，这就需要管理人员对正式的评审流程进行裁剪，制订符合本项目特点的个性化流程。

图4-4  同行评审收尾阶段流程图

　　在同行评审计划阶段，根据项目的类型、规模等因素确定所需评审的工作产品。

　　在同行评审启动阶段，主要的工作有以下几点：

　　① 准入/准出条款、评审的方法通常在公司范围内都有统一的标准，每个项目组一般不需要再自行定义。如果公司范围内已经有相关标准，那么这几个步骤可以进行裁剪。

　　② 对于准入/准出条款和评审方法的讨论，如果项目较小，团队成员之间的沟通又比较顺畅，那么这个环境可以被简化或被裁剪。

　　③ 评审的正式通知在一些小规模团队中也可以被简化或被裁剪，前提是与会人员都应该在同一个地点办公，但不管是那种通知方式，都必须做到提前通知。

　　同行评审执行阶段和收尾阶段已经非常简单，因此不建议对其流程进行裁剪。

　　对于代码走查类型的同行评审来说，工作的流程可以进行一下定义和裁剪。

　　代码走查应该被软件开发人员视为与编码、单元测试同等重要的日常工作，只是代码走查的频率不像单元测试那样天天都要进行。在制订项目计划时可以根据实际情况定义代码走查的间隔时间，例如三天检查一次，或一周检查一次。

　　在代码走查的启动阶段，不一定要等某个模块的功能完全实现再进行代码走查，因为代码走查的重点不是模块的功能是否正确，而是代码是否规范、算法是否合理，因此代码走查的准入条款可以被裁剪。代码走查的准出条款相对比较严格，通常发现的所有缺陷都必须被修正。代码走查的方法可以是项目组内开发人员互相检查，也可以安排设计人员来检查开发人员的代码，只要设计人员的时间允许，这种检查方式的效率和效果都是最好的。由于代码走查中准入/准出条款及走查的方法都比较简单，因此不需要对这些内容进行再次讨论，另外代码走查已经成为开发环节中的日常工作，而且流程相对简单，因此也不需要在每次走查前都发出正式的通知。代码走查也不需要填写评审准备表，公司的编码规范就已经起到评审准备表的作用。

　　在代码走查的执行阶段中，只需要把发现的缺陷以及不符合编码规范的地方记录下来即可。代码走查的结果只有通过和不通过两种，软件项目不存在代码级别上有条件的通过，这会给软件产品带来较大的风险。

　　裁剪指南的原则就是不管增加还是减少了某些流程或工作产品，都不能给项目带来风险。对于项目组裁剪后的流程都必须经过过程改进（EPG）人员的确认。