资深CMMI高成熟度主任评估师任甲林老师在前两周进行了一场主题为“你真的了解CMMI吗”的精彩直播，在直播中也对大家关心的一些常见的CMMI问题进行了答复。本文摘录了部分话题，干货满满，希望对大家深入了解CMMI有所帮助。

Q：申请CMMI评估，流程是怎样的？

A:CMMI的咨询评估流程可分为以下两种：

• 瀑布的做法：需要先成立一个团队专门做过程改进，一般称为EPG（工程过程组），也有人称之为卓越绩效组。然后梳理公司的实践，和CMMI做映射。看下哪些要求是已经做到的，哪些是没有做到的。映射完之后就要找How to do。识别完How to do后要通过流程、体系和规章制度将它固化下来。接下来就是在公司内部宣贯，要求大家养成习惯。等推广到差不多了，觉得可以满足CMMI要求了，就可以申请做评估了。评估师会先看看，大概了解一下水平到底怎么样，然后准备评估。

• 迭代的做法：每三个月做一个迭代，每一个迭代来改进一个或几个问题，通过几个迭代，自我感觉可以通过评估了，就直接申请评估。我们公司做CMMI评估，一般改进的总时间如果超过一年了，就建议公司用迭代的方式来做。

Q：CMMI评估对项目大小、数量有要求吗？

A:没有要求。

从项目规模上而言，对项目大小是没有要求的，我在咨询评估的生涯中遇到的最小的项目是项目中只有一个开发人员，以及其他兼职的QA等人员；我也曾遇到过一个项目就投入了160个人的。

从企业的规模上来讲，也没有大小之别，我做到的最小的一个公司只有5个开发人员，大的公司可能动辄上千人。

从项目数量上来讲，小的公司可能只有1个项目，大的公司几百个项目，都是可以的。

Q：商业银行的科技部门申请做CMMI需要做哪些准备工作，和软件公司有什么不同？

A:基本没有什么不同。主要区别在于商业银行会有外包，表现在银行内部的员工主要做需求、项目管理等工作，而开发、测试等工作主要是由外包团队来完成。在这种场景下，我们做评估的时候，需要把供应商管理的PA也纳进来，放进评估范围内。

Q：软硬件结合的公司怎样更好地融入CMMI的流程？

A:在软硬件公司中落地CMMI的时候，有一个较一般软件公司而言不同的地方，在于他们定义整个项目的产品研发生命周期流程的时候，是以硬件的流程为主。

比如一开始我有一个设想，先做设计，其次进行实现，然后出样机，接下来做小批量、大批量生产。所以软硬件结合的项目在落地的过程中，与纯软件的项目来比较，最大的不同就在于，软硬件结合的项目是以硬件为主定的生命周期，并且从总的生命周期上来讲，这是一个大的瀑布，软件的生命周期实际是附属在硬件的生命周期上的。在这种情况下，其中软件的部分也可以采用迭代的方式来做，也就是说在整个大的生命周期中，将某一段采用迭代的方式来实施。

如果我们把硬件纳入进来，其实硬件的规模估算和软件的规模估算不一样，硬件的验证、确认和软件的验证、确认又不一样。这些地方会从技术方面有一些差别。但如果我们把主流程统一，剩下的部分其实会比较好处理。

Q：硬件的规模如何度量？

A:如果我们设计一个板子，那板子上面新器件的个数、管脚的数量、板子的层数、板子面积（台式机的主板和手机的主板）、通风口的位置等等，这些因素都会影响工作量。

我们为什么要度量规模？其实是为了估算工作量。所以从本质上来讲，这需要我们看在整个过程中，有哪些因素影响了我们的工作量。我们有一个客户，他们通过度量数据证明管脚个数和工作量是不是强相关的，如果是强相关，可以用管脚个数来代表规模。

那么硬件有没有一个行业度量的方法？据我了解，还没有一个大家都认可的规模度量，是需要大家在实际中不断摸索的。

Q：CMMI不提供流程指导，它是不是一个对其它流程辅助补充的类似实践库形式的存在？

A:CMMI就是一个实践库，里面的实践没有一个严格的先后顺序。比如说用RUP定义流程、基于Scrum来定义流程都是可以的，只要能覆盖到CMMI的要求就可以。

Q：CMMI2.0Dev中20个核心实践域的关联关系可以详细讲讲吗?

A:20个PA可以分为四大类：

第一类是（Doing）工程类：Doing类实际上映射为工程活动，需求设计、编码测试、同行评审……

第二类是（Managing）管理类：比如做估算、做计划跟踪、做风险管理。管理类需要再细分，管人、管事、管风险、管不确定性……

第三类是（Enabling）支持类：比如决策分析，原因分析……

最后一类是（Improving）改善类：比如EPG，按照PDCA循环持续改进。

所以20个PA可分为这四大类，这四大类基本把开发有关的活动都覆盖到了。

