成熟度模型已死--本文有争议，慎入！

回顾前一篇文章的主要观点：

• 应用DevOps的企业不应该使用成熟度模型度量

• 应用DevOps的不同企业/部门不会参考某个所谓标准

• 应用DevOps的不同企业/部门应该参考5大类24项的能力成长模型，来度量其发展进度，在磨练这些能力的过程中，选择符合自身业务需求的，且优先级别高能力先发展。

成熟度模型已死

这个模型在各行各业都可能存在，而且可能是最容易被人接受的模型之一。对于很多新生的领域，如法炮制的套用这个模型合适么？无论合适与否，它还是会出现在DevOps的领域中。为了避免实践者试错，我们不得来分析一下这种模型的特点。

1

特征1：它总是阶梯式的，而且从来都是5个等级，人们经常戏称为Golden 5。常见的5级成熟度模型有下列几种。

CMMI 能力成熟度模型集成

ITIL/ITSM的成熟度模型

IT与业务融合的成熟度 http://www.cio.com.cn/eyan/1431.html

德勤网络安全合规成熟度示意图

持续交付流程成熟度

如果你百度“成熟度模型”，还可以轻易地找到很多类似模型。客观的讲，这个模型是被广泛应用的神五级。

这个模型对于任何使用的组织来说都是统一的，不会说对于有些企业是8级的，对于另外一些企业是10级的。

这种模型的另外一个代名词是“XXX标准”，或者“XX行业标准”。

2

特征2：通常对于每个等级上还可以定义出3到7个不同的维度。维度的数量少则3个级别，多字7到10个维度；可以要在每一个级别的不同维度上进行评价。这些维度一旦确定下来，也通常是十年如一日的静止不变。

只是一种纵横交叉的矩阵的模式，如以上的持续交付流程成熟度、德勤网络安全合规成熟度示意图和IT与业务融合的成熟度都是这样。

维度和等级往往都是静态的，通常模型发布之后，在很长一段时间里，不会发生改变。

3

特征3：这些模型对于不同的组织而言，组织的目标都是一致而单纯的，即“通过/到达”某个级别。请你回忆一下以前的经历。一个软件开发组织经过一年的奋斗，他们通过了CMMI3级认证；第二年的时候，项目组一狠心，一跺脚一次性通过了5级认证。请问他们为什么一定要在第二年通过5级？在第三年里，相比以前，软件开发的质量提高了么？在第四年，有没有可能出现倒退的现象？如果你回答不了这些问题的话，可以尝试请教一个更资深一些的，工作10年以上的朋友或者同事。

成熟度模型的局限性

根据以上的三个主要特征，这种模型的局限性大概有以下几个方面：

每一个企业的自身条件、业务环境、资源约束都是不同的。让他们都对标一个统一的静态成熟度模型是不合适的。这就像是目前某些国家的教育体制一样。

IT行业每天都在发生着巨大的变化，这就是我么经常提到的乌卡时代，今年流行的技术，很快就会过时，明年也将出现新的、未知的技术领域。很多行业的特点就是，在不断反复的被颠覆。而这些成熟度模型通常是永恒不变的。

成熟度模型通常是在微观上进行考察，对很多考察点做孤立的分析和评测。这样做只能度量到技术、工具或者流程本身的一些方面。而忽视了组织通过它们所获得的总体成果产出。举个例子一个企业在通过了CMMI5级之后，发现收入/利润比以前还下降了；解释CMMI到达顶级的企业，业务收入还退步了，这本来就是一件比较尴尬的事情。

如果一个集团企业，在所有IT组织/部门中强推某种成熟度模型的话，还有可能出现停滞不前的博弈现象。某些组织可能会宁愿待在中间的某个不成熟等级，并不愿意快速的提升到最高等级。那样的话，他们将失去每年一定数量的，用于提高成熟度等级的资源和预算。从最大化局部利益的角度考虑，最高级的成熟度可能等于最低级的资源支持。

