CMMI评估通过了，软件成熟度的口碑却没有同步跟上，项目延期和返工依然是常态。
同样是通过CMMI评估，为什么有的团队交付越来越稳定，有的只是多了一张证书？
要理解CMMI为什么能提升软件成熟度，需要回到它的诞生现场。
如果你是研发管理者或质量负责人，这篇文章会讲清它起作用的条件，也指出最容易走偏的地方。
一、CMMI从何而来
1. 外包项目失控的现实问题
1984年，美国国防部的软件外包项目频繁出问题，项目铺开后进度延误和返工不断，据公开资料，相关损失以亿美元计。
承包商是否具备按时交付的能力，签约前很难判断，国防部因此委托卡内基梅隆大学软件工程研究所开展专项研究，目标是建立一套工程制度，用来评估和改善软件开发过程。这项研究服务一个实际决策：如何选承包商，如何管外包项目。
2. SW-CMM提供思路
1987年，软件能力成熟度模型SW-CMM框架推出，1991年发布第一版。它的核心转向是，不再只盯着交付结果，而是看开发过程是否受控。如果需求经常变、变更靠口头通知、测试总是在交付前救火，交付质量就很难稳定。
SW-CMM把这一判断变成可评估的框架，先定义过程做得好不好，再谈成熟度高不高。它把软件开发过程分为若干关键实践域，每个实践域都有明确的评估标准，这比凭感觉判断承包商能力更可靠。这种思路为后来的CMMI奠定了基础，也是理解CMMI为什么能提升软件成熟度的逻辑起点。
二、CMMI如何提升软件成熟度
1. 过程改进框架的定位
CMMI的定位是过程改进框架。它不规定用哪种编程语言，不限定使用哪款工具，只定义该做什么和做到什么程度。
所谓该做什么，在CMMI中体现为一组实践域。每一个实践域可以理解为一类相关的优秀实践，比如需求管理、项目策划、配置管理都属于不同的实践域。
做到什么程度则用成熟度等级来衡量。成熟度等级相当于一把标尺，用来判断这些实践做得好不好、执行过程稳不稳定。
CMMI与技术规范的区别也由此而来：技术规范解决的是怎么实现，而CMMI关注的是组织怎么工作。举个例子，一个团队可以选用任何需求管理工具来跟踪需求，但CMMI关心的是需求从提出到验收是否走完了完整流程，变更是否留下记录，以及是否有人对最终结果负责。
2. 从能力评估到结果稳定
CMMI将组织的过程成熟度划分为五个等级，每个等级代表组织过程能力的一个台阶。
第一级：初始级。组织的过程通常是无序且被动的，项目执行缺乏统一标准，成功主要依赖于个别成员的个人能力，项目结果波动很大。
第二级：已管理级。组织在项目管理层面建立基本的过程规范，项目能够制定计划、跟踪进度、管理需求和控制变更，能够在类似项目中重复以往的成功经验。
第三级：已定义级。组织将标准过程正式文档化，所有项目都按照组织级的标准流程进行裁剪和执行，好的做法不再只属于某个项目，而成为整个组织的能力。
第四级：量化管理级。组织使用统计和量化技术管理过程绩效，能够根据历史数据预测项目的进度、成本和质量，从知道过去发生了什么，升级为能够预测未来会发生什么。
第五级：优化级。组织建立持续改进机制，通过技术创新和过程优化不断提升过程绩效，改进成为组织文化的一部分。
每一个等级都在回答同一个问题：这个组织是否有能力稳定、可重复地交付高质量的成果？等级越高，答案就越确定。
三、CMMI为何要统一模型
1. 多模型并存的乱象
CMMI之前，行业里已经有SW-CMM、SE-CMM、IPD-CMM、SA-CMM等多套模型并行。它们分别服务于软件工程、系统工程、集成产品开发和供应商采购，看起来方向不同，实际使用中却互相重叠。
一个典型的场景是，团队同时服务多个客户，客户要求不同模型，团队就不得不为同样一套流程准备多个版本的描述。多模型并存的直接问题是重复评估和标准冲突，企业不知道按哪一套改进，更难和别人做横向比较。
2. 统一评定基准的收益
CMMI把多套模型整合为一个体系，统一了评定基准。对企业来说，重复评估的成本下降；对行业来说，软件成熟度有了共同标尺，不同团队、不同供应商可以用同一套标准衡量。
统一之后，软件成熟度不再是模糊的形容词，而是可以用等级和实践域来描述的指标。企业可以看清自己处在什么位置，也知道下一步往哪里走。
这种统一也降低了人才流动带来的学习成本，新人进入团队时，可以用统一的过程语言快速对齐，不必分别理解多套模型的差异。这也是CMMI沿用至今的原因之一，它让过程改进有了共同的参照系。
四、证书不等于能力成熟度
1. 证书与能力成熟度的落差
现实中常见的做法是为拿证而认证。过程文件只服务评估，不服务日常研发，评估结束，证书拿到，流程恢复原样。
证书只能证明企业通过了一次评估，不能证明过程能力真正提升。出现这种落差，往往是对CMMI的定位理解偏了，把它当成资质评定，而不是过程改进工具。
2. 回到能力提升的做法
让CMMI发挥作用，建议把重点放回能力提升本身。
先定改进目标，再选试点项目，把实践落到需求评审、任务拆解、Bug闭环和项目度量上。
同时建议把度量结果定期同步给团队成员，让数据真实影响决策；除此之外，建议用支持CMMI评估的工具来辅助这个过程。
五、CMMI常见疑问速答
CMMI只适合大公司吗？ 不是。它的价值在过程改进，与组织规模无关。小团队按需裁剪实践域，同样能提升交付稳定性，不必追求全覆盖或高级别。
CMMI和敏捷开发冲突吗？ 不必然冲突。CMMI关注过程能力是否稳定可预测，敏捷关注迭代和响应变化的方式，两者可以并行。
不引入CMMI就不能提升软件成熟度吗？ 不是。其他路径也能改进，CMMI的优势在于系统化、可评估、可比较，让改进有统一基准。
1984年的教训到今天依然适用，结果由过程决定，评估只是起点。
准备引入CMMI时，可以先问自己两个问题：当前最影响交付稳定性的环节是什么，评估之后打算改变哪个动作。答案越具体，CMMI对软件成熟度的提升就越可预期。
