CMMI入门 - 由来与思路

在80年代CMM开始的时候，我还记得当时的软件项目真的非常混乱，经常成倍地超支、超时。失败被取消的比完成开发，有产品交付的多好多。那个时候完全是靠员工的能力。个别员工能力水平，就是大家都具备成功的开发能力，也可能相差十倍。所以软件项目的成功是不可能保证、不可重复的。

这样的状态，对美国的国防部来看，是不可接受的，因为武器越来越多地依靠软件。每一个国家都不能接受不可靠的武器。所以美国国防部作了许多努力，包括制定一系列的质量标准，定义了一种语言（ALGOL）。其中最能帮助提高软件项目成功率与软件质量的，就是CMM这个软件工程的改进模型。开始的时候，模型只包含软件开发，后来加进来系统工程的要求，就变成了CMMI。

有些人认为CMMI是软件开发与硬件开发的集成。其实系统工程包括考虑硬件在整个产品的配合，所以CMMI有一些产品整体的考虑，尤其是产品集成方面。但CMMI里面没有真正地针对硬件的议题。项目的硬件部分已经比较成熟，不是武器产品的短板，美国国防部知道如何管理，所以重点不在硬件。CMMI其实是软件与系统工程的集成。

CMMI的由来，在于提升软件工程的水平

所以开始的时候，CMM的一个目标就是如何帮助软件项目，后来变成了产品项目的系统与软件部分提高管理能力，从而提高软件项目的成功率，与产品的质量。CMM的重点，一开始就放在“帮助提高”软件业界水平上面。而且当时的软件项目管理水平很低，所以CMM模型的重点是在于如何从一个低下的软件管理水平，发展成为高效的管理能力，保证产品的质量。这一点对了解CMMI非常重要，也是CMMI独特之处。

CMMI有哪些独特之处？相对ISO/TL9000，PMP， 6 Sigma 等等改进模型与方法，CMMI的目标是能让企业逐步提高水平。因为要让人家知道如何“逐步”改进，所以CMMI模型就有明显的“次序”的概念：第一步做什么，第二步做什么，等等。这与其它任何模型不同。ISO/TL9000制定了一个标准，要求企业达到这个标准就好了。PMP 的重点在于项目管理，这方面的要求比CMMI里的更详细。但还是一组的标准。6 Sigma使用了两个生命周期模型，（一个是开发，一个是改进）来组织一系列的方法与工具，让企业知道如何高效地处理那两种项目的活动。这些模型，相互并不冲突，并没有不一致的地方，大家都是为提高或是保证过程的效率而设。任何企业都可以混合着使用。其中只有 CMMI 从一开始就具备这样改进次序的概念。

后来TL9000也参考了CMMI 的内容，并且希望帮助企业不断地提升质量，但是因为它的模型结构没有“次序”这个概念，它只能每年提高认证的标准，作为驱动企业提高的动力。这个当然不很好。我就在一次TL9000的技术会议中提到这样有问题，因为这样下去，就很难让新企业得到认证，因为对他们来说，门槛已经越来越高了。这样不但减小Quest Forum（TL9000的负责组织）的收入，同时让新企业望而却步，削弱了TL9000的影响力。我当时的提议就是把认证分等级：比如一等TL9000认证，二级认证，等等（是不是跟CMMI很像？）。后来我离开公司之后，就没有再参与Quest Forum 的活动，不知道后来的发展了。

我们可以说，CMMI的由来，就是当时的企业软件产品项目管理水平比较混乱、无序，需要一个方法，帮助企业逐步提高这个管理水平，到达可以制度化地、系统性地、自动地不断提高的成熟水平。

项目管理的状态

举一些70年代后期以至80年代中期这段时间的项目案例：我知道有一个软件产品项目是没有文档的。需求的文档没有。领导只有一个概念，这个软件需要自动控制炼钢过程的化学成分，并提供各部门科室所需要的纪录与报告。这就是全部的需求，并且只存在于小数几个人的脑子里，而且每一个版本（每个人的想法）都未必是相同的。产品的实施方案呢，也就只存在于项目经理的脑子里。就他一个人知道如何实施。还记得当时的观念，就是这个项目经理是神，法力无穷：这么复杂的系统，千丝万缕，任何细节，手到拿来，并且把任务分配下来。团队都是电脑专家、开发高手。大家都认为这样的人才才算有用。后来进展不理想，高层就请来一位专家来审核项目，发现检查不到任何文档纪录，他的报告就是项目缺乏文档，没有任何可以让其他人了解情况的信息与机制，是一个绝对不透明的项目，不能做任何风险的判断，项目的成功没有保证。这位项目经理虽然有才，但是完全没有项目管理的理念。等等。

