评审活动 #评审 #亚信 #吴平福

摘要：我们在代码上取得的进步，但在影响代码的设计和需求上，需要做出正确的判断。通过评审活动，降低因个人能力可能带来的风险。而评审活动更多的是主观的过程，我们建议采用PPQA督促+工具（DMP，SVN）方式来如实反映评审活动的数据，为提高评审的质量和覆盖率提供科学的依据。

参考：

lDMP评审流程；

lSVN LOG PRE-COMMIT；

l阿里巴巴评审情况说明【孟子】；

l部分度量数据参考：IBMIPD-CMMI；

lDEVOPS；

1.背景

SONAR推广有半年以上时间，在代码质量方面，我们取得了进步。正如一个盖房子，我们具备了熟练的工人，要造出好的房子，还需要在需求和设计上下功夫。软件过程中的评审，正是解决这个问题的重要方法之一。

2.障碍

2.1.时间因素

大家通常疲于应付工作，天天面对各个任务的最后期限，时间被塞的满满的。很少或没有为评审计划时间。

2.2.一团和气

评审发现的问题，内部消化，根据DMP要求填写字段，不能如实反映真实情况。

度量数据作为考核依据，大家不愿意如实填写。

2.3.无法对评审活动和结果进行测量和管理

什么被评审？什么没有被评审？评审有多彻底?有多有效？风险部分在哪里？

2.4.文档长度太长容易提高逃逸率

一个文档太长，有需要在限定时间完成，部分章节被跳过评审。

3.应对

3.1.原则

评审更多的是主观过程，我们主要靠人的监督，辅助工具来完成评审质量的提升。

l允许错误，不允许犯戒【坚决反对数据造假】；

l评审中发现的问题度量数据不作为考核数据；

l引入PPQA作为参与者，监督者，全量全程参与；

l严格控制SVN提交【没有评审ID或问题ID禁止提交】；

l建议最大文档有效内容：20-24页，【参考IBMIPD-CMMI，评审效率10-12页/小时；从人的行为心理学来说，太长的文件评审容易跳过某些内容章节】；

l建议评审时间不超过2小时【参考SmartBearSoftware，超过2小时后，评审效率降低】。评审的确很长，建议中途休息30-60分钟。

l参与评审的人数：4-8人。【人多了，带来太多发散；有的人就是来打酱油的；会议成本很高】。

l文档的确很长的，可以分章节，分层次评审。

3.2.步骤

3.2.1.制定一个月计划

经理必须为评审预留时间。

根据同比和环比，大概可以确定一个月可能的需求，可能的评审。

比较简单的做法：

无大项目状态：本月需求=（同比需求+环比需求）/2。

有大项目状态：采用类比/类推方法，根据上一个类似项目需求时间变化曲线，得到需求时间增长率，计算得到可能的需求数。

评审项识别：在做计划的时候,需要识别出哪些设计/方案/文档是需要评审的, 让PPQA做出评审计划。[w1]

3.2.2.评审内容自己先审查

代码已经可以通过SONAR检查，文档需要比对文档模板。在评审过程中出现格式错误，是不可接受的。

自己觉得审查不够，可以请人帮忙。

这个时候，文档提交到SVN。

3.2.3.选择评审委员

不同的评审需要选择不同角色的评委。在选择评委的时候必须注意互补性。

工作产品类型	建议参与角色
需求规格说明书	需求分析师，项目经理，架构师，系统测试工程师，PPQA，用户或市场代表，文档工程师，业务专家，IT人员
项目计划	项目经理，需求提出者，用户或市场代表，技术负责人，PPQA
架构或概要设计	技术经理，架构师，需求分析师，设计师，测试工程师
详细设计	设计师，架构师，程序员，测试工程师
测试文档	测试工程师，程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试），质量保证代表
源代码	程序员，设计师，维护者，编码标准专家
用户界面设计	用户界面设计师，市场代表，测试工程师

可选内部角色：

l需求分析师

l项目经理

l技术经理

lPPQA

l架构师

l程序员

l测试工程师

lIT人员

l业务专家

l有接口的产品对应人员

l市场代表

l文档工程师

l用户界面设计师

3.2.4.评审内容邮件发送，做到预评审

提前时间参考量：10页/天

注：这里的页数：有效页数。

预评审最低预留时间：0.5天。

3.2.5.评审过程

请根据评审类型的CHECKLIST，客观评审。

