【IT168 专稿】

    在日常生活以及其他行业中，评审活动都大量存在。比如项目招标评审、质量评审、设计评审、合同评审、订单评审等。

    在软件开发的过程中，评审也是软件开发过程中的一个重要活动。软件开发活动中到处都有评审活动的存在，比如测试计划、软件开发计划、配置管理计划、风险管理计划、需求管理计划等的评审；另外，开发过程文档的评审，包括需求文档、分析文档、概要设计文档、详细设计文档等都需要做评审；在公司的开发过程管理规范上也需要评审，诸如开发过程规范文档和流程的评审都是必需的；同样，在开发结果上也需要评审，如代码走查、系统验收，也都是评审活动的表现形式。

如何评价项目评审状态

    很多书籍和资料中都可以查阅到评审的过程，以及相关的一些问题，但是，在软件开发中，我们的评审活动做得如何，不妨通过一个评估来了解。大家可以用下面几项内容来做个测试，看看你们公司的评审是否真得起到评审的效果。

    1、公司的评审通常都有几个人参加？参加人的角色都是什么样的？各个阶段的参加角色和人数是否有明确的定义？

    2、公司在评审前给参加评审的人员准备时间了么？这个时间是否够用？大家是如何使用这个时间的？

    3、公司评审前，评审资料准备的充足么？是否是人手一份纸质的？还是都在计算机上阅读？

    4、公司的评审会持续多长时间？

    5、公司的一次评审会一般评审多少份待评审工件？

    6、评审时候提出的修改意见如何记录？

    7、评审的时候是否直接在原文档上作修改？

    8、有没有专人作评审记录？评审记录是怎么做的？

    9、评审后，一般多长时间给工件开发者进行修改？

    10、修改后的工件如何进行修改确认？如果确认不通过是否还会安排评审，一般如何做？

    请大家记录一下上面这十个问题的答案。我们来看看一个评审应该如何进行，什么样的评审才能起到效果。

