一种简单的Review效果评估方法——缺陷-投入四象限法

赵同学的第一次开讲就有网红的趋势,他生动诙谐的语言讲解了CMMI各个级别,今天人气讲师赵sir再登讲桌,他介绍的评审评价方法既简单又有效,堪称QA需要掌握的必杀技。很多朋友听我介绍过四象图和九宫图方法,华为确把其运用的非常到位,深领其精髓,值得称道!

常常听到开发人员抱怨说:QA又找我麻烦了,说我写的代码Review缺陷密度太低,达不到质量目标下限,让我重评,难道我的代码一定很差吗?

使用组织过程能力基线来判断代码质量Review评审效果,这本是QA工作的一种常用方法,但如果仅仅使用一个数据就来评判Review效果,未免简单粗暴了一点。难道发现的缺陷密度低就真的不好吗?哪些因素会影响Review效果,如何客观评判一次Review的效果呢?这里给大家介绍一种简单的的评判方法:缺陷—投入四象限法。

先让我们先来看看什么是Review?说简单点,就是多个同行专家对同一工作产品进行检查,以发现其中存在的错误的过程。Review是一种常用、重要、且有效的质量验证(Verification)方法和的缺陷发现手段。在项目开发中的所有阶段,对所有交付件都可以使用,通用性和易用性也非常好。业界关于Review有很多中过程和方法,如审查(Inspection)、小组评审(team  review)、走查(walkthrough)、结对编程等。

Review应该关注四个要素:

  1. 人员成熟度——多个同行专家参加。参加Review的人员应该是对Review工作产品熟悉,并有一定的工作经验的人,其中最好能有几个专家。人员数量不能少于3人(否则意见不同时无法决断),当然也不能太多(意见容易发散,也是对人力的浪费)。
  2. Review投入——需要花费一定时间。Review的时间需要有保证,要充足,确保各Review人员能充分阅读和检查工作产品。投入时间也和被Review工作产品的规模和复杂度有关。
  3. Review规模——被评审工作产品的数量要合适。 单次Review规模要有限制,不能太多也不能太少,要能在有限的投入时间内充分阅读和检查,内容太多则让人没耐心看完,出现一目十行,走马观花的情况。
  4. 发现问题数量——发现工作产品中的错误。通过Review发现的问题数量。这里还有一个问题严重程度(提示,一般,严重,致命)的问题。要注意,一般在Review发现的问题中,各类严重度问题都会有,并且有一定的趋势。Review投入和人员成熟度也会影响发现问题严重度。

我们再来看看业界一些IT公司对Review的要求:

·  任何一次Review最少需要3人,最多需要7人。

·  建议工程文档的Review规模不超过40页。建议代码的Review规模不超过500行(非空非注释行)。

·  组织者应当根据被Review对象的规模及复杂程度为检视者留出足够的准备时间(对Review规模不超过40页的工程文档,建议准备时间为2~3天)。Review会议时间一般为两小时,但组织者也可根据被Review对象的类型及规模来调整。

·  在每次review会议总结时,组织者应得出本次review的结论:通过(本次被review的内容满足质量要求,所有发现的问题得到合理处理后可以交付)或不通过。

要求虽然很简单,但在实际项目中却很少有能被完全满足的。我们在分析Reivew效果时,可以从这四个方面入手,也可以将这四个要素整合成两个指标:Review投入和缺陷率。

·  Review投入:结合人员成熟度和所花时间综合判断。对于一次Review,希望由一定数量的专家花费足够的时间,具体项目需要结合实际情况并参考组织基线,给出Review投入是否充分的判断。

  缺陷率:也就是缺陷数量/Review规模。缺陷率数值一般使用组织基线判断其高低,也可根据项目情况进行定制。

 接下来,我们把Review投入,缺陷率分别作为坐标系的横轴和纵轴,把Review的质量目标和投入充分的参考值标注到坐标系中,并分别垂直于横纵坐标画出一条直线。这样坐标系就被分成了四个象限。(对于不同工作产品的评审,质量目标取值不同,投入参考值也不相同)

一种简单的Review效果评估方法——缺陷-投入四象限法
一种简单的Review效果评估方法——缺陷-投入四象限法

当一次Review完成后,我们统计发现缺陷数,参加人数,投入时间等过程数据,计算出投入时间和缺陷率,放到坐标系中,根据其落入的不同象限来判断这次Review的效果。各象限的分析和建议措施如下表:

