成熟度模型在软件行业里流行甚广，CMM（Capability Maturity Model）可以说是软件领域最著名的成熟度模型。在敏捷开发之前，大部分软件开发组织都会尝试通过CMM评估来确定自身的能力水平和确定提升方向。CMM本身对于推进软件开发的过程规范性起到了一定作用，但基于成熟度的认证却将大部分参与CMM评估的组织推向了形式化，远离了建立能力成熟度模型的初衷。
（CMM基本分级模型示例 来自wikipedia）成熟度模型一般会被构造为一系列有效性级别，比如CMM的1到5级。使用成熟度模型时，首先要进行评估，确定被评估者当前正在执行的等级。确定现行等级之后，便可以使用之上的等级来确定接下来的能力发展方向。明确所需能力的优先级确实是使用成熟度模型的最大好处，基于这样的认知，如果处于第二级，那么获取第三级的能力要比第四级的重要很多。针对复杂领域，这样的分级认知有助于快速共识和改进计划的制定。Martin Fowler在Maturity Model一文中提出的观点是：成熟度模型评估的真正结果不是您处于什么水平，而是您需要改进的工作清单。您当前的水平只是一项中间工作，以便能够确定接下来需要获得的技能列表。敏捷开发普及以后，成熟度也成为一个不可不谈的工具，特别在大型组织里，成熟度成为了敏捷规模化推广的首选。在过去的5年时间里，我们已经帮助数十家企业建立了自己的敏捷成熟度模型，成效和副作用应该说都客观存在，借用此文小结，供大家参考。
成熟度模型的药效在敏捷开发的上下文里，历史的经验告诉我们是不太可能在近期出现一个可以通用的能力成熟度模型的。这里有两个客观原因：
软件服务的业务领域太广，各个业务领域对于软件开发能力的诉求存在较大差异，比如互联网服务平台和大型工程设备制造。
- 软件仍然是一个新兴产业，技术的更新换代造成能力的迭代速度很快，即使在比较成熟的Web技术上，也没有人可以准确告知两年后主流的JavaScript框架是什么。
基于这样的认知，在帮助企业建立自己的敏捷成熟度模型之时，我们还是强调从企业自身的发展目标出发，考虑企业的业务愿景和自身的研发诉求。（敏捷成熟度模型AMM的基本构建过程示意）只有结合组织和业务上下文的成熟度模型才可能产生正向的成效，从多年的经验来看，主要成效聚焦在以下两个方面。
敏捷改进目标共识
敏捷开发的导入对一个组织来说是一次变革，对于任何变革来说，设定明确的改进目标都是关键的第一步。即使仅从研发视角出发，统一目标也不是一件容易的事情。开发同学们觉得需求不清是最大问题，而业务分析会认为开发质量差是关键，最后测试团队强烈建议先解决环境不足问题。面临这样的不同声音，成熟度模型很大程度上可以帮助大家建立一个更加全局的系统性认知。任何组织引入敏捷的初衷都是希望能够构建快速响应外部变化的能力，基于组织存在的业务环境和经营愿景，大家的关键改进点是不同的。比如金融机构可能需要更多的考虑变快的过程中安全能力如何跟上，互联网服务公司则更需要看到整个团队对用户体验的关注。如果执行正确，建立敏捷成熟度模型的过程就是一次帮助大家跳出自身角色帽子限制，真正站在组织视角来审视变革改进关键点的机会。从这个视角出发，其实构建成熟度模型的过程就是一个敏捷项目，同样强调跨职能的协作。通过端到端的分析，开发同学可能会发现需求不清也许不是现在需要改进的关键点，而集中力量构建端到端的流水线是更重要的任务。
(成熟度模型梳理现场照片，不同角色共聚一堂进行研讨。）正确建立成熟度模型后，具体改进工作的设计也会得到很大的提升。在敏捷转型的过程中，对于组织最有效果的改进往往是跨部门、跨职能的，当然也是最困难的，需要打破组织内部已经形成的边界。只有让大家看到全局，才有可能让团队理解为什么开发也需要进行自动化测试的撰写，而测试也需要和业务分析结对。最后想要获得目标共识上的最大成效，千万别忘了敏捷迭代，定期根据改进结果进行目标的调整，乃至成熟度模型的调整，都是必要的。同时也并非一次要把成熟度的每个级别都进行详细分解，如果大部分团队都处于变革的初始，对成熟度模型的高级别进行具体定义是没有意义的。别忘了目标本身应该是团队努力可及的，而不是飘在空中的海市蜃楼。
敏捷规模化组织推广
很多组织在启动变革时并没有构建自己的成熟度模型，而是聘请了外部顾问，根据他们的经验模型进行分析和诊断。AMM评估也成为ThoughtWorks咨询团队在帮助企业启动敏捷转型的一个相对标准实践。
（ThoughtWorks最早提出的AMM原型，包含了10个实践领域和6个评级。此模型多年前内部共识是不公开发表的，避免行业误解为通用敏捷开放能力模型。）
真正的敏捷成熟度模型构建工作是在第一阶段的试点和实践导入之后，其目的是为敏捷在组织的规模化推广做准备。从转型的视角看，这是我们推荐的，也是针对大型组织一种行之有效的落地执行方式。在规模化推广上，正确执行的敏捷成熟度模型同样遵循前文描述的构建方式，并能够结合多方意见，包括企业的业务部门，设定合理的组织级改进目标。“组织80%团队达到成熟度3级”这样的目标很容易设置，但却需要异常小心，别忘了不同的研发团队间可能差异很大，移动APP应用团队和大数据平台团队不管在人员结构和技能，还是在节奏和产出上都不可能一刀切。在一些卓有成效的敏捷改进过程中，我们看到组织将组织级成熟度模型的建立和敏捷教练组工作进行联动，让一线的敏捷教练成为成熟度模型的负责人，从而能够真正让团队在改进工作中践行成熟度模型中的要求。这样的实践思路是接地气的，也是敏捷宣言提倡的，通过工具更加关注人与交流！
成熟度模型的副作用CMM从最早提炼的良好初衷到后期认证带来的形式化，给我们生动地展示了成熟度模型的副作用。作为一种线性的模型，存在两个致命的缺陷：团队和组织容易在成熟度模型的牵引下形成惯性的“升级”思维，忘记业务发展和改进成效才是目的。为了升级，很多改进动作实际上并没有落地，也没有人研究是否真的应该去构建更高一级的能力，投入产出的ROI是否合理。成熟度模型本身成为了僵化的根因，由于成熟度上要考察测试能力，所以就有专门的测试部门进行“持续改进”。这点即使在我们经历的各个组织转型过程中也屡见不鲜。成熟度模型制定后，各个部门开始认领自己的维度，每次的评估结果成了各个部门PK的工具。怎么规避副作用是大家共同关心的问题，然而第一个问题却应该问是否采用成熟度模型。显然如果这个问题有标准答案，那么我们又会陷入成熟度模型已经遇到的尴尬，时代的持续发展和组织形态的持续进化，要求我们在建立任何模型的时候都需要谨慎。有几种典型情况下，我们建议研发组织暂时不要启动成熟度模型的建设：
组织刚开始导入敏捷开发的基本理念，组织结构仍然是相对比较传统的职能仓筒划分，这个时候尝试建立成熟度模型很难不被已经存在的部门壁垒所左右。
新兴业务领域，组织规模有限，并且没有形成固定的职能划分。不同于成型业务，这样的研发团队内部大家往往会觉得缺乏规则比较混乱，很容易寄希望于成熟度模型来明确职责规范。但必须认识到这样的混乱其实更多是业务不确定性所带来的，反而应该尝试让团队理解这样的不确定，让持续变化成为团队常态。
- 组织改进的过程中还没有培养出自己的敏捷教练队伍（或类似改进力量），外部顾问和教练仍然是转型推动的主要依靠，这个时候建立成熟度模型会直接造成模型成为一纸规范，和一线实践脱节。
从临床经验看，成熟度模型的药效和副作用都可能很显著，本着敏捷精神，持续实践反馈、迭代调整是必不可少的正确用药方式。
成熟度模型的提炼如果决定采用成熟度模型，提炼也是有讲究的。下图我们给出了一个比较常用的过程。
（典型的成熟度模型提炼过程，来源于多家企业实践。）这里要特别强调后面两步，模型本身是用来指导团队改进的，所以整个组织、每个团队的共识理解是关键一步。这样的共识是不可能通过红头文件达成的，更需要人和人之间的互动交流，通过不同渠道让更多人参与到讨论反馈过程中来。模型的初步验证也需要团队真正去使用，只有驱动出真正有效的改进，模型才是有价值的。
伴随组织复杂度的流畅度模型在敏捷领域里其实很早已经有了不一样的思考 —— 敏捷流畅度模型，由Diana Larsen和James Shore在2012年提出的。
（敏捷流畅度模型）
不同于成熟度模型，流畅度模型总结了四个区域（Focusing、Delivering、Optimizing和Strengthening），打破了成熟度模型的线性结构。不同的企业和组织根据自己的环境上下文可以选择适合于自己的区域去改进和发展。在复杂业务场景下，成熟度级别区分带来的绝对好坏评判越来越不确定，取而代之的是针对特定上下文的适合与不适，进而随着上下文改变而改变的不同选择。正如我们每个人日常语言学习都能体会到的，如果只是希望能够玩电子游戏，几个典型的英语单词就够用了；而如果需要在外企工作，则至少需要基本的英语沟通；如果选择外派，那么英语可能就需要到达一定专业水平。随着数字化时代的深化，每家企业和每个研发组织实际上面临的业务场景是日益复杂的，所以流畅度的理念也为越来越多的团队所接受。ThoughtWorks也将这样的流畅度元模型借鉴到了企业数字化转型这个复杂工程中，形成了数字化流畅度模型，希望能够帮助面临时代挑战的企业构建真正的组织级敏捷能力。
(ThoughtWorks数字化流畅度模型示意，从横轴的五个板块儿去帮助企业分析自身数字化转型所需的核心投入。）不久的将来，我们可能不会再问 “你的组织成熟度几级？”，取而代之的是“你的组织保持应有的流畅度了吗？”。