评审注意事项：参考评审培训。

3.2.6.PPQA必须参加评审会议，如实记录

CMMI模型进一步强调的是过程和产品质量保证和评价，即PPQA。

PPQA应该参与到评审的过程中。

问题描述：作者，第几页（章节），问题的大小（由评审组决定）

3.2.7.评审录入

发现的问题转换为问题，在DMP录入。评审会议上必须为每个问题指定审核者。

如果问题较严重，可以重新评审（评审组决定）。

3.2.8.文档提交SVN，必须有评审号/问题号。

评审后文档接受SVN监管。

如果向SVN提交文档变化，必须有评审号或问题号。

评审号和问题号来自DMP。

3.2.9.问题跟踪

1 PPQA负责跟踪，在DMP上跟踪。

2 记录解决问题的时长。

3 因为问题修改提交SVN，必须有问题ID号

注意事项：

1.评审中发现的问题而触发的修改，一律以修订模式保存。

2.PPQA检查文档修改结果，确认后审阅通过再提交到SVN。

3.3.评审审查

评审审查是纠正评审中的方向。

3.3.1.根据评审结果跟踪：

业界的通用准则如下：

（1）设计同行评审工作量应占设计阶段总工作量的1/3以上，其质量准则为：设计文档同行评审应该至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，3级80%以上，残留缺陷密度控制在0.5个/页以下。

（2）代码同行评审工作量应占实现阶段总工作量的1/3以上。

（3）同行评审准备过程发现的缺陷数应该是同行评审会上发现的缺陷数的2倍以上。

发现数据偏离公司数据或行业参考数据的，及时了解情况。

如果是确认的数据，进入公司数据。

3.3.2.根据BUG结果跟踪：

可以通过鱼骨图，因果图来判断评审中的质量。

需要指出的，BUG需要追溯到最早偏离点。

3.3.3.在月报上反映

l在评审周报上列出非正常提交的TOP3，并请产品经理分析原因并整改。

l在评审周报上列出下列指标

1.评审文档覆盖率：实际评审文档/SVN上实际文档

3.4.评审奖励

通过积分奖励：

发现一个重大问题：奖励5分

发现一个普通问题：奖励3分

发现一个轻微问题：奖励1分。

多人共同发现，分数均摊。

3.5.文档受控过程

文档提交到SVN即接受监管。

3.6.CHECKLIST更新

由于面对的项目，技术水平差异，建议一年更新一次CHECKLIST。请李小平（总）牵头CHECKLIST更新。

4.评审结果行业参考值

阿里巴巴孟子：review人员有30%责任；阿里希望能够通过流程和机制来消除PM个人能力导致的项目风险，但是目前来看，重大的项目还是不行，一般的需求和项目基本可控。

5.时间计划

时间点	任务	输出物
12月13日前	完成评审工作开展准备；得到领导认可	评审过程文档；
12月14日-15日	分2批和开发人员讨论评审过程	修订后的评审过程文档
12月16日	评审文档再确认	最终评审过程文档
12月17日	工具，接口确认	脚本
12月18日-20日	评审活动推广，解释	活动记录

6.评审培训

评审培训在周末或晚上举行。每个人都要参与，掌握评审方法，技巧。

6.1.主持人培训

6.1.1.对象

每个人都可能成为主持人，每个人都应该参与。

6.1.2.评审设计

主持人要选择评委：选择的角色是否恰当。

选择哪些是重点评审

如何引导评审的方向。

6.1.3.评审准备

包含评审材料，如果准备不充分，延迟评审。

6.1.4.明确评审目标

不要被不是目标的话题转移后不能回来或在某个细节上花费太多时间。

6.1.5.设计方案得到认同时，引导大家讨论方案中风险点

如果讲述完文档，大家都十分认同，而且也找不到任何问题，在这种情况下，主持人应该把讨论转向是否有潜在问题，是否存在风险的话题上。

6.2.评委培训

6.2.1.对象

每个人都可能成为评委，每个人都应该参与。

6.2.2.评委的主观意见

尤其在评审中涉及到界面风格的时候，主观意见很突出。设计者应该说明自己是根据什么规范和什么原则来设计的。

6.2.3.评审意见模糊

这种结论无益结果的改进。

6.2.4.严禁破坏性评审

6.2.5.关注评审内容，而不是评审人

6.2.6.表达个人喜好一定要提前声明

这样既可以让设计师了解到评审人员的直观感受，又避免了上述评论成为评审中讨论的重点。

