摘要： 本文介绍了成熟度模型在软件开发行业的应用，重点阐述了成熟度模型对于敏捷和DevOps在企业中进行规模化推广的价值，探讨了成熟度模型的设计原则，并对于如何明智使用成熟度模型给出了建议。 导言
在敏捷和DevOps社区，尽管对成熟度模型一直有些争议，但使用各种成熟度模型来指导转型的尝试却从未停止过；从笔者的从业经历来看，谨慎地使用成熟度模型，对敏捷和DevOps在企业中的规模化推广具有很重要的现实意义。
成熟度模型简介“团队定期地反思如何能提高成效，并依此调整自身的举止表现”，这是敏捷宣言的一个原则，它鼓励我们持续地对软件开发方法进行改进。这种改进直接表现在提升团队的效能（更多的价值，更快的交付速度，更高的交付质量，以及更低的成本等），最终服务于企业的业务目标。改进通常由团队交付业务价值所面临的问题或挑战触发，团队共同识别改进点，采取改进措施，检查改进成效，再发起新的改进；周而复始，永不停歇。
针对软件开发方法的改进没有终点，这个漫漫长路需要指引，成熟度模型正是为了满足这一需求。所谓成熟，意思是长大和成长，指生物体发育到完备的阶段，或事物发展到完善的程度。虽然成长的过程是连续的，但还是可以通过观察主体特征的明显变化来确定一些阶段，譬如人类成熟的过程可以分为婴幼儿、儿童、青少年、成年、老年等阶段。基于这个隐喻，成熟度模型使用一个结构化的框架，描述所关注的主体如何随着时间的推移而发展(成熟)；演进的每个阶段，被称为成熟度的一个级别，表明了在成长路径上的进展。
在软件开发领域，历史最悠久，也是最著名的成熟度模型是CMMI。CMMI及其前身CMM，是受美国国防部委托，由Wattss Humphrey在软件工程研究所(SEI)领导的团队所创建，以评估供应商有效交付软件项目的能力。该模型定义了五个渐进的成熟度阶段，从级别1(最不成熟)开始，到级别5(最成熟)结束；根据其成熟度特征对每个阶段进行描述，包含目标、实践和实例等。自上世纪九十年代初被提出之后，CMM迅速为软件开发行业所接受，它所应用的成熟度模型结构，也被很多其它成熟度模型所借鉴，譬如PMI的组织项目管理成熟度模型等。
当敏捷运动兴起，并逐渐成为软件开发的主流之后，虽然CMMI并没有被市场抛弃，但其深刻的瀑布模式烙印，成为相当一部分敏捷实践者们眼中的反面教材，也导致敏捷和DevOps社区对成熟度模型的争议不断；但不可否认的是，伴随着敏捷和DevOps在企业的推广，成熟度的应用从一开始就出现，且一直没有停止过；敏捷教练的工具箱里少不了各种成熟度模型。
成熟度模型的类型针对任何具有持续演进特征的主体，我们都可以设计一个成熟度模型。主体范围可大可小，取决于应用的需要；譬如，可以分别为敏捷或DevOps设计一个模型，也可以设计一个范围更广的研发效能成熟度模型来涵盖它们；或者，对于某些特定领域，例如持续集成或者看板方法，也可以建立一个轻量级的成熟度模型。
成熟度模型主要有阶段式和连续式两种类型。其中，阶段式模型在整体上把成熟度分成多个阶段，每个阶段都有一组考察点；每个考察点用目标或满足目标的实践进行描述，展示了成熟度所关注的某个方面。
图一是阶段式成熟度模型的示例，简明地描述了持续集成的五个成熟度级别；持续集成能力的提升，是通过自低而高，逐一满足各级成熟度中所有考察点的目标来实现的，每个级别都建立在上一级的基础之上。
图一：阶段式成熟度模型示例
连续式模型同样包含多个考察点，每个考察点为一个独立的评估项；与阶段式模型不同，每个考察点都包含成熟度的几个阶段，各阶段可以用阶段性的目标，满足该目标的实践，或能够体现该阶段成熟度的行为进行描述。
图二是一个连续性模型的示例；这是一个DevOps成熟度模型，考察点包括6大领域36个子领域，每个具体考察点（子领域）包含五个成熟等级的描述，图二展示了其中的一部分（需求领域）：
图二，连续式成熟度模型示例