评审形式不止一种

一提到评审，在科研单位里似乎就是有领导、专家坐在一起开会的场景。所以，在实施GJB5000A的组织中编写评审规程的时候，多数也是按这种会议评审的方式来写。这样的做法，就把评审给单一化了。

按汉语词典的解释，评审就是评判审核，是为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。这个解释中并没有说要有几个人参加评审，也没有说评审是开会还是其他的什么形式，只要做出有效的评判审核，那不就行了。

在GJB5000A中，有几个实践是直接以评审命名的，像二级中的“实施进展评审”、“实施里程碑评审”、“评审影响该项目的计划”，三级中的“实施同行评审”、“评审接口说明的完备性”等等。这里的评审也都是泛指的评审，也没有指定评审的方式。

所以，在GJB5000A中的评审就是以作出有效的评判审核为目的，并不只是会议评审这样一种形式。

评审可以是单人、二人、多人进行，可以是会议评审、会签评审；可以是线上评审、线下评审。

• 单人评审

这个是和我们熟知的评审差距最大的。自己一个人也能叫评审吗？但是，自己一个人就不能达成“有效的评判审核”的目标吗？虽然个人看自己的作品，总会觉得哪哪都好，主观上缺少发现问题的动力，所以，单人评审一定要有个评审检查表，对照检查表逐项检查，会在很大程度上弥补主观能动性的问题。

• 二人评审

二人评审，也叫伙伴评审，即程序员之间的互相评审。与单人评审相比，它避免了个人主观上不积极的问题，而且也是很轻量级的评审，比多人评审更容易执行。二人评审也有些缺点，比如：评审人员可能缺乏对被评产品的深入了解，无法在短时间内做出有效的评审。

• 多人评审

多人评审，也叫团队评审，是指多于两人的团队就某一工作产品进行的评审。团队评审可以发挥多个专家的作用，评审的效果可能比前两种评审好很多。但是它也有一些缺点，比如：

a）要找到一个所有评审人员都能出席的时间，并不容易；

b）牵涉的人员众多，理解程度不一，复审的速度和效果不能得到有效的平衡——太快则有人不懂，太慢则浪费许多人的时间；

c）正是由于成本问题，无法对所有的文档和代码进行深入的评审；

d）由于人员众多，有面子问题。

总之，在GJB5000A中，评审并不只会议评审一种，评审的形式可以根据项目的实际情况（考虑项目进度和投入的资源等），评审的内容不同而选择合适的评审形式。

这正是：

评审追求有效性，形式可以很灵活

人员未必要众多，会议会签也都可

参考文献：移山之道：VSTS软件开发指南，邹欣

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