【分享】评审的概念、形式、作用和目的及其必要性!

评审的形式
1．人

如果就参加评审的人员而论，有以下几类评审形式。

① 同行评审（Peer Review）：也翻译为“同伴评审”或“同级评审”或“对等审查”等。由软件开发文档的编写者的同事对软件文档进行系统的检查，以发现错误和检查修改过的区域，并提供改进的建议。

② 独立评审：安排一些人对成果进行个别检查，以单独完成对成果的评审，评审人员相互之间暂时不进行讨论。

③ 组内评审：项目团队内部组织的对成果的评审。

④ 相关项目成员评审：相关项目成员可以分为横向和纵向两类，所谓横向，指与本项目同时进行的项目的成员；所谓纵向，指历史上已经开发与这个系统有关的软件系统项目的成员。在必要时，也可以请规划中即将建设的软件项目的成员参加。横向和纵向可以是针对同一个用户而言，主要是为了在客户的业务上进行统一的规划设计，如统一的用户账号管理及统一的用户信息代码管理等；也可以是针对公司内部而言，这主要是在软件的技术和设计风格上进行统一的规划。以充分利用软件复用技术来提高效率和易维护性，充分考虑各系统之间的接口、兼容性和界面一致性。

⑤ 企业内评审：也可以称为“项目组外评审”，是企业内部抽调必要的力量进行组织的，有条件时也可请用户参与。相关项目成员评审是企业内评审的一种特例。

⑥ 邀请专家评审：在特殊情况下或为了特殊的目的，管理层或用户邀请专家对阶段成果进行评审。这些专家可以是软件技术方面的专家，也可以是与客户业务密切相关的行业业务专家，如国家某个行业信息规划人员和行业标准制定人员等。

⑦ 用户评审：以用户为主的评审，一般是把文档交给用户检查，或以用户为首组织的评审会议。一般情况下，每份需求文档都要经过数次的用户评审，尽可能地得到最终的确认。而设计文档则视情况而定，一般较少进行用户评审。

⑧ 第三方评审：用户委托第三方机构进行评审，如监理机构、检测机构和专家验收组等对需求设计文档或其他工作成果进行评审。

2．对象

如果就评审的对象完整性而论，有以下几类评审形式。

① 整体评审：在文档整体完成后，对需求或设计文档的整体进行评审。当文档比较大而难以进行整体评审时，可分而治之，分多次进行“部分评审”。

② 物理部分评审：不同评审人员对某一成果的某些物理部分内容进行评审，如按照文档章节、功能划分或模块划分等。

③ 逻辑部分评审：分阶段检查某一成果是否具有某个所期望的特性，或不同评审人员对某一成果的某些特性（如可读性或可维护性）要求进行评审。

④ 迭代评审：迭代开发模式中分阶段对部分内容进行评审，每一部分评审通过后即可作为下一阶段相关部分工作的基础，每一次迭代都包括需求、分析、设计、实现和测试活动。同时每次迭代都建立在前一次迭代工作的基础上，每次迭代都会生成更加接近最终产品的可执行版本。

⑤ 回归评审：原来的评审发现问题需要整改并再次进行的评审，以检查问题是否已经得到修改，同时检查是否出现新的问题。

3．环境

就评审的环境或使用的工具而论，有以下几类评审形式。

① 临时检查：在需要的情况下临时检查文档、评审人员与作者随时对文档中的问题进行讨论。这是评审中最不正式的一种，可以快速听取评审人员的意见。主要为了解决当前的某个特定问题，或对某个特定问题进行确认。临时检查也翻译为“专案评审”（ad hoc）或“随时评审”，可以及时沟通，及时发现问题。但要注意适度，在必要时进行。

② 工具评审：通过安装在网络环境上的管理工具软件将项目阶段成果提交给评审人员阅读，评审人员利用工具阅读文档后填写意见（如Domino.Doc）。

③ 邮件评审：通过邮件将项目阶段成果发给相关人员进行评审，评审人员通过邮件反馈意见。

④ 会议评审：相关人员集中在一起开会对项目阶段成果进行评审，这是最常用的形式。所以当提到“评审”时，很多人就会自然地联想到开会。

⑤ 远程会议评审：不仅在主会场进行评审，而且通过视频及音频与外地的评审人员进行实时在线沟通。这是会议评审的一种特殊形式，可以突破空间的限制，对于项目团队成员或评审人员有出差在外的项目是一个比较经济的形式。

4．效力

① 正式评审：得出是否批准通过的正式结论。

② 非正式评审：不具否决权的“评审”，也可以称为“评阅”，主要是为了讨论，收集意见和建议，不做是否批准通过的结论。

正式评审或非正式评审都可以通过会议、邮件及工具的各种形式，也可以是整体评审、部分评审或迭代评审。当然正式评审最好是整体文档完成后的评审，批准主要是针对整个文档的，但迭代开发的例外。

③ 观摩培训式评审：一般是一种会议形式，主要是为了培养新人。在评审会议召开时，可安排一些不同角色新人来旁听。他们不对评审的工作负责，而是以学习评审技术，体验评审工作为目的。

评审的作用和目的
在团队开发中，充分的沟通是非常有必要的，沟通的方式之一就是通过文档。不论评审的效果如何，发现多少问题都可以让相关人员了解需求与设计。而通过相互之间的讨论，澄清一些模糊的认识，进一步理解文档的含义。评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以利用企业内部各种优秀成员的智慧，为软件开发寻找最佳的解决方案。

评审的作用和目的主要是尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。本阶段造成的错误如果能够及时地发现，或者在后面越早的阶段发现，就能够及早发现潜在的风险，及时做好防范的对策，做到未雨绸缪。

评审的过程不仅是为了发现问题，而且为了便于跟踪及改正，还应当对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。正如著名软件大师Gerald M Weinberg在《你的灯亮着吗？》所说：“一旦我们知道问题是什么，那么该问题的解答或解决对问题本身来说就是一件微不足道的事情。”确实，人们经常会把一些表面的现象当成问题，而不知道根本的问题是什么？不知道真正的问题出在哪里？这样解决问题时就很有可能头痛医头，脚痛医脚。

具体来说，评审最直接的作用和目的当然是要改进需求与设计文档本身，为下一阶段工作提供正确的基础，并通过评审的过程提高相关人员的总体分析设计及文档写作水平。当然，写需求或设计等技术文档，并不等于会“做”需求分析和设计。因此有些刚参加工作的新手急于找一些模板或样例照葫芦画瓢，把文档完成就说“我会做分析”、“我会做设计”，其实只是刚起步而已。而评审不仅能够看出文档本身的问题和水平，也可以看出分析设计的过程和水平。

评审的作用和目的还在于强化开发人员的责任感，这是基于“把关效应”。即分配工作任务时，是否事先声明设置检查点，直接关系到工作任务完成的质量和效率。日本软件开发企业非常重视用验证与确认来强化开发人员的责任感。

丰富行业业务经验和评审经验并改进评审流程，使项目进度安排更加合理也可以作为评审的作用和目的。

当然，评审的最终目的无疑是提高软件质量，减少各种无形损失。