通过故事学CMMI——白话CMMI

CMMI的身世

关于CMMI的发展历史，说起来确实非常复杂。早在1984年，美国国防部希望将国防部的软件委派给其他软件公司进行承做。由于没有办法评估软件公司的承接和执行能力，因此委托卡内基梅隆大学软件工程学院（Software Engineering Institute，简称SEI）进行一项研究，希望能够在软件产业建立一套工程制度，用来评估和改善软件开发公司的过程和能力，并协助软件开发人员持续改善流程的成熟度以及软件质量，从而提升软件开发项目及公司的管理能力，最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。

基于此目的，SEI在1986年开始研究能力成熟度模型（Capability Maturity Model，简称CMM），于1991年正式推出了软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM），并发布了最早的SW-CMM 1.0版。经过两年试用之后，1993年SEI正式推出SW-CMM1.1版。

那么CMM又怎么发展成为现在的CMMI了呢？原来，在CMM1.0推出之后，很多单位都先后在不同的应用领域发展了自己的CMMs，其中包括系统工程能力成熟度模型（Systems Engineering Capability Maturity Model, SE-CMM）、整合产品发展能力成熟度模型（Integrated Product Development Capability Maturity Model, IPD-CMM）、人力资源管理能力成熟度模式 （People Capability Maturity Model, P-CMM）等应用模型。

这些不同的模型在自己的应用领域内确实发挥了很多的作用，但是由于架构和内容的限制，他们之间并不能通用。于是SEI于2000年12月公布了能力成熟度整合模型（Capability Maturity Model - Integrated, CMMI），主要整合了软件能力成熟度模型（SW-CMM）2.0版，系统工程能力模型（SECM）和整合产品发展能力成熟度模型（IPD-CMM）0.98版。在随后的发展过程中，本着不断改进的原则，CMMI产品团队不断评估变更请求并进行相应的变更，逐渐发展到目前的CMMI 1.2 版本。在CMMI中文版资料中，用这样的图来描述CMMI的发展历史：

       CMMI的集成达到了两个目的：一是将多学科领域之间的公共过程域进行了提炼；二是减少了过程域的总数量。但是，看到这里，我们会想到另外一个问题：CMMI集成了那么多领域的标准和规范，在实施过程中难道需要全部满足吗？不是的，企业在利用CMMI进行过程改进的时候，首先必须根据自身的主要业务类型和改进目标等，选择适合于自身的规范。例如：从事某个领域软件开发的企业，没有外包和采购业务，那么可以考虑使用在软件开发和系统工程方面进行了集成的CMMI SW/SE。对于需要集成多个产品，或者产品开发受到其他工程影响的企业，可以采用CMMI-SE/SW/IPPD。另外对于涉及到产品的获取和转包方面的企业，可以考虑使用CMMI-SE/SW/IPPD/SS。

CMMI 1初始级

了解了CMMI的身世，我们再来看一下CMMI的不同级别。严格来讲，CMMI级别有连续式和阶段式两种描述方式。虽然方式不同，但所表达的意思是一样的。我们以最常用的阶段式进行描述。先来看下边这个故事：

A公司刚刚拿到一笔订单，公司让小张主要负责开发这个项目。小张是名牌大学毕业高材生，一个人可以几天几夜不休息写出几千行代码，在公司属于大侠级人物。

接到上司的任务，小张不敢怠慢，仔细阅读了项目合同，并和用户方通了电话，仔细询问了用户希望实现的需求。经过一番深思熟虑，他的脑海里已经有了大概的构思。于是，小张打开电脑，开始了他非常熟悉的编码工作。

一周过去了，老板过来询问项目的进展，小张说如果不出意外的话，一个月应该差不多能完成。老板很高兴，夸奖小张很能干。

可接下来的事情并不像小张想象的那么顺利，他突然发现：由于一时疏忽，竟然忘掉了一个很重要的功能；如果将其加进去，需要推翻以前编写的大部分代码。想到已经跟老板夸下海口，没有办法的小张只好连续加班好几个晚上，最后终于把代码修改完成了。虽然经过了这样一次挫折，但是小张感觉还是比较庆幸：幸亏自己发现得早，要不然就死定了。

接下来的开发一切顺利，小张还是重复着夜以继日的编码工作。眼看就要大功告成，小张很高兴得把喜讯告诉了老板，于是老板也很高兴得通知了客户，说下周你们就可以过来看产品了。

用户高高兴兴来到公司之后，当小张跟他们介绍产品时，用户却挑出了很多毛病。原来小张当初没有完全理解用户的意图，此后也没有与用户进行太多沟通，他以为自己已经完全理解了用户需求，因此就按照心目中的想像把产品开发完成了。