有效的评审过程

    1. 评审的准备

    评审的准备需要包括如下四项必要的内容：

    (1)待评审工件

    一般来说，一次评审会的待评审工件数量不宜过多。因为需要让参加评审人员能够集中精力关注工件的内容和开发质量，过多的工件会分散评审人员的注意力，同时也会影响评审的效果。

    待评审工件一般一次为一件最好，宁可多开评审会，也不要弄一次工作量过大时间过长的评审活动。

    (2)参加评审的人

    参加评审的人员一般包括：

    工件的开发者，负责工件的讲述和简要介绍。

    工件开发者项目组负责人，负责会议的协调和评审过程的控制。

    工件评审者，需要至少三人，最多七人，奇数人数，以便于评审中的评审意见的投票。评审者的选择一般根据待评审工件的属性进行选择，开发类工件选择其它项目组中相关的开发人员来参与，其它亦如此。

    会议记录者，只需一人，负责会议记录。

    (3)评审准备时间

    评审一般要提前三到五天以上告知参加评审的人员，给每个参加评审的人以确定的准备时间，而不是工作之余的准备时间。

    如果不给固定的工时来做准备，并记录绩效，那么很多人就不会有时间来专门看评审工件的内容，提前做好准备。最后就会造成评审会时间过长，效果也就无法保证。

    评审前评审人员要把自己找到的问题通过邮件发送给本次评审的评审负责人。

    这个具体的工时根据评审会的工件数量和评审时间进行确定，这里给一个参考的时间定义。如果评审一个工件需要一个小时的评审，那么至少给每个参加评审的人员两个小时以上的文档审阅时间。基本上按照评审时间的两倍进行定义即可（这是个经验数字，限于国内的软件开发中数据积累过少，我本人目前也没有可供参考的实验性数字可以提供）。

    (4)评审工件准备

    待评审工件最好进行纸质打印，评审的时候，建议不考虑电子版的评审模式，因为打印出来的容易做标记，容易留下痕迹和评审记录信息（这些在CMM3级的要求中是必须留下的）。

    当然，如果贵公司有足够多的手写设备，也可以考虑全部采用电子版本的评审模式。

    (5)其他工具准备

    录音笔或者速写笔和足够的纸张，建议考虑前者。

    2. 评审进程

    评审过程在很多书中都有介绍，这里建议大家去看看刘寅虓著的《系统分析之路》一书中的介绍。这里为了文章的完整性做一个流程性的描述，以便于全文的分析之用。

    评审过程：

    (1)评审会开始后，主要开发者进行任务的简单介绍，每个工件的介绍时间不要超过五分钟，因为所有参加评审的人都已经经过了认真的准备。

    (2)参加评审人员对工件进行提问，开发人员进行回答，同时录音笔/记录人员进行记录。这个过程每个工件不要超过三十分钟为佳，如果工件内容过多可适当延长。

    (3)评审负责人进行评审意见总结和宣读，时间为10分钟到15分钟，然后根据修改的工作量确定评审后的修改时间和最后的审核时间点。

    (4)大家在评审总结上签字确认。

    3. 评审后的修改与审核

    评审后的活动，经常被人们所忽视，这里我就详细写一下相关步骤：

    (1)评审会后，通过录音和现场记录将评审时的评审记录通过邮件发送给所有参加者。

    (2)开发者根据评审记录修改开发工件。

    (3)修改完成后，将修改后的开发工件提交给所有评审者进行最终审核。

    (4)审核通过后，标记工件版本，确定此工件的阶段性版本记录。

    4. 评审常见错误

    (1)评审时间过长

    整个评审会议过程要快速有效，不能拖延。否则时间超过一个小时以后，评审人员会感到疲劳，评审效率和效果都会降低，同时还会延误其他工作。因此一个小时以上的评审，甚至会议，往往都是无效的。

    (2)评审过程中对工件进行修改

    评审的目的是为了找到错误，而不是修改错误，因此评审的时候要最大程度地利用评审的有效时间进行错误的查找和分析，而不要用这个时间对开发工件进行修改，哪怕是个别文字的修改，也会耽误参加评审人员的时间，降低整个评审的效率。

    这个错误的错误等级最高，几乎所有的评审中，都会发生这类错误，因此要格外注意。

    （3）评审准备工作不足

    这也是造成评审会时间过长的一个根本原因，因为很多人在参加评审之前根本没有给安排固定的时间进行文档的审核，因此，就会出现评审会开始的时候大家都在埋头看文档，或者匆忙间找一些措辞和小的错误来掩饰自己此前没有时间检查工件的实情。于是，主要开发者不得不重新对工件进行详细介绍，这个介绍时间一般都会花费十几二十分钟以上，结果评审会就很容易超过一个小时的有效时间范围。

    这个错误的错误级别也是最高的，基本上国内很少有软件公司给参加评审的人员以专门的准备时间，因此也需要特别慎重。

    （4）评审准备是否算工作量

    另外很多公司并不认为评审是一个重要的工作内容，因此，没有给参加评审者以时间来进行工件审核，谁在这上面花费时间就会影响自己正常任务的完成。所以，很多参加评审的人就只能对评审敷衍了事，临时抱佛脚，评审会上现看现说，于是，评审也就流于形式。

    国外某些公司在这方面做得很不错，这点是值得称赞的。国内我还没有看到这方面的公司。

    电信集团当年的评审会，都是需要提前做准备的，尤其是招投标的评审，会专门安排人进行封闭审核分析，这当然是因为这种评审是十分必要的。

    在笔者创建的绩效管理模型中，评审是做了绩点计算的，同时定义一次评审的工作量定为一点基础绩点，因此，这也是笔者那个绩效管理模型的基础评价指标之一。

总结

    评审是软件开发过程中的一个重要活动，因为在最近的咨询工作中发现很多公司都存在一些概念甚至操作上的严重问题，因此打算把软件开发过程中的各个活动都单独撰写出来，作为提示要点来进行，本文是第一篇。