最后，无论到达了那个等级的成熟度，这种明确而清晰的满足感，滋生出了锚定效应。这其实阻碍了组织持续的探索和尝试未知领域，组织因此学习的知识就会越来越少。甚至于出现能力的下滑和倒退。

综上所述，在DevOps的领域里，成熟度模型和统一标准已经过时了，它不适合用于DevOps的度量；而且，纵观整个行业，国际上目前还没有那一个适用的DevOps成熟度模型被应用于任何组织。那么还有什么其他DevOps适用的模型？

DevOps能力成长模型

这个模型是在《Accelerate-加速器》这本书里被提出的。相信大家对Nicole博士联合Puppet Lab发起的DevOps状态调查和年度报告并不陌生。这本书分析了DevOps状态报告四年的历史数据，书里所展示的内容，其实也正好是作者Nicole Forsgren博士对DevOps现状调研的第一个迭代的阶段性成果。

这本书的目标是解密高效能组织的高明之处，以及背后的原因。从探寻影响组织绩效的因素为起点，经过了四年的不断调研，Nicole博士向我们展示了一个相对比较完整的，各种影响因素的关系网。特别说明的是：下图来自于《加速器》这本书，这个形态是经过4年演进出来的，我们无法猜测2018年Nicole博士究竟怎样地拓展了调研的范围；更无法猜测的是：在2018年的状态报告结果中，这幅图会变成什么样子？

Nicole博士总结出了DevOps能力的5大分类，包含的能力点有24项。

第一类：持续交付

1. 对生产环境的所有工件进行版本控制

2. 运用自动化部署流程

3. 实施持续集成

4. 运用基于主干的开发方法

5. 实施测试自动化

6. 进行测试数据管理

7. 前置信息安全管理

8. 实施持续交付

第二类：系统架构

1. 应用松耦合的架构设计

2. 授权团队进行架构重构的决策

第三类：产品和流程

1. 收集和实施客户反馈

2. 运用价值流模式可视化工作流

3. 运用小批量的工作模式

4. 培养和赋能团队进行试验

第四类：精益管理和监控

1. 应用轻量变更审批流程

2. 业务决策得到从应用到基础架构的全堆栈支持

3. 前瞻性地监控系统的状况

4. 应用WIP来进行价值流的工作管理

5. 通过可视化来监控团队工作质量和进行沟通

第五类：企业文化

1. 发展并支持生机型企业文化

2. 鼓励和支持学习

3. 支持和辅助团队间的协作

4. 提供工作所需要的资源和工具

5. 支持和落实领导力转型

DevOps能力成长模型的特点

首先，这个模型是基于4年以上的、科学的调查分析而来的。Nicole博士和全球最顶尖的DevOps公司，以及各种业内大咖，历经了多年的协作。其次，此模型是演变出来的，而且一定会持续更新。最后，分析一下这个模型的特点。

• 它目标是适用于能力和起点本来就参差不齐的不同的组织/团队。

• 它适用于每个团队在能力上优劣各不相同的情况。而且每个团队的业务使命和向下文也不相同。

• 它使每个团队聚焦在各自不同的能力点上，发展和解决各不相同的约束点/弱点。

• 以上能力模型来上游调查数据就是一个行业基线（基线也在不断变化中），不同的团队参考每一项能力的行业基线定义各自的下一步的发展目标。

建议的度量套路

可以将DevOps能力成长模型作为企业应用DevOps的一个有效的度量工具。通过持续的度量，现状分析和改进，让DevOps的优化全局价值产出的特性加速企业客户价值的增长。这里简单描述一下建议的套路

• 度量关键产出：这些指标是衡量你的团队软件交付的好坏与否的一个高阶的度量。相关指标有：IT效能、前置时间、部署频率、MTTR、变更失败率、加班程度和部署痛点。

• 能力驱动的改进：这些能力是你提升关键产出的抓手。由于你提高了一些能力，你在这些能力得到提升的同时，还能更快且可靠的交付软件。

• 按优先级改进：通过能力模型的评估，你识别出了那些能力约束点/瓶颈，是它们在阻止你达到更高的技术阶段，然后确定那些能力需要先优先发展。