在参与这么多次自从我们公司学习了CMMI3软件过程改进的评审后，我觉的有必要做这样的一次总结。也希望各位同事能重视软件评审这样的一个软件过程。

首先，我们必须要意识到我们为什么要开软件评审，如果你连这样的觉悟都没有，或者你还是认为评审是在浪费时间、减缓了项目的进度。很抱歉，从CMMI3的原则上讲，你连开评审会的资格都没有。可能我的语气强硬了一点，但是我们必须意识到造成项目进度缓慢的是各种各样的产品缺陷。不管你有没有发现，缺陷总是存在，问题只是你最终发现它们时，需要多少纠正的成本。我想做我们程序员的都知道,缺陷发现得越晚费用越高，研究表明在测试后期发现的BUG所消耗的质量成本是需求分析阶段的100倍。而开软件评审的重要目的就是在评审中发现产品的缺陷，减少大量的后期返工，从而真正意义上达到软件质量的提高和成本的减少。很多大公司比如IBM,HP,AT&T等，都在软件评审这个过程中，得到了巨额的回报，有兴趣的同事可以查阅这方面的资料。

OK。软件评审的好处我就说到这里，在说下去也没什么意义。

这次总结主要是针对如何实施成功的评审，对CMMI的其他环节并不进行描述。在我接下来的总结中，一些术语及相关的概念大家可以在《软件研发技术评审过程指南》的文档中找到，如果想更深层次的理解，可以查询软件质量保证相关书籍。

我觉得我们公司现在各个试点项目评审从某种意义上来说，都是不合格的，虽然说也有各个评审报告、审查表、缺陷表。但是我们不能为了文档而文档。那如何实施成功的评审呢？我觉得已下几点特别重要：

第一、 对所有的工程师进行评审的培训，使评审深入人心。

这一点我们公司培训过，但是效果太差，深入人心更是谈不上。为什么我要把这一点放在第一位、因为这是意识上的认识，是反映了你对评审会重视程度。如果评审参与者都不了解整个的评审会过程，那他们就会感觉非常的迷茫，影响参与评审会的积极性，也影响整个评审过程的效果。这一点我就是一个例子，记得第一次参加CMMI举行的评审会时，真的是一头雾水，一个通知下来要开评审会。OK开就开吧，但是在会上什么你当主持人呀，作者不能读文档，要替换个人呀，等等什么都不懂，还以为在开联欢会呢！也根本没有认识到自己的角色和责任。就这样的一个状态，能开好评审吗？

第二、 一定要充分的为评审会议做好准备。

这一点在我们公司，不管是第一个试点项目，还是第二个试点项目，都完全没有做好。从二个方面可以完全说明这一点：

1) 评审组长的选定【我们公司称为主持人】

选定评审组长对评审来说，是非常重要的。评审组长需要和作者一起，策划和组织整个评审活动。研究表明：一个优秀的评审组长所领导的评审组比其他评审组平均多发现20-30个缺陷。而且选派的评审组长应该是自觉担任该职务，因为任何勉强都会导致评审不能达到预期的目的。

然而我们公司对这块根本就不予重视，有的是会上临时任命、有的评审组长对自己责任和注意点根本不知道、有的甚至到了开评审会都不知道自己是评审组长的。更不要说和作者一起策划整个评审会。

2) 对审查包的准备

如果说上一个方面是公司不给于重视，那这一点可以说在我参加的这么多次评审会中，包括我本人，完全没有做到。有人可能认为我在夸大其词，呵呵、还是听我慢慢道来吧！

首先、我们知道审查包也就是评审材料的集合，在我们公司都要先开项目组内部评审，将组内认为的一些缺陷、一些模糊感念、一些语病错别字之类提出来，然后修改之后打包。

其次、在评审会议开始前几天分发给评审小组的成员，已使小组成员在会议之前可以有所准备。

接下来，也是准备过程中最关键的，在评审员收到评审包后要阅读并理解其中的内容，然后采用相应的缺陷检查表或其他方法来检查产品和文档中可能存在的缺陷，并记下将在会议中提出的问题。

