成熟度模型的思考

在一次在线直播中，我和我的同事们一起讨论了《成熟度模型的利与弊》。任何一场讨论都是一个思辩的过程，我得以有机会深入思考，并将讨论过程中的一些观点记录下来，是一个不错的学习旅程。

首先什么是成熟度模型？业内有很多介绍，提及最多的是CMMI。我本人是反对CMMI的，CMMI文档过多且滥：抽象看，好像CMMI文档的每一项都能说出它的用处，但这些“有用”的文档却不能在软件开发实践中起到促进作用。这和“工作的软件高于详尽的文档”是背道而驰的。同时，CMMI将高度创造性的开发过程当成机器的开动运转和停止，忽视了人的主观能动性和人在不同状态下工作效率的差异。然而，“个体和互动高于流程和工具”，这也是敏捷的核心精神之一。

什么是敏捷？两年前在写《项目管理中的敏捷实践》时，对敏捷交付价值的理解并不十分深刻。很多时候，我们都能理解敏捷的工具和基础实践，却忽视了敏捷的本质。敏捷的本质正是追求价值，这也是我们很多软件从业者的初心。

工具仅是工具。春节期间，我在我自己的微信公众号上更新过一篇文章《谈谈远程协作：人、流程和工具》，文中提到了一个框架：人、流程和工具。我认为任何团队运作都不可能离开这三个层面的相互作用。我们可以这么想：工具服务于流程，流程服务于人，即团队。“道、法、术、器”出自老子的道德经，道以明向，法以立本，术以立策，器以成事。工具是器的层面，不是说器不重要，但是我看到在很多组织里面，过于看重“器”，而忽略了人和流程的价值，这就本末倒置了。

所以，成熟度模型用不好，会阻碍组织敏捷。作为咨询师，我看到很多团队为了追求成熟度模型的评级，将其看作绩效考核的指标。为了评级而评级，这是没有价值的，很多时候甚至会起到反向的作用。

当然，如果我们将成熟度模型视为判断改进状态的工具，在前进的过程中不断地作出评估，依据评估的反馈形成持续改进的闭环，这就很有价值了。同时，一定不要对团队“一刀切”，对于不同的团队，根据成熟度不同，因地制宜的设计改进的解决方案，并采取相应的激励措施。

所以，我们不可能用一个工具去解决所有问题，也不能将好与坏归结为一个工具。我们需要做的是把工具整合在一起，从解决问题的角度出发，让工具更好地服务于团队。

ThoughtWorks敏捷成熟度模型是什么？

ThoughtWorks敏捷成熟度模型从业务、团队、产品和技术四个维度，九个基本面来对团队的敏捷成熟度作有效评估。

4个维度

组织治理：采用更适合的项目计划和管理实践、更紧凑的软件开发流程，应对不断变化的业务需求，抓住不可预测的市场机遇。治理的最根本目标是高效、实时把软件开发流程和商业计划管理集成起来。

需求管理：在软件开发过程中，需求是对客户价值的明确定义。最大化满足客户价值的软件，其开发过程依赖于实际用户参与开发和以即时制（JIT：无库存生产方式）为基础的价值排序。

交流协作：通过促进在项目利益相关者之间高效沟通和协作，使得项目得以快速、准确地传递客户价值。协同开发过程是通过配置、工具和技术的系统性支持。

构建管理：敏捷团队中，多人快速提交是一种日常行为。构建管理系统应该支持快速并发提交构建而不破坏现有构建。

简单设计：产品设计和实现应该越来越简单，功能的增量修改会变得越来越高效和低风险。

测试策略：测试是为敏捷项目小步快走护航，为其提供行之有效的安全网。

快速响应：“敏捷”本意是具备快速响应客户需求变化的能力。响应的度量从速度和质量两个维度，需求的变更可被高响应力淡化。

职责共享：团队灵活和相互协调，创造出积极的氛围，推进不断提高效率。团队不存在知识和技能的潜在单点故障。

精益思考：敏捷开发实践是对精益管理目标的有力补充。软件开发中的浪费在端到端业务价值流中无处不在，系统性地识别、跟踪、消除浪费来提高组织的生产率。

9个基本面

本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。