无序的软件项目管理当时比较普遍。当然也有做的比较好的。在IBM等有规模的企业在这方面就比较好。反而贝尔实验室当时还比较依赖人才与技术。

在这个年代，如果一个软件项目，有一点点地可视性，就已经是非常卓越了。比如另外一个项目，它的项目经理在项目中也像一个神一样，是项目的灵魂。但是他比较重视策划、文档，让项目的进度有一定的准确性。但是因为是软件项目，大家还是认为这位项目经理是无可替代的。

后来这位项目经理要请一个月的假，到北极去旅游。公司的高层非常害怕他的缺勤会造成项目的风险。但是他信言旦旦地保证，因为项目管理做得好，项目的运作不会受影响。后来一个月后回来，项目的进度，真的如他所说的按计划开展。这是一个比较成功的项目。

总结一下，当时以下的问题在软件产品项目中非常普遍：

不知道要做什么？没有需求。
版本很混乱，经常遗失完成了得修改。构建版本非常困难、吃力，等等。
没有准则判断项目过程中的进展与质量。高层很难掌握项目情况。

在这种情况下，开展一个软件产品项目就有点像×××一样：不知道开出来的是大还是小？

从上面的案例，很明显，改进的思路应该是从管理入手。只有在有序的情况下才可能进一步研究如何提升软件管理的水平，帮助软件项目变得更成熟，更能保证软件产品的质量。CMM的目的就是如何提升软件工程水平的问题，而不是简单地制定一个标准：比如：项目需要有文档之类的要求。因为就是要求有文档，也不知道需要哪些文档。

另外一个问题就是在这么多的项目活动之中，如何整理出来一个可以提供指导作用的框架。当时有些企业在这个领域已经开始努力。贝尔里已经知道项目大概需要30%项目的工作量放在测试方面。也记不清楚是否IBM发现提高项目计划的准确性，在于让员工自己估算任务的工作量。分析的结果，就是员工自己估算可能提高了员工的承诺意识，让员工更能认同、主动、积极。

所以SEI 就召集了业界的作的比较好的企业专家，一起研究提高软件工程能力的工作。他们的工作其实就是从一大堆零散的经验与最佳实践之中，整理出一个系统性的机制，适合一般的软件企业提升能力之用。

过程域：既相互独立，又相互关联

面临的问题，当然是项目的活动这么多，又如何整理、组织这些零散的经验呢？我们知道这个分析的结果就是过程域这个概念。过程域就是一些相关的活动。问题是，这个“相关”又是如何决定的呢？同时，如果真的明确了不同的过程域，那么，不同过程与之间，又是否毫无关系呢？这里就有一个我希望大家能理解的概念：很多事情都是既相互独立，而又相互关联的。比如母亲与婴儿，当然是两个独立的个体。但同时，婴儿依赖着母亲，母亲也牵挂着婴儿。这种关系，到处都是。过程域也是一样。

项目到底要做什么？我希望大家知道：项目的使命就是要实现需求。就是说，项目需要知道要完成什么。知道了要做什么之后，要找到一个可行的方法。然后指定一个如何实施这个满足需求的方法的步骤与安排。这就是计划。领导也需要保证各个项目成员都是朝着既定的方向，合适的进度开展活动。这就是监控。所以我们可以看到，项目里比较项目独立的活动组包括：理解需求并为满足需求开展活动；需要制定计划实现需求；并且需要监督、保证活动进展是合适的。这就是“需求管理”，“项目策划”，与“项目跟踪与监控”。这些都是相对独立的。知道要做什么，与策划如何去做，是不同的，是相互独立的。也是相互关联的。监控进度，也不是策划活动。但是策划与需求是由依赖性的，监控的依据就是计划。所以，不同的“过程域”都是相对独立，但在项目活动的开展角度来看，也是相互依赖与相互支持的。

项目必须实施的活动，都可以划分到上述的过程域里。在同一个过程域里的项目活动之间，都是关联非常密彻，因为它们都是同一个项目任务的一种活动。

过程域让我们可以组织零散的经验。比如，上面提到的员工自己估算自己的任务，是一个有效的方法。但是作为一个零散的事例，作用可能不大，很可能不能提供应有的价值。但是如果我们知道估算是“策划”这个过程域的一个环节，它的作用在于更好地建立进度安排，这个活动的价值就更明显，它的意义就可以更有效地帮助项目策划如何实现项目的目标。这样就更能系统性地研究、分析过程的特征，提高项目的效率与质量。

过程域之间的依赖关系

把项目的活动组织成过程域之后，就要考虑这些过程域之间的依赖关系。比如，需求管理这个过程域，与需求开发这个过程域有什么关系呢？我们第一个反应就是：如果没有需求，我们就不需要管理它。所以，需求开发是基础，需求管理依赖着需求的存在作为基础。这当然对。但是这是从实际操作的角度看问题的结论。