我们可以对照上面的要求，我们做到了吗？在评审会，我常常听到这样的声音：今天要开评审会？评审材料在什么地方？评审材料我才刚刚收到？有的人可能认为我是领域专家，这方面的软件我做过很多篇了，不用看什么材料了？对不起！非常抱歉，如果是这样的人来评审会，往往会将评审会往死胡同带。何况你是真正的领域专家吗？在我们读书的时候，都知道在学习新知识时，课前的预习，往往在掌握新知识时有很大的帮助。因为我在听课时候，有重点、有目标、有疑问、这样我们才能真正达到有效率的去听课。开评审会也一样，如果各位评审员没有阅读和分析资料，这样就会对文档了解不够，导致在整个评审过程中可能曲解作者提供的信息，并假设作者是正确的，很容易对作者实现方法的合理性保持沉默。

对审查包的准备应该说是开好评审会的重中之重，但是也是最难实现的一步，因为参与评审的工程师或者领域专家都需要投入大量的时间和精力，然而我们都知道这些人都是公司的大忙人，但是并不是意味着是大忙人就对审查包不闻不问，而是事先要为评审活动分配足够的资源，能让评审人员有足够的时间去分析，如果时间不够，那评审人员往往采取敷衍的态度，无法体现评审的真正效果。这一块涉及到了很多管理和人力资源上面的知识。这里需要提出一点，评审人员的数量一般保持在3-6个人，不要以为审查小组的评审人员越多越有效，人数太多往往很难集中所有人的精力，而且参加了评审会，你就要有相应的角色与责任，对审查包的也要仔细的分析过，所以往往加一个评审人员并不是表面上只占用他一次评审会的时间，必须要意识到这里资源的消耗。还有研究表明安排几个小型的评审会要比安排一个大型的评审会更加有效。

第三、 召开评审会议

这个步骤可以说是上二点的产物，也是最核心，所有与会者都需要仔细检查评审内容、提出可能的缺陷和问题，由记录员在记录在评审表格中。

这里我只谈我对在评审会召开时的几个注意点：

首先：评审组长要介绍一下评审会成员，以及他们的角色与责任，然后，评审组长还需简要说明待审查的内容，重申会议目标，提醒所有人会议的目的是为了尽快找到缺陷和问题。

这里需要注意的是，评审组长还需要判断每一位评审人员是否都准备充分，如果认为某些成员并没有为评审会议准备，评审组长有权终止该次会议，并重新安排会议时间。这么做的原因是因为准备是否充分对于评审来说十分重要。如果评审员在会议前并没有充分阅读和理解分发给他们的材料，那么评审会并不能起到预期的效果，而只能是时间和成本的浪费。

这里我做了一次模拟评审会开启模拟对话:

评审组长小胡：“今天我们开的是项目计划评审会议，这次会议评审的内容有：《软件项目计划书》《软件项目估算表》《风险计划与跟踪表》《软件项目进度计划》《配置管理计划》《质量保证计划》。这次参加会议的人员有：在项目管理方面经验丰富的老余，老夏，在本次项目中担任系统架构师的小王，系统分析师小青，QA小赵，记录员小李，在开本次评审会之前，我先要确认各位对3天前分发的审查包已经经过仔细的阅读和分析，请已经仔细阅读和分析的各位评审员举手表决！”

场景一：各位评审员举手表示已经仔细阅读和分析过审查包，做好了充分的准备。

评审组长小胡：“很好！各位评审员都已经做好充分的准备。在这里我强调一下，这次评审会的时间为1个半小时，我们这次的会议的目的是为了尽快的找到缺陷和问题，而不是解决问题，千万不要陷入无休止的讨论中，也不要对材料中某些词的二义性过多的讨论。好！现在会议开始，先由作者解读XXXX文档…….”

场景二：老余、小青没有举手，他们表示由于时间没有安排好，没有看过材料。

评审组长小胡：“非常抱歉！由于我评审计划安排的不合理，可能导致老余、小青没有对审查包的阅读和分析，这将会使整个评审会没有达到原有的目标。这里老余同志和小青也要反省一下为什么没有反馈你们的情况，这不仅浪费了你们的时间，更浪费了大家的时间。基于这种情况，我决定项目计划评审会推迟到后天。散会！老余、小青留一下……“

通过以上二组情景对话，我想大家都应该明白评审会是严肃的，紧张而有序的，是就是是，不是就不是。有人可能会认为场景二的要求太苛刻了，就因为准备不充分，而导致整个项目评审会延后。我认为这是有必要的，第一、不管是什么会议都要讲究它的质量和成本，尤其是软件公司更要注意这一点。由于老余和小青没有准备，必将导致整个评审会质量的下降。第二、起到了一个警示作用，使整个公司的员工都认识到在审查包准备阶段的重要性，也会使老余和小青重新去认识软件评审这个过程。