Q：CMMI的成熟度级别如何定义的？各个PA域都有级别的区分吗，还是某个级别必须实现某些PA域？

A:在CMMI2.0中，它定义了每个PA都有1级、2级、3级、4级、5级的实践。有的PA最高能到5级，有的PA最高到4级。CMMI1.3将PA划分了等级。在CMMI2.0中，是把实践划分为了等级。实际上是更灵活了。

在企业当中进行评估的时候，也是分了两类等级。一类是成熟度等级，还有一种是能力等级。能力等级在我们实际当中遇到的评估比较少，能力等级评出来的PA最高是到3级。

能力等级和成熟度等级的差别在哪呢？成熟度等级就像是套餐，按照已有规定来做。能力等级更像你在单点，就想吃这个菜，我觉得这个做不好，就专门评这个PA。能力等级最高到3级。

Q：假如不用任何流程，只有最小集合的实践，这几个实践做得也挺好，能通过CMMI评估吗?

A:是不行的，想要通过CMMI成熟度评估的要求是目前公司的流程覆盖了CMMI的要求。如果说参考了CMMI，我有实效，这个说法是可以的。其次，我们要注意为什么要求有流程？

第一点我们要注意的是，在公司内部，我们只要有一个固定流程来做事情，同时定义了这些活动的先后顺序，那么这个流程就是客观存在的，只不过区别在于这个流程是可重复的流程还是一次性流程。

第二点就是这个流程是只存在于头脑中还是已经文档化了？如果我们的流程不需要文档化，就能够养成习惯，形成一个固定套路。比如说我天天做西红柿炒鸡蛋，这个流程并没有规范的文档，但我已习惯性地按照第一步加盐、第二步加糖的步骤来进行，那这就是约定俗成的流程。但如果我想让不管是谁来做都能做出一个味道的西红柿炒鸡蛋，那这就会有一个问题：每个人的流程不一样，炒出来菜的质量也会不一样。那我们怎样来保证这个味道一样呢？那就需要文档化的流程。文档化流程的价值在于把我们的经验教训汇总起来，形成一个固定套路，让成功可重复。

Q：CMMI从2级做到3级给公司带来的最大价值是什么呢？

A:第一点是更完备了。2级只侧重于项目管理，3级则把工程活动也包含进去了，包括需求、设计、编码、测试等规范。同时，3级也建立了组织级的持续改进流程。

第二点是从项目级的水平提升到了组织级的水平。如果你是项目经理，把2级的这10个方面都做到，就到达2级水平了；3级则是整个公司统一定义的流程，如果把3级的20个方面都做到，就到达了3级的水平。

Q：CMMI4、5级的量化级如何开展？

A:回到最初CMMI2.0的要求上来，就是围绕目标做改进、围绕目标采集数据，分析数据中隐藏的分布规律、因果规律。分布的规律说明了我们当前的水平是什么样的；因果规律，刻画了我们为什么是当前这个水平，影响因子是什么。然后我们通过找到影响因子去做出改变。做CMMI4、5级，是要通过数据让帮助我们来去巧干，帮助我们四两拨千斤。

3级的完备性已经到顶峰了，4、5级是用数据来刻画公司的现状。数据可以让你清楚什么是对的，什么是有价值的，什么是效率高的……这就是巧干。

Q：CMMI是评估公司还是评估项目呢？

A:CMMI评估的是公司下的部门（从部门里抽某些项目来参与评估）。CMMI的结论一般是某某公司某某部门通过了CMMI成熟度3级评估。同时，在评估部门的时候，不管是大部门、小部门，还是单部门、多部门都可以进行评估。

Q：CMMI评估，一个部门通过可以代表整个公司通过了吗？

A:不可以，还是按照部门来评估的。如果公司有10个事业部，只给一个事业部做评估，通过的话只代表该事业部达到某一水平，无法代表其他9个事业部都到这个水平。

Q：很多组织通过了CMMI评估后就把相关的体系流程执行变形甚至放弃，如何避免这种现象？

A:这一问题还是应该回归到做评估的目的：是为了商业目的还是为了实效改进。如果说在评估后，整体水平稍微降低了一些（原基础水平是0.8，评估后从1.0降低到0.9），这个是可以理解的。但如果评估后退回原有水平（原基础水平是0.5，评估后从1.0降低到0.5），这就是我们应该去反思的，也就是说评估后的水平和原有的实际水平相差太大，所以等评估后，会觉得又降低到了原有水平。

这个问题我们在公司内部也讨论过，我们的顾问给客户做完咨询后，给客户留下的是什么？从本质上来讲，我们的顾问咨询完了，应该留下来的是能够改变客户的人。如果只留下了流程，没有留下能够改变客户的人，那这个咨询其实算失败。我们需要改变这个人的思想、改变了他们的行为，这个才是有价值的。所以现在在我们公司里面，我也会要求我们的顾问去关注如何改变客户的人。比如EPG是和我们打交道最多的人，我们首先要去改变他们，将思想的种子留下。这意味着即使我们结束咨询，EPG还可以再去改变项目经理、开发人员、测试人员。