CMMI的重点不在于项目的操作，而是在于如何帮助提升项目的效能。CMMI的作用，不在于某一个项目是否成功完成，而是企业如何把大部分的项目管理到能够成功完成。这个分别非常重要。我们经常以为知道如何做了一次，就会知道如何做大量批次。就好像做了一个样机，就知道如何生产一样。这是不完全对的。

做了一次，做了样机，只是解决了技术问题。一次与经常、样机与批量之间的分别，是管理。CMMI重视的，是软件工程的管理能力，而不是技术细节。CMMI这个模型的重点，在于改进，而不是在于规范。所以，CMMI的角度，认为如果项目不重视需求，不以实现需求作为项目的使命的话，需求开发能力的发展是会比较慢的。不是不可以发展，但是发展会遇到很多困难。这样的看法，需求开发是依赖于一个重视需求的环境这个基础上的。

如果能够理解CMMI的含义，那么，项目就要关注需求，把它理解清楚，把它的变更管理好，项目才能按需求开展工作。但是如果项目不关注需求，就很难吸收或是培养系统工程人员来进行需求开发的工作。这是一个对CMMI的真正理解非常重要的概念。

通用实践：习惯才是能力

CMMI 的另一个特殊而重要的概念就是“通用实践”。顾名思义，通用实践就是一些在每一个活动都需要做的事情。比如：无论我们是在做项目，或是去旅游，甚至是青年男女要结婚了，又或是最近的国际局势，要撤侨了，等等事情，都应该有一些“计划”。有些事情需要计划的详细一点，有些可以粗一点，紧急的事情只能由很少很短的时间做计划，甚至要计划一点点就做一点点。但总得有计划。这一类的活动，就是CMMI的“通用实践”。

听起来通用实践就有点像“习惯”。CMMI在告诉我们，个别的、一次两次的表现，不足以构成真正的能力。习惯才能体现真正的能力。高效的行为，需要不断的体现，在所有的活动中体现。这样才会提升能力。

等级：打好基础、循序提升

既然CMMI的重点在于“改进”，那么，把活动组织成过程域，然后提供了每一个过程域如何如何做好，还是不够的。在这么多的不同的活动，要如何开始呢？要先做什么，然后再做什么，就变成了一个“改进”需要解决的问题。留意，一个标准、规范，好像ISO/TL等，是不需要考虑这个改进的次序的。这是CMMI特殊的地方。CMMI提供的特殊思路，就是“等级”这个概念。

刚才提到从“改进”的角度看，一些过程域是其他过程域的基础。CMMI就把这些过程域分成不同的等级。过程域包含的活动越基本，过程域就被安排到越低层次的等级。高等级的过程域，里面的活动，它的改进（是改进，不是实际操作）需要低等级的活动作为基础，才能有效。就是说，改进需要从低等级的活动开始。这是CMMI的一个关键的价值，也是CMMI最特殊的地方。那么，这些等级是什么呢？

大概来说，CMMI有五个等级。我们先不要太关注成熟度、能力、等的分别。这个议题我打算将来再在一个专题文章中比较详细的讨论。我在这里，先讨论CMMI模型里面的等级概念与这些等级的含义。这五个等级就是：

第一级：先关注完成这个过程任务。比如：管理好需求、做计划、监控进展，等等。这里谈的，主要是过程的活动，而不是员工的任务。在这里做一个提醒。
第二级：然后在项目的层面，做到规范和形成制度。
第三级：从项目收集做得有效的做法，总结、组织、整理，形成标准的规程向整个企业推广，让所有项目相互参考最适合的经验。同时提升工程技术方面的效能。
第四级：因为项目通过标准规程，相互学习，效能不断提高，做到过程的效能稳定，可以建立过程效能的基线与模型，达到量化预测项目结果的水平。
第五级：体制具备制度性地参考业界与内部经验，找寻过程问题的根本原因，系统地、持续地改进过程的能力与质量。

大家是否能够看得到每一个级别的改进，都需要所有下层级别的支持？我观察到在中国的CMMI实施，大部分都不能收到提高项目效率与产品质量的结果，就是因为我们的实施，很多都没有符合CMMI的本意。我们只是关注了CMMI之中形式的部分，而忽略了关键的含义。比如：在技术方案的过程域里，CMMI要求有多个方案以供选择。我们就看到了需要两个或更多的被选方案。这个还不容易：就给你两个、三个方案。但是我们忽略了一个现实：我们本能的强烈倾向就是相信自己的第一个方案是最好的。因为如此，往往忽略了一些需要考虑的因素，或是用另一个角度考虑问题。这样得出来的方案可能可以，可能根本上就不行。无论如何，这个方案作为最适合的可能方案的机会不高。