6.2.7.肯定做的好的一面

一方面是对设计师所做工作的肯定，另一方面明确了哪些部分是比较好的，需要保留并可以继续探索。

6.2.8.不要被设计者的假设条件迷惑

也不是要全面否认，能从历史项目和经验中，发现不正常的假设条件。

7.典型案例[w2]

7.1.一个设计评审

程序员小强接受经理安排，对某个需求编写了一个设计，现在需要评审。

小强该怎么操作呢？

1.小强根据需求类型（项目类型）在公司的文档模板库找到对应的文档模板。

包含:设计模板，设计评审模板

2.小强在了解需求后在模板上编写设计，一共写了20页（有效页数15页）。设计文档必须指明实现了需求的那个章节（功能点）和需求约束（如性能）。

3.小强根据设计评审模板，自己检查注意事项。

4.小强对自己的设计审查不放心，请经理帮忙审查一下。

5.小强从PPQA小田那里得到文档应该存放的SVN路径，并提交到SVN。

6.小强请经理一起确定参加评审的角色，评委清单。

7.小强预订会议室。

8.经理发送邮件，通知参加评审的人，包含评审对象，评审的作者，评审时间，评审目标，评审参考的CHECKLIST。

9.小强发现设计有些问题，以修订方式修改文档，没有提交到SVN。

禁止在发出评审通知后以普通方式修改文档，如果评审时候评委发现文档差异，预评审就失去意义。

10.评委收到通知后，抽空阅读文档，并把自己的意见标注。

11.2天后评审会议在会议室举行（15页/10（页/天）=1.5 =2天）

12.小强心里回顾了一下评审注意事项，开始评审会议。

13.小强花5分钟总体介绍了评审对象，2分钟介绍评审目标。

14.小强根据文档顺序，介绍章节标题，大家根据预审发现的问题，及时提出问题。

15.在某个问题上，大家争论不休，PPQA提醒大家，这个问题花费了10分钟，请先搁置，作为存在的问题，会下继续讨论。技术经理决定这个问题是否还需要重新召开评审会议。

16.大家继续评审。花费60分钟

17.评审对象结束后，评审作者综述评审活动，指出肯定的地方和存在问题的地方。花费5分钟。

18.评委决定该评审的结论：通过/有条件通过/不通过。PPQA记录。花费3分钟。

19.技术经理指定问题的跟踪人员。花费2分钟。

20.评审作者将评审文档提交到SVN（非修订方式）。

21.评审作者在DMP录入评审信息，包含问题。

22.PPQA收到评审信息后，核查信息是否和会议结论一致。

。。。

23.评审对象作者以修订方式修改评审中发现问题，完成后提交到SVN（修订方式）。（SVN LOG需要指明问题编号）

24.问题跟踪者从SVN下载文档，核查问题是否修改。如果问题得到修改，将修订模式取消，提交到SVN。（SVN LOG需要指明问题编号）

25.问题跟踪者将DMP上对应问题关闭。

26.SQA（崇斯田）根据DMP信息，核对度量数据，对发现偏离值40%的评审进行调查。

7.2.问题和讨论

问题：

1.如果是需求评审，该怎么办？

2.如果小强的设计有外部接口，该如何办？

3.如果外部接口存在争论而没有结论，是否应该重新评审。

4.如果评审中没有发现问题，该怎么办？

回答：

1.需求评审的文档模板不同，需要选择的评委角色不同。

2.需要通知到外部接口负责人参与评审，优先评审外部接口。

3.必须的。不过新开评审只需讨论接口。作者应该在会下再设计接口定义。

4.评审主持引导大家讨论可能的风险，假设。时间控制应该在预计会议时间的一半时间。

8.评审度量统计

8.1.第一阶段：产品级别统计

8.1.1.评审覆盖率

以文档为单位统计覆盖率。

1.PPQA统计自己对应产品的评审覆盖率。

PPQA从DMP上获取被评审的文档个数，页数（需求/设计）。

PPQA从SVN上获取被监管的文档个数，页数（需求/设计）。

PPQA计算文档覆盖率。包含文档个数覆盖率，页数覆盖率。

8.1.2.评审发现问题

8.1.3.评审问题跟踪

1.PPQA负责对应产品的评审问题跟踪。

PPQA从DMP上获取被评审的文档问题数据。

包含问题大小，是否解决，解决时间。

评审活动