CMMI v2.0之二 同行评审

今早一金融行业企业CMMI启动会上，发起人（公司领导） 对如何提升交付质量时，便提到过去项目大部分过程中的 缺陷大部分都是后期，例如系统测试时发现， 很多需求 / 设计 阶段的缺陷未在本阶段被发现。 他希望大家加强前期的评审， 如需求 、 设计，降低早期引发缺陷，导致后期大量返工。

我估计这发起人有超过30年的 开发行业经验， 他非常了解有效的评审对质量的重要。

让我们看看CMMI的最佳实践可如何帮助企业做好 “同行评审”：

PEER REVIEWS 同行评审 (PR)

 

CMMI V2.0从V1.3特别抽出“验证”(VER) 中的第二目标“同行评审”作为一个单独的PA。 可见CMMI也认同同行评审确实可以帮助项目预早找出缺陷和问题，减少后面的返工。

 

在V2.0， 大部分同行评审的大部分实践属于CMMI 2级 (分析部分属于3级)。以前在V1.3，“验证”(VER)，包括同行评审， 属于 3级，工程部分。

 

 

 

 

同行评审案例分享

 

越来越多人关注敏捷开发，这几天在杭州的客户现场，刚好就有本地咨询顾问，印度CMMI评估师 和我。 印度老师 除了有20年的CMMI经验外，也是敏捷的导师。有些人误解以为敏捷就是要减轻过程，可以不需要文档，只是把开发做好便可以。

 

这是不对的，这例子说明可以使用一些CMMI的最佳实践，提高无论是敏捷或传统开发。

 

我们在和测试人员讨论他们如何评审测试用例，他们说直接把写好的测试用例发主管，主管觉得可以就可以。其中一位评估组成员觉得不合适，另一位偏敏捷的觉得同行评审测试用例这活动没有价值，可以节省掉不做。

 

印度老师说：同行评审有多个不同的形式，有些较严格，有些较省力，如发邮件去让其他人看。

 

问：对不同的产物有那些不同的评审方法？ 这企业就展示出在项目计划中的一个列表：

 

- 需求 - 需要客户评审

- 设计 - 需要同行评审

- 代码 - 也是同行评审

 

问：同行评审如何定义？ 规定怎样做？

 

这企业不同人有不同的理解，公司级也没有明确定义。

 

老师接着说：如果同行评审是指审查(Inspection)，代码也用正式同行评审是很理想，但可能太费力了，不太实际。

 

评审方法有很多，常见的包括：

 

1  审查(Inspection) - 最正规，最严谨的方法，通常用于重要的产物，比如框架的设计

2  走查(Walkthrough) - 要求低一些，例如 一起开会，把产物投出来一起看

3  最简单也可以是两个人互相查看，或者发邮件

(如想多了解各种同行评审的方法，详见 PR 同行评审 Peer Review*)

 

老师接着说：计划时也要定那些工作产品选用那种评审；例如，像以上那种只说设计/代码都是采用某种评审方法便太笼统

 

他还建议需要有一个项目的质量计划 (Quality Plan)，预先列出对那些阶段的那有产物采取什么方法来评审。 例如：代码评审 - 核心的代码你可能就需要做正规的同行评审。但是如果是一些用户界面那种就简单一点，但必须要质量计划(或项目计划)里面预先定好，然后按照计划去做。

 

最后关于测试用例我们都总结应该要评审的，但是是否所有案例都要评审就看企业需要，起码关键核心的需要做评审。

 

 

用 V2.0 解读上面案例

 

- PR 2.1 制定同行评审的步骤：需要做同行评审的产物的准则？例如 审查(Inspection) 要怎样做；也要包括 同行评审的检查单、模板等，应在公司级制定好。

 

- PR 2.2 选择同行评审的产物：正如案例所说，应该在计划中依据重要程度和预计工作量的经历，预先规定哪些产物需要什么方式来评审？哪些需要做评审；哪些不需要做评审。

评审是要耗费人力/时间，所以针对一些重要的产物，才要花人力评审。

 

- PR 2.3 跟V1.3 的 VER 视频。2 差不多，同行评审的准备和记录， 把所有发现的缺陷和应对措施都记录下来。

 

- PR 2.4 是新增的,以前v1.3没有。同行评审最重要的就是跟踪缺陷，所以必须跟踪所有缺陷，直到被关闭。缺陷的跟踪中，有些缺陷在同行评审中就已经被解决，但对需要后面处理的就必须记录下来、进行跟踪，制定一个通过标准。

评审最大目标是找出问题，所以特别加这一条，要解决那些发现的问题。

 

 

分析并提升(PR 3.1)

 

从不同维度来做分析，例如：同行评审缺陷源自那个阶段？哪类缺陷较多；缺陷的原因等等。从这些分析就可以帮我们判断哪些同行评审方法最有效，利用同行评审尽早找出缺陷。

 

 

利用系统再进一步提升

 

很多开发团队都会使用系统和自动化提高质量与生产率。 

 

例如，测试如果还是用手工的话，你应该想如何开始用自动化测试？

 

你可以想，我们很多时候测试用例需要复用，回归测试。如果靠人工去回归测试，很耗时间，效率很低。所以无论是国外还是大陆比较做产品的公司都开始做使用自动化测试，这也是利用系统可以帮助我们做真正改进的一个例子。

 

如果一个公司以测试人员能力不够，时间不允许等为借口，这类公司是很难有真正的提升。

 

所以另外一个我接触的顾问，他每次都会问客户：你现在有没有用自动化测试？如果没有的话，他会说为什么你不做？

 

我们也合作在杭州做一个很好的敏捷试点，也是利用了自动化测试加上一些度量，确实无论对质量和生产率都有了显著的提升。

 

同样思路，很多团队都开始使用自动代码走查工具来检查代码问题。

 

但核心代码 还是要有经验的人评审，自动工具代替不了。

 

PR 同行评审 Peer Review链接如下：http://mwiki.processis.com/agile.cmmi/index.php/PR_%E5%90%8C%E8%A1%8C%E8%AF%84%E5%AE%A1_Peer_Review

也欢迎联系我们来获得相关资料。

联系我们

电话：18921395967

QQ：1228021190

微信：processis2009

地址：香港/北京/江苏

官网：www.processis.org