看到用户提的那么多问题，小张别无选择。于是，他又开始没日没夜地修改起了代码。这次小张吸取上次的教训，跟用户进行了多次沟通，最后终于完成了产品。但是整个开发进度却延迟了一个月。虽然老板没有批评他，但是小张心里的滋味也不好受，可又能怪谁呢？只能怪自己运气不好，在项目中碰到了这么多倒霉的事情。

真的是小张那么倒霉吗？当然不是，而且他运气还算不错了。按照他这样的开发过程，只发生这两件事情已经是非常幸运了。在开发之前没有完全弄清楚用户的需求，也没有备忘录以免发生遗漏，更没有预先估计风险并采取预防措施，而只是碰运气，走一步算一步，你说能不出问题吗？所以，小张的开发过程还停留在CMMI第一级，也就是初始级的水平。

CMMI 2管理级
如果用CMMI 2管理级水平进行改进，小张的这个项目应该怎么做呢？

在真正动手做之前，先别忙着编程序，应该先考虑一下怎么做才能把事情办好，并且尽可能想得周全一些。我们不妨从下边几个方面帮助小张分析一下：

1、 用户的需求是什么？怎样确保真正理解了用户的需求呢？那就先做个系统的需求调研吧。

2、 为了避免遗忘某个需求，我还应该把这些需求都记录下来才行。（REQM需求管理）

3、 对了，这个功能技术难度太大，要不跟老板申请外包吧。（SAM供应协议管理）

4、 剩下的任务老板让我一个月完成这个任务，我得先计划一下，要是完不成，我得提前跟老板说啊。（PP项目计划）

5、 计划出来了，还不错，可以完成。不行，还不能高兴的太早，我每周还得跟计划对照一下，看计划完成得怎么样。（PMC项目跟踪）

6、 要是我的代码下次也能用就好了，而且以后维护也得用啊，我得找个工具把代码管理起来。（CM配置管理）

7、 老板不太放心，安排了一个人来监督我，呵呵，我做的很好，尽管汇报吧。（PPQA质量保证）

8、 任务完成了，真累啊，不行，我得算算我在这个项目上花了多长时间，加了几次班，遇到了哪些问题，这些问题是怎么产生的，下次的项目我得提前做好打算。（MA度量）

经过了这样的考虑和计划，小张顺利开发完了第二个项目，产品拿到用户那里正式使用了，小张也因为出色的表现受到了领导的表扬。

可是产品上线不久，就因为负荷压力过大引起死机，给用户造成了很大的影响。这个问题迅速反馈到了公司老板那里。老板找到了小张。呵呵，看来小张真够倒霉的，什么事情都让他碰上了，小张百思不得其解，为什么我这么努力，还是出问题了呢？

原来，小张开发完之后，由于测试人员出差，他就自己测了一下，觉得没问题就交给了用户。用户对产品也很放心，认为应该没什么问题，产品就上线了。但由于用户实际使用环境远比小张的开发环境复杂得多，而这些小张之前并没有意识到，也根本没有进行这方面的考虑和设计。所以才发生了这样的一幕。

CMMI 3可定义级
那么小张应该吸取什么教训呢？我们用CMMI 3 可定义级来帮着分析一下。

1、 在了解用户需求之后，编码之前其实还要做很多工作。首先，应该把需求分析一下，看看哪些是功能需求，哪些是非功能需求，如何进行模块划分，不同模块之间会有哪些接口需求等等。由于小张缺少这样的分析过程，也没有形成最终的需求规格说明书，所以他最终还是遗漏了非功能需求，以至于产生上边的问题。（RD需求开发）

2、 需求分析完成之后，小张还应该进行设计，把用户所有的功能需求和非功能需求进行统一考虑，形成设计说明书，然后再进行编码。这样才会保证代码结构合理，并且会全面满足用户的需求。（TS技术解决方案）

3、 在开始编码之前，小张还应该考虑一下不同模块和组件之间集成的顺序，必要的话，还应该跟用户商量一下，根据用户需求的优先级来决定模块组件开发和集成的顺序。（PI产品整合）

4、 为了保证设计和编码质量，部门还应该组织一些经验比较丰富的人员来帮助小张发现一些问题，因此，在开发过程中，还应进行设计评审和编码走查方面的工作。小张自己也应该进行一些单元测试，以便及时发现问题，减少影响和损失。开发完成之后，小张必须交给测试人员进行系统测试，因为自己检查自己的代码往往是检查不出什么问题来的。（VER验证）

5、 测试人员测试完成之后，在产品真正上线之前还应该进行验收和试运行。试运行一段时间，一切都没有问题之后，再将产品正式切换上线。这样即使在这个阶段发现Bug，也不会造成太大影响。为了确保验收效率，小张可以事先准备一份验收大纲。（VAL确认）

