之前写过几篇吐槽CMMI高成熟度在软件环境下的硬伤的文章。将制造业SPC(统计过程控制)的应用照搬在软件工程中属实驴唇不对马嘴，1万个水杯的制造过程都是完全一致的，但没有两个软件系统的开发的过程是完全一致的。在软件环境中导致变异的特殊原因实在太多，强制将不同团队开发的不同系统的数据放在一起做控制图，用SPC（统计过程控制）方法识别所谓“异常点”，做有远见的分析改进，将隐患防患于未然，不仅强人所难，也不符合使用SPC的前提。另一个是模型硬性要求使用具备统计意义的过程性能模型，管控变异，做“what-if”的分析以实现开发目标，更是将复杂软件开发想简单了。

这些制造业中流水线模式的思维明显不适用于充满不确定性，业务和技术创新是常态的软件世界。十几年来，在许多场合我表达了我的观点，然而回应不多，我自己也有乏力感。最近，两个重量级人物的声音让我有了认同感，也许是重塑CMMI高成熟度的时候了。

当被问到如何评价SPC应用到软件开发时，Donald Wheeler（当今SPC应用第一人）的回答直截了当，“软件开发用SPC纯属扯淡！” 他认为软件开发中的特殊原因实在太多，SPC无的放矢。

这个月标志着CMMI正式问世30年（1991年8月，CMM1.0正式发布），我特别想知道，如今，30年前群星璀璨的CMM制造团队是怎么看待CMMI高成熟度的，很可惜，我们已经无法听到Humphrey的声音了，但他的接班人Bill Curtis在这个月初做的一个CMMI高成熟度演讲中，明确给出了自己的结论：

“I am part of the group that got it wrong.” 

“我是把这件事搞砸了的团队一员。”

这让我想起一句话——智者看到证明自己信念是错的证据时，都有能力改变自己的观点。Curtis就是这样一位智者， 也让我对他多了一份敬意。

CMMI改变了软件世界，成为了软件工程中的智慧和经验的载体，高成熟中的不足不影响它在软件发展历史中的地位，我们应该把这些不足当做后人改进完善的机会。在这方面，Bill Curtis给我们做出了榜样，在指出CMMI高成熟度不足后，他也给出了今天他眼中的高成熟度的模样（见下图）。

他认为四级应该是优化级，他所说的优化是让组织内部的重要过程做到极致，变得稳定，可预测。而五级则应该是创新级，如果当前做法已无法满足公司发展要求时，不破不立，通过革命性创新，改变组织的业务、研发、管理模式，让自己立于不败之地。他对2级和3级组织特征的描述和之前没有大的变化，只是换了个新词描述三级组织的能力：可信赖。

我20年的评估、咨询经验发现，成功的CMMI组织有一个共同特点，他们对自己遵循过程开发出来的东西会越来越有自信，敢于应用于后面的产品和项目中，复用率会越来越高。过程混乱、处处走捷径的团队开发出来的东西，恐怕连自己都没信心。所以Curtis给出的三级组织特征是可信赖，也就是对自己对通过过程自律开发出来的东西有信心。

参考Bill Curtis的思路，我认为软件高成熟度的度量分析从过程角度应该关注端到端的价值链的分析和中间过程的关联关系，同时也应做好产品分析，如复用度，可信度，质量债务等。分析方式可以包含各类统计或其他量化分析技术，关键是能引导我们找到改进的关键点。所以模型关注的不应是具体用什么样的分析方法，而是如何让这些量化分析能够真正发挥作用。这样一来，过程性能模型也只是一个可选项：一个实施的选择，而非模型的硬性要求。

其实美国一些被作为标杆的高成熟度组织用的SPC分析，也不是100%遵循纯粹的控制图的分析规则，而是根据性价比（易用、低培训成本、有价值）做了重大调整。

高成熟度的组织应该具备高成熟度的自动化程度，如果可自动化的过程还在手工折腾，不同平台之间没有打通，那么不能说你的过程已经做到优秀。其实Humphrey在30多年前已经告诉我们软件过程自动化的重要性，把它作为高成熟度组织的一个特征。有兴趣的朋友可以再读一遍《管理软件过程》一书中的第十八章。

在软件世界里，不需要做任何数据分析，我们都知道人是造成过程能力差异的最大原因。所以如果没有成熟的软件团队，不可能有高成熟度的组织。在强调推动自我管理团队的同时，也不能忽略如何让管理层对团队有信任和信心。我很认可Bill Curtis的理念：让领导放心的团队必须是一个有能力打硬仗的队伍，同时又是一个过程自律的群体。软件高成熟度在这方面也应该有相关的要求。

上面这些想法虽然不够成熟、全面，但是如果不跳出旧思维，很难解决这个至今存在的旧问题。换个思路，也许我们可以找到更加适合软件、在顶级中外IT企业经过验证的高成熟度实践。

意识到高成熟度的不足对企业导入CMMI4级和5级实践也至关重要，以模型意图和价值为抓手，我们完全可以有创意的建立一套简单、轻量、有价值的高成熟度体系，也可以通过替代实践让高成熟实践在组织活动中常态化，而不是只为评估做些数字游戏。

客观说来，CMMI 2.0还是多少忽略了高成熟度的改进，失去了一次突围机会。希望5000和CSMM的团队和实践者，在建立、完善自己的模型过程中，可以走出困局，重塑软件高成熟度。也欢迎朋友们积极转发，大家一起讨论如何让高成熟度实践变得不再高不可攀，而是能带来实实在在好处。

本文转载自老丛讲桌。