CMMI的要求，其实是希望大家用多角度来考虑问题。但是我们坚持自己得的第一个方案，然后进行一些小改交差。这样就不会得到CMMI要求的好处了。如果要明白CMMI的意义，就需要能够看明白CMMI的要求背后的理由。CMMI要求的，不是如何去实施，而是要考虑哪些问题。

认证是推广CMMI的重要手段

SEI建立了CMMI模型，提供了一系列的培训教材。建立了一个技术转移伙伴（Transition Partner）网，来进行推广。其中也应用了一批由SEI亲自训练与监督的主任评估师队伍，为SEI做CMMI等级的评估工作。SEI对这个机制要求越来越高，希望保证CMMI等级的含金量。

但是中国的教育制度，让大家非常熟识如何通过任何考试形式的活动，而不一定需要真材实料。这个能力，让我们不能得到CMMI可能提供的价值，虽然我们花费了很多资源与精力。大部分从事过程改进的员工本身经过好几年的辛劳，也得不到明显的提升。这是非常可惜的。

一些感想

CMMI的由来，在于帮助软件产品项目改进过程效率与质量。CMMI 模型的形成，是总结零散的经验，从其中把重要的关键因素抽象出来的系统性结果。在CMMI这个模型的等级定义里，也明显地要求先在项目里管理好项目，才把项目中积累的经验，组织成为标准规程，在企业中推广。所以在实施CMMI的时候，也应该从项目的实际操作中观察到一些好的做法，然后再把它们组织起来，编辑成为企业的标准规程。这样的事件要求比较长一点，但是项目的确可以得到CMMI的实际帮助，提高过程效率与质量。

转载于:https://blog.51cto.com/mk6yeung/509358

CMMI入门 - 由来与思路相关推荐

CMMI入门-通用目标的实施- GG3
CMMI入门-通用目标的实施- GG3 如果我们说CMMI第二级是范围地把项目管理好,那么,第三级就是进行改进与提高效率.第二级的内容,主要是一些项目的先决条件与工作的举措,让项目可以高效完成与满足目 ...
关于“数据分析”如何快速入门一些基本思路
数据说·思维季树上的果子,一旦熟透了,马上就要坠落.凡事总要稍留欠缺,才能持恒.--莫言前言对数据敏感,能够通过"数据分析"发现业务层面提升的机会,是很多企业对产品.人力.运 ...
CMMI入门 - 通用实践的实施GP 2.1-GP 2.5
CMMI入门 - 通用实践的实施GP 2.1-GP 2.5 上文<CMMI入门-通用实践简介>讨论了CMMI通用实践的意义与对过程有效性的重要性.我建议在讨论通用实践实施之前,先从那里了解 ...
CMMI入门 - 通用实践的实施GP 2.8-GP 2.10
CMMI入门 - 通用实践的实施GP 2.8-GP 2.10 在整个CMMI 的GG2,都是一般项目操作的最佳实践.前面的几个通用实践,都是有关履行任务的条件.策划.与一些比较容易被忽略的实际操作.最 ...
java web系统设计思路_JavaWeb——实战入门，设计思路总结。
期末考试炸掉了,关于此次期末考试题,我一言难尽,过后总结,还是应该加强功底,勤能补拙. 做一篇入门的设计思路总结,巩固一下基础,如讲解有误,请多多包涵. 我的设计思路如下: 1.在navicat(my ...
【CV】目标检测入门和实现思路！
作者:徐和鼎,浙江大学,Datawhale优秀学习者本文讲解了目标检测的基本概念,分析了实现目标检测的常用思路.下一篇将介绍目标检测经典数据集-VOC数据集的基本信息,和对VOC数据集进行处理的方法 ...
音视频怎样入门？带你入门基础+学习思路
Android开发的路越走越难,难道真的没有其他出路了? 并没有,一个行业的下降趋势也会带起新的行业,他的本质不会变,技术会稍有改变,本篇我们就来说说音视频行业. 音视频行情分析 1.市场市场是一个 ...
黑客与红客｜新手入门渗透测试思路
渗透测试是门技术,也是一门艺术. 渗透测试是门技术,也是一门艺术. 参考书籍<欺骗的艺术><入侵的艺术><社会工程学攻击1><社会工程学攻击2> 这门技 ...
干货|Web安全入门基础与思路总结（附思维导图）
该篇文章主要是写给WEB安全入门者的基础与思路基础 HTTP协议网站访问过程静态页访问首先用户通过浏览器打开kw0ng.top,此时浏览器会向DNS服务器请求解析,将kw0ng.top转换为I ...

CMMI入门 - 由来与思路

CMMI入门 - 由来与思路相关推荐

最新文章

热门文章