在CMMI 3 可定义级中，把以上5项作为工程流程领域，无论做怎样的裁减，这5项都是不能裁减的。它们之间的关系在CMMI 1.2中文版中用下图来表示：

经过这样一番分析之后，小张终于明白：看来自己是少做了很多工作。于是他决定下一个项目一定按照该流程好好做。

小张的项目引起了公司极大重视，为了避免类似问题产生，公司专门进行了以下工作的改进：

1、 公司过程改进部门分析了问题产生原因，找出了不足，并针对不足制定了相应的改进计划。（OPF组织过程焦点）

2、 结合成功项目经验，经过认真分析和考虑，公司内部制定了软件开发生命周期规程指南，同时还制定了相应的文档模板。（OPD组织过程定义）

3、 为了保证各部门相关人员密切配合，团结协作，各负其责，公司公司专门定义了软件开发不同角色以及角色职责，确保各种角色充分发挥其作用，保证整个团队的协作开发。（IPM集成项目管理）

4、 为了减少项目风险，组织了有经验的项目经理和开发经理，总结归纳项目风险，建立部门风险知识库，并要求在项目过程中进行风险管理。（RSKM风险管理）

5、 为避免重大决策失误，成立了专家团，制定决策分析依据，在一些项目的重要决策上，帮助项目进行决策分析，以减少风险。（DAR决策分析与解决方案）

6、 为了便于大家理解和吸收，公司专门组织了相应培训，同时还进行了需求开发、设计、单元测试方面的培训，这些培训使大家受益匪浅。（OT组织训练）

经过这样的改进之后，公司整体的开发和管理水平都上了一个很高的台阶。项目成功的几率也大大提高了，公司还专门请来了CMMI评估师，并且顺利通过了3级的正式评估，客户的订单也就纷至沓来。从这点来说，公司真的应该感谢小张才对啊！

CMMI 4量化级
过了CMMI 3级，公司各方面工作井然有序，一切都很正常。看上去似乎没有什么需要改进的了。就这样过了一年的时间，年底将至，公司正在加紧统计一年来的利润和成本，统计的结果却让人吃了一惊：虽然公司的合同额非常大，利润却不是很多，这是什么原因呢？原来公司虽然在软件开发上做了很多工作，保证了项目顺利的开发完成并上线，但是每个项目的真正数据并没有进行记录和统计分析。一个项目实际花费了多少工作量，产生了多少费用，到底什么项目利润比较大，可复用性比较强，什么项目个性化需求太多，成本比较大，可复用性较弱。这些都没有相应的数据进行支持。

发现了这个问题之后，公司又召开了一次经理会议，做出了如下改进措施：

1、 建立公司内部统一的过程管理平台，所有项目和产品的开发都要通过过程管理平台进行管理；

2、 根据平台的数据积累，公司制定了统一的量化目标以及相应度量活动。（OPP组织过程绩效）

3、 根据公司的量化目标，每个项目定义自己的量化目标，并且定期进行偏差分析，分析偏差产生的原因，制定相应改进措施.（QPM量化项目管理）

经过一段时间，平台中积累了大量数据。每个项目实际成本、项目进度、风险以及曾经发生过的问题在平台上都能够一目了然。在这些历史数据的帮助下，销售人员对项目的报价充满了信心；开发经理做项目计划的偏差率也越来越小，对项目问题的预测和掌控能力也更加强大。这不，公司正准备进军CMMI 4呢！

CMMI 5持续改进级
虽然小张所在的公司刚准备向CMMI 4级发起进攻，不妨先了解下5级也没有关系，它并没有我们想象的那么可怕。5级只有两个域，分别叫组织创新与发展（OID）、原因分析与解决方案（CAR）。这两个域的主要意思，就是在度量的基础之上，选择循序渐进的创新与改善活动，逐步改善，从而达到企业制定的各项指标；同时对发生的问题以及产生的缺陷进行分析，并采取积极预防措施，避免类似问题再次发生。

怎么样，看完这个故事，你是否觉得CMMI离我们并不是那么遥远呢？是不是也已经被我“迷惑”，对CMMI有些痴迷了呢？呵呵，尽管CMMI有如此多好处，企业也有一万个理由应该去实施，但是切不可操之过急。要先考察企业的真正需求和现状，看到底需不需要这些改进，有没有能力进行改进，改进的过程需要哪些方面的配合等等；否则，改进不但不能产生相应的效果，很可能还会起到相反的作用。要知道：企业的过程改进也是一个项目，需要做好充分的准备，并且做坚持不懈的努力

本文来自：我爱研发网(52RD.com) - R&D大本营
详细出处：http://www.52rd.com/Blog/Detail_RD.Blog_xuanny_22098.html