那在短暂的咨询期间，想要真正改变一个人其实很难。在这种情况下，我们要想去改变人的思想，需要采用迭代的方式，通过手把手的教、重复训练多次来逐渐改变他们。先定一个小目标，通过小步快跑的方式在咨询期间把3、4个措施真正落地。或者通过多年的陪伴，来陪伴客户成长。

Q：希望客户改变成什么理想状态好呢？

A:我们是希望客户能具备持续改进能力，就算离开了咨询顾问，他们也可以发现自己的改进点，从而找到How to do，把它变成现实，固化下来，并用定量的数据来去刻画效果。如果离开了顾问，还能持续改进，就挺好的。如果离开了顾问，今年的水平和明年的水平一样，甚至还退步了，那就有问题了。

Q：QA质量保证的价值如何体现？

A:QA是一家公司内部质量文化的传承者，确保公司内部能够形成质量文化并传承下去。那应该如何传承呢？是需要通过文档化的体系流程、人员示范等来传承，需要QA来做监督、检查。

那QA的价值应如何体现？会有如下三个层次：

♦第一个层次的QA是警察，发现你违章便给你开罚单；

♦第二个层次的QA是医生，能够为你诊病治疗；

♦第三个层次的QA是教练，可以事先提醒，起到预防的作用。

大家可以看一下自己公司的QA是处于什么样的层次，是只能开罚单，还是能够帮公司发现问题并治疗、改进，或是能够帮助公司提升能力、预防风险？我们的理想情况是希望QA都能够发挥第三个层次的作用。

那对于一些QA没有一线项目经验等问题，我们有个来自北京的客户，他们公司的实践提供给大家参考：如果一个项目经理或开发人员要被提拔了，需要先到QA部门任职半年。也就是说，大家要有QA的从业经历才能晋升，来弥补QA人员没有一线经验、管理人员没有QA视角的缺陷。

Q：实际项目里如何利用好CMMI里的文档模板？能用到里面的百分比多少？

A:CMMI没有模板，咨询师有。最好还是根据自己公司的文化去定文档。文档可以是正式或者非正式的照片都可以。不同的公司文化差别很大，体系的复杂度也是不一样的。

Q：能否将用户需求、软件需求、业务需求合并，减少这些文档的数量？

A:我们一般会将需求文档分为用户需求和产品需求（具体叫法根据公司实际有所不同）：一类是面向客户，用用户的术语来表达的需求，我们称之为用户需求；另一类是开发人员理解用户需求后，用技术的术语来表达的需求，我们称之为产品需求。如果想把这两个需求文档放在一个文档里面，是可以的，CMMI评估也是认可的。

我们拿UserStory来举例，UserStory包括角色、功能、目的三段论。如果仅仅描述了这3部分，我们可以认为这是一个用户需求，这个需求粗略地说明了“我要什么”。产品或开发人员通过需求细化，来形成验收标准、实例化需求，通过原型来把需求具体化。这个时候这个需求我们就可以称之为产品需求了。那如果我们把这两种需求都放在一个Excel表里，前三列是角色、功能、目的，后三列是验收标准、优先级以及界面原型。我们可以将这种形式的需求称为需求定义，在评估的时候完全可以这样去评估，也能够通过评估。

不过我们需要去思考的一点是，即使合到一个文档里了，我们是不是也需要站在用户的角度来描述需求，然后站在产品的角度、开发的角度，把需求做细化？所以尽管我们放在了一个文档里面，还是会有两个侧重点。

当然，还有的公司会更往前延伸，描述业务背景（我原来是什么样的？我原来的作业是如何做的……）等等。所以，需求描述的概略、详细程度不一样，可能最开始描述比较粗，随后会一步步细化，可以将它分成多个文档。有的公司有可能会写3、4份文档，这些都是可以的，都非常灵活。

Q：问题跟踪表、风险表、机会表，这几个能合并吗？

A:首先，我们需要把概念区分开。问题跟踪是已发生了，发生的概率已等于1，已经成为客观事实。所以对问题，我们只要去找应对的措施，去关闭它就OK。风险是可能发生的坏事，我们在风险没发生之前，去预防它的发生，采取的一些预防措施。机会是我们预料之外的好事，我们也要去跟踪它状态的变化，我们可以提供一些便利措施使这个机会能够来临，或者机会一旦来临了，我们要采取措施抓住它。

所以这三个概念先区别开，你再看看在你们公司中能不能合并。如果单纯问能不能的话，那肯定是可以的。如果你问提倡不提倡这么做，我是不太提倡合并的。

Q：CMMI与IPD流程的区别及侧重点？

A:IPD是定义了主流程，定义了生命周期模型。CMMI只给了实践。如果落地IPD的时候，需要再去定义自己的流程，把IPD大的阶段划分，再做细化。当你做细化的时候，这时候就会用CMMI的实践帮你填充流程。