这是鼎叔的第四十四篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

对于传统软件行业的 QA（过程改进）和 PM 人员，CMM/CMMI 知识是基本要求，但是在推行敏捷的组织中，CMM/CMMI 并不被接受，甚至和敏捷转型理念背道而驰。CMM/CMMI 如果作为一个过程改进的知识框架，本身并不会和敏捷研发产生冲突，但这篇文章我们会关注 CMM/CMMI 行业认证中的反敏捷之处。QA 人员也可以对比思考，如何在组织中选取更符合敏捷价值观的实践方案。

参考文章：《CMM 的不成熟之处》，《软件过程改进的竞争价值观》（IEEE 工程管理汇刊），CMMI 相关规范，《丰田之道》，《破除 CMM 迷信》，Barry Boehm，Mark Paulk《软件 CMM》作者等。

CMMI 并非是基于瀑布研发流程来设计的，并非需要大量文档。它和敏捷及精益没有根本上的冲突，但是其改进过程的范式差异比较大。CMMI 对任何的特定实践并没有做出规范要求，但它引入了 “持续改进” 的重要理念。

CMMI 和敏捷开发的表面冲突来自于双方产生的环境、目标客户和团队文化要素。例如 CMMI 早期客户,主要关注大型项目、复杂系统，而敏捷开发主要关注小项目、简单应用和灵活多变的系统；CMMI 的假想市场和用户主要面向成熟市场，面向那些关注流程创新的企业，而敏捷开发主要关注在新兴市场和多变的市场环境；文化方面，CMMI 强调流程和管理，而敏捷更强调高度信任的氛围中，被激励起来的个人之间的协作创新。

在整体上，CMMI 和敏捷开发能够相互补充、相互支持。CMMI 关注组织级或企业级改进，关注回答项目应该做什么，而不是具体怎么做的方法，而敏捷开发则更关注项目具体怎么做的方法和最佳实践，这使双方在定位方面形成相互补充的态势。

两者的有效结合，能够有效实现个人绩效向向组织绩效的转变过程。同时，团队可以借助敏捷实践，规避 CMMI 实施过程中重文档、重流程的不良倾向，让 CMMI 实施时更加关注组织的实际价值、关注客户和创新。

很多外包 IT 团队往往都有 CMMI 的认证。CMMI 早期广泛用于美国国防部招标合同，领导者很多来自美国国防业。我们首先要澄清一些业界的误解，警惕根据 CMMI 鉴定来挑选远程外包公司的做法。

一个公司拥有 CMMI 证书，和它是否有高质量的代码，并没有关系。任何一个简单的数字，如果有利可图的话，那有人就开始要作假了。一个部门得到一次认证，可以被大而化之地广告为整个公司多年来都获得了五级成熟度评价。像一个开发组织的过程能力这么复杂精妙的事物，不可能用一个从 0 到 5 的数字来表示，就靠几个审查师在公司呆一周，访谈几十个员工得出结论？几天的认证培训并不会对改变思维模式或文化的能力有任何变化，这只是人事部门的一厢情愿。

度量容易之事，而非有用之事，这个普遍的反模式导致大家注重合规性，而不是创新，消除浪费和交付价值。如果不关心底层系统的改进，任何认证改进都毫无效果而流于表面。大型调研表示，CMMI 是生产率最不重要的因素之一。最重要的因素是开发人员的能力，这就反映了人员高于过程的敏捷价值观。

当花大力气把 CMMI 提升到 5 级后的团队，转为采用 Scrum 后，各种类型的工作效能提高了一倍。至于 CMMI 和 Scrum 等敏捷框架是否能够一起在团队中使用，取长补短，业界暂时没有能证实的案例。

CMM 最差之处，是粉饰模糊了软件工程的真正动态，压制了其他可选的模型，容易导致软件公司竞争潜力的崩溃。CMM 哲学的流行，是因为给管理层希望和控制的幻觉，提供了一个循序渐进的计划完成明确的事情。CMM 强调可重复的确定过程，不适合天生无重复性的面向学习的创造性领域。

CMM 的价值观把过程看成最重要的永久因素，把人员当成临时因素给机械化了，这和敏捷价值观是完全违背的。

CMMI 并没有正式的理论基础，也没有得到所有专家的广泛接受。它只是基于某些专家的价值观，他们有传统军事软件的开发背景。CMMI 模型的假设是存在一个 “最佳实践”，这和 “泰勒主义” 一脉相承，如果人们见过了最佳方法，那为何还要努力改变现状呢？

“有毒” 的 CMMI 咨询师会把瀑布开发，大批量移交，繁重手册驱动和崇拜式合规仪式，作为 CMMI 的要求来宣导，真相并非如此。

如果你必须用 CMMI 模式来赢得政府合同，那就探索尽可能简单的实践方式，比如利用拍照和录音。

敏捷第一原则告诉我们，个人和互动高于过程和工具，人们会为了奖赏而和系统博弈。不管规范上如何写，只要对实际工作中的员工有用，那就继续实践并改进它，否则就不要做。