象限分析建议措施
第一象限如果落在第一象限(尤其是超过质量目标上限),这种情况说明在投入不足的情况下发现问题较多,可能代码质量较差,需要具体分析,可能有但不限于以下一些原因:  ·  由于模块难度大或作者对业务不熟悉编程经验不足,代码质量差;  ·  检视者对业务理解深刻、编程经验丰富,检视效率高;  ·  编码人员在提交代码走读前没有做必要的检查,如编译通过、PCLint检查通过等;·  缺陷统计不准确,严重级别划分不清楚。·如果代码质量差,需要对该部分代码进行第二次Review;·如果代码质量较差但尚可接受(如在质量目标范围内),考虑增加针对该模块的单元测试用例和/或提高该模块的单元测试质量目标;  ·强调代码在提交走读前必须进行自检;·明确缺陷严重级别划分标准。
第二象限说明在投入较多的情况下发现问题也较多,这种情况的不确定性因素较多,可能代码质量较差(尤其是超过质量目标上限),也可能代码质量正常,需要具体分析,可能有但不限于以下一些原因:  ·  由于模块难度大或作者对业务不熟悉编程经验不足,代码质量差;  ·  检视者对业务理解深刻、编程经验丰富,检视充分;  ·  较多的专家参加review;·  编码人员在提交代码走读前没有做必要的检查,如编译通过、PCLint检查通过等;·  缺陷统计不准确,严重级别划分不清楚,提示问题错填为一般以上问题。·如果代码质量差,需要对该部分代码进行第二次review;·如果代码质量较差但尚可接受(如在质量目标范围内),考虑增加针对该模块的单元测试用例和/或提高该模块的单元测试质量目标;  ·强调代码在提交走读前的必须进行自检;·明确缺陷严重级别划分标准;·质量正常不用采取任何措施。
第三象限说明在投入较少的情况下发现问题也较少,这种情况的不确定性因素较多,可能代码质量较差,也可能代码质量正常甚至较好(尤其是低于质量目标下限),需要具体分析,可能有但不限于以下一些原因:  ·    由于模块难度小或作者对业务熟悉编程经验丰富,代码质量高;·    检视者对业务理解不足,检视效率低;·    参加review人员较少或review人员投入预审时间不足;·    缺陷统计不准确,严重级别划分不清楚。·如果review投入严重不足或review人员对模块不了解,需要调整计划和人员重新review,同时考虑召开介绍会议;·明确缺陷严重级别划分标准;·质量正常不用采取任何措施。
第四象限如果review的结果落在第四象限,说明在投入较多的情况下发现问题较少,这种情况预示代码质量可能较高(尤其是低于质量目标下限),需要具体分析,可能有但不限于以下一些原因:  ·  由于作者对业务熟悉编程经验丰富,代码质量高;  ·  由于模块难度大的原因检视者对业务理解不足,检视效率低;  ·  参加review人员较多;·  缺陷统计不准确,严重级别划分不清楚。·如果代码质量高,不用采取任何措施,甚至在项目进度紧张时可适当减少对类似代码的review投入,同时考虑调低该模块代码在单元测试中的质量目标;  ·如果review人员对模块不了解而提不出问题,需要调整计划和人员重新review,同时考虑召开介绍会议;·明确缺陷分类和严重级别划分;·质量正常不用采取任何措施。

从上面的介绍可以看到,分析过程中虽然使用了很多数据,但还是按照我们的主观想法来就进行分析和判断的,其结果也会受到很多因素的影响,所以在实际做缺陷-投入四象限分析时还需要结合其他因素进行判断,可以采用以下的动作。

·   查看参加Review的人员,是否都是熟悉该业务人员,是否有对应领域的专家;

·   查看Review发现问题的严重级别,看看是否填写准确,否则也会导致缺陷数量的不准确(提示类问题不计入缺陷数量)。如果发现都是提示类问题,或都是严重类问题,则需要进一步检查,以判断Review人员是否对问题严重级别判断标准理解不一致,或是否存在为了达到质量目标而特意修改严重级别的行为。

·   检查Review具体意见的质量,以判断Review人员是否全力投入。如果Review对象是一个复杂度或难度较大的工作产品,而发现的问题都是很简单的表面问题,有可能是Review人员能力不足,或Review时间不够。

·    结合业务来判断,找一个参加了Review的业务专家交流一下,请他对本次Review内容的质量进行总体评价,以印证分析结果。如果专家觉得Review内容质量不高,但分析结果很好的,我宁愿相信专家的意见。

缺陷-投入四象限法是一种简单、定性的分析方法,适用于包括文档、代码、用例等各类项目交付件的Review,能够初步分析出单次Review的效果,为进一步分析指明方向,如果还想深入挖掘原因,可继续使用其他分析方法。

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
返回顶部