其次：主持人要充分发挥核心作用，在作者解读过慢或过快的情况，都要进行适当的调节。在会议陷入无休止的讨论中时，也要及时的阻止，再次明确评审的目的等等。其实当软件评审的意识深入人心的时候，像这些问题都不会发生。

第四、 跟踪和分析评审结果

这一块是在对评审会所发现的缺陷，做出妥善的解决。这里，我不想说什么，既然能准确的发现缺陷并记录，我想解决问题这一块，大家应该是没什么问题。

总结：学习和理解CMMI3是一个很漫长的过程，并不是统一考一下试就可以解决。我们可以在一个过程中失败一次，因为我们没有经验，我们不知道前面有个坑，所以我们跌倒了。但是在同一个过程失败二次，那只能说明我们就算知道前面有个坑，我们也无所谓，继续往里前走，继续跌倒。那只能说明一个问题我们更本就没有重视这个过程。

次日，公司领导都顶了我的帖子：

周院长【院方领导】:

金刚波总结得很好。我想不光是CMMI技术评审之前要做足充分的准备工作，其他事情，如给客户讲解售前方案、演示产品，现场需求调研，用户培训，内部技术交流，召集各种会议等，都必须做好准备工作，有管理大师说：

如果一个人准备工作做失败了，那就准备着失败。如果一个人准备工作做成功了，那就准备着成功。

毛院长【院方领导】:

写得很好，希望我们的EPG人员、QA人员、各部门经理以及各项目的项目经理仔细阅读并进行深入反思，并在今后的工作中严格要求，将CMMI中对各个环节的控制真正落到实处，而不是走过场。

舒克【院方领导】:

一口气看完了金刚波的大作，我看到了一个肯钻研有想法的年轻人。项目及质量管理部非常高兴地看到在CMMI初试情况下，引出了许多当事者的共鸣。希望越来越多的项目人共同探讨和实践CMMI的模型。希望CMMI项目组能够开启对话通道，不断进行过程改进。越来越多的人关心CMMI，是好事。CMMI项目组及相关人员要行动起来，我们的EPG、QA要行动起来。专家同志们，不要让员工走在你们的前面！

公司CMMI的规范已经出来，当然还不完整。因此如何保证头一次试用CMMI项目过程的质量十分重要。要金文中我们看到了工作的随意。员工的眼睛是雪亮的。我非常同意金文中的项目过程的严肃性和评审进程及要求的严肃性。我们的政策可能不完整，但我们的政策一定是必须执行的。

我也参加了一次项目计划管理评审会。我非常希望它能成为我们日常项目计划评审的标准范例。可是说实话，我认为没有达到目的。首先没有形成或确定计划评审的标准工作流程。评审会前的评审单没有回复，以至于评审类型都不得不临时改变。评审会不能事先抓住关键点，只能凭经验和演示中那快速的浏览产生的即时的质询。一个完美的会议的召开准备时间占70%，开会时间占30%。

CMMI强调过程控制，那就要把过程规范起来，把过程细化起来。而这些需要大家在实践中进行的。许多项目组把实施CMMI做为一个风险进行控制，不要把它当做累赘，要把它当做化蝶前的蛹蚕。

希望涌现出更多个金刚波。因为CMMI需要。东海蓝帆需要。

毛部长【部门经理】:

写的非常好，希望大家都能用心地思考、总结、分享，一些建议完全值得采纳。希望有更多的人在讨论IT软件技术的同时讨论软件工程技术，业务领域知识，那说明我们取得了不错的成长。

夏刚【首席架构师】:

1.很欣慰金刚波做了这样的思考，里面很多想法和建议很不错，一些内容可以作为cmmi技术评审领域的过程改进建议。

2.最终cmmi是否能够发挥作用——“改进质量，降低成本”，还需要大家群策群力，目前的规范也只是搭起了1个架子，其中肯定会有缺陷和不合理之处，希望能起到抛砖引玉的效果。

3.建议epg尽快将规范改进的流程建议做一次培训，或整理一个过程改进流程的概述，也让大家了解到关于cmmi过程改进本身的改进，cmmi也是有相应规范的，egp欢迎大家提改进建议，也让大家知道如何提过程改进建议给epg，epg如何处理等。

4.思考不息，讨论不息，改进不息。我们这次cmmi过程改进的口号就是——“人人参与，天天改进”。

5.不要为了节约开发成本牺牲产品质量，后面会造成维护上成本的无底洞，本人深有感触。