CMMI 2.0 与敏捷的融合实践：研发过程改进不只能靠"考证"

很多企业花了几百万做 CMMI 认证，拿到证书后研发流程该怎么乱还是怎么乱。另一些团队全面拥抱敏捷，却在规模化扩张时陷入混乱。问题不在于方法论本身，而在于我们把"过程改进"等同于"拿证"，把"敏捷转型"简化为"开站会"。CMMI 2.0 的发布，恰好给了一个重新审视两者关系的契机。

一、CMMI 从 V1.3 到 V2.0：不只是版本号变了

2018年3月，ISACA 发布了 CMMI V2.0，这是自2010年 V1.3 以来最大幅度的一次修订。表面上看是版本号的变化，实际上反映了整个行业对"过程改进"认知的深层转向。

1.1 V1.3 时代的核心痛点

CMMI V1.3 诞生于2010年，彼时软件工程仍以瀑布模型为主流。V1.3 的设计逻辑是"先定义过程，再执行过程，最后度量过程"，强调文档驱动和阶段门控。这套体系在大型军工、金融、电信等重监管行业确实发挥了巨大作用，但也暴露出三个结构性问题：

1.2 V2.0 的关键变化

CMMI 2.0 做了几个关键调整，直接回应了上述痛点：

• 引入 Practice Area（实践域）替代 Process Area（过程域）：从"你有哪些过程"转向"你做了哪些实践"，语言上就向敏捷靠拢了一大步。
• 新增 Doing 维度：V1.3 只关注"过程是否被定义和执行"，V2.0 增加了"是否真正在做"的验证维度，强调日常实践而非评估期突击。
• Performance Management 贯穿始终：不再把度量当作评估前的突击动作，而是嵌入日常运营。
• 正式承认敏捷实践：V2.0 在多个 Practice Area 中明确引用了 Sprint、Backlog、Retrospective 等敏捷术语，这是官方框架首次向敏捷"低头"。

这些变化的本质信号是：过程改进的目标不是通过评估，而是持续交付价值。 CMMI 终于承认了业界早已知道的事实——证书不等于能力。

二、CMMI 与敏捷：不是替代关系，而是 What 与 How 的关系

很多团队在讨论过程改进时，会把 CMMI 和敏捷放在对立面：“我们是敏捷团队，不需要 CMMI 那套"或者"我们要过 CMMI，敏捷那套太随意了”。这种二元对立本身就是认知偏差。

2.1 核心框架：CMMI 解决 What，Scrum 给出 How to

把 CMMI 和敏捷放在一起审视，会发现一个非常清晰的互补结构：

1
2
3
4
5

CMMI 回答的问题：研发过程"应该做什么"？
  → 需求管理要做、配置管理要做、风险管理要做……

敏捷回答的问题：这些事"具体怎么做"？
  → 用 Product Backlog 管需求、用 CI/CD 管配置、用 Sprint 节奏管风险……

两者都强调透明度和持续改进，只是表达路径不同：

当两者融合时，CMMI 提供的是"过程改进的完整性检查清单"——确保你没有遗漏关键实践；敏捷提供的是"落地的具体手法"——确保这些实践能在日常工作中活起来。

2.2 为什么很多企业的融合尝试失败了

失败案例中，最常见的模式有三种：

1. 两层皮模式：CMMI 一套文档，敏捷一套实践，两者互不相干。评估时用前者，日常用后者。
2. 过度裁剪模式：为了适配 CMMI 要求，给敏捷加了大量文档和审批环节，把 Scrum 变成了"带站会的瀑布"。
3. 形式主义模式：看板只是墙上的贴纸，Retrospective 只是走过场，度量数据只用于汇报而非改进。

这三种模式的共同问题是：把 CMMI 当成"要过的考试"，而不是"要融入日常的习惯"。

三、CMMI ML3 过程域与敏捷实践的完整映射

下面这张映射表是整个融合框架的核心。它覆盖了 CMMI ML3 所有关键过程域，并给出了对应的敏捷落地实践。

3.1 组织级过程域

3.2 项目级过程域

3.3 工程级过程域

3.4 支持级过程域

使用这张映射表的关键原则：不要把它当成"对照检查表"逐条打勾，而是用它来诊断——你的敏捷实践中，是否已经覆盖了这些过程域的核心意图？如果有缺失，是刻意裁剪还是无意遗漏？

四、ETC：让过程改进从"项目组行为"变成"组织级能力"

单靠一个 Scrum 团队做得好，不叫过程改进。真正的挑战是：如何让优秀的实践从个别团队扩散到整个组织？

4.1 什么是 ETC

ETC（Enterprise Agile Transition Community，企业敏捷转型社区）是 CMMI 2.0 和大规模敏捷框架中共同强调的组织级治理结构。它的定位是：

• 不是 PMO：不控制项目，不分配资源
• 不是过程改进组：不写流程文件，不做内部评估
• 而是：一个由跨团队教练、技术专家和变革推动者组成的社区，负责创造过程改进的"土壤和气候"

4.2 ETC 的核心职能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

ETC 职能模型
├── 感知层
│   ├── 收集各团队的 Retrospective 改进项
│   ├── 分析组织级度量趋势（质量、速度、交付周期）
│   └── 识别跨团队的共性问题和改进机会
├── 赋能层
│   ├── 设计和交付组织级工作坊（如 TDD Bootcamp、安全编码训练营）
│   ├── 建立内部教练池，培养团队级 ScrumMaster
│   └── 维护组织级知识库（最佳实践、踩坑记录、决策模板）
└── 治理层
    ├── 定义组织级敏捷成熟度评估标准
    ├── 推动过程改进从"项目级试点"到"组织级推广"
    └── 与管理层沟通，争取改进所需的资源和授权

4.3 ETC 与 CMMI OPF 的融合

在 CMMI 框架中，OPF（组织过程焦点）要求组织系统地识别改进机会并推动实施。ETC 恰好是 OPF 在敏捷组织中的实现载体：

ETC 存在的最大价值是：把"过程改进"从评估驱动的周期性活动，变成价值驱动的持续性活动。 没有人再需要为了"过评估"而突击补文档。

五、落地实践：从"考证思维"转向"改进思维"

5.1 融合落地的四个阶段

将 CMMI 过程改进能力真正融入敏捷团队，通常需要经历四个阶段：

阶段一：意识唤醒（1-2个月）

目标是让团队理解"为什么要做过程改进"，而非"为什么要过 CMMI"。

• 用一次 Retrospective 专门讨论"我们当前最大的流程痛点是什么"
• 引入敏捷成熟度自评工具，让团队看到自己在各个实践域的现状
• 避免在这个阶段引入任何 CMMI 术语，用团队自己的语言描述问题

阶段二：实践映射（2-4个月）

目标是让团队发现"原来我们已经在做很多 CMMI 要求的事了"。

• 用上述映射表做一次"实践覆盖度评估"：哪些 PA 我们已经做得很好？哪些有缺失？
• 对缺失的 PA，不是直接引入 CMMI 过程，而是寻找对应的敏捷实践来填补
• 例如：发现 RSKM 缺失 → 在 Backlog 中增加"风险"标签 → 每个 Sprint 计划时检视风险项

阶段三：度量闭环（4-8个月）

目标是建立"改进-度量-再改进"的闭环。

• 为每个关键实践定义1-2个度量指标（不要多，多了就是负担）
• 度量数据在 Retrospective 中使用，而非在管理层汇报中使用
• 建立"改进实验"机制：每个 Sprint 尝试一个小改进，下个 Sprint 看数据是否变化

阶段四：组织扩散（8-12个月）

目标是从"一个团队做得好"变成"一类团队都能做好"。

• ETC 从成功团队中提取可复制的实践模式
• 通过内部工作坊、结对辅导、实践社区传播
• 建立组织级的"实践菜单"，让新团队可以快速选择和适配

5.2 避免形式主义的五个检查点

在融合落地过程中，以下五个问题可以帮助团队自我检测是否陷入了形式主义：

1
2
3
4
5
6

形式主义自检清单
□ 看板上的卡片是团队自己写的，还是 QA 帮写的？
□ Retrospective 的改进项在下个 Sprint 有被跟进吗？
□ 燃尽图是每天手动更新的，还是自动生成的？
□ Sprint 评审有真正的用户/利益相关者参与吗？
□ 团队速度数据被用于团队自我改进，还是用于绩效考核？

如果以上任何一项的答案指向形式主义，就需要暂停并重新审视。 形式主义的代价不只是浪费时间，更危险的是它会让团队对"过程改进"产生抗体——以后任何改进倡议都会被当成"又来折腾了"。

5.3 一个实际的融合案例

某金融科技公司的一个事业部有12个 Scrum 团队，之前通过了 CMMI ML3 评估。评估结束后，团队普遍反映"写了很多文档但没什么用"。在新任 CTO 推动下，该事业部启动了 CMMI-Agile 融合项目：

第一步：诊断

• 对12个团队做敏捷成熟度评估，发现共性短板：需求管理（REQM）做得好但需求开发（RD）弱，配置管理（CM）做得好但产品集成（PI）弱。
• 根因：团队有规范的 Backlog 管理流程，但 PO 能力不足导致用户故事质量差；有 Git 仓库和构建服务器，但没有真正的 CI Pipeline。

第二步：干预

• 引入"用户故事工作坊"提升 PO 能力（对应 RD 过程域）
• 建立 CI/CD Pipeline，要求每次提交触发自动构建和测试（对应 PI 和 VER 过程域）
• 每个 Sprint Retrospective 增加"过程改进检视"环节，跟踪改进项落地情况（对应 OPF 过程域）

第三步：验证

• 3个月后，缺陷逃逸率下降34%，Sprint 交付承诺达成率从68%提升到85%
• 没有做任何 CMMI 评估，但团队实际的过程能力已经显著提升

这个案例的关键启示：过程改进的效果应该用业务指标来衡量，而不是用评估等级来衡量。 缺陷少了、交付稳了、客户满意了——这比任何证书都有说服力。

六、工具与机制：让融合可持续运转

6.1 推荐工具链

6.2 关键治理机制

融合要可持续，需要以下治理机制：

• 双周 ETC Sync：跨团队教练和 ScrumMaster 同步改进进展
• 季度过程健康检查：用轻量级评估（1-2天）替代传统的重评估（数周）
• 年度敏捷成熟度评估：对标行业标准，设定下一年改进目标
• 改进实验看板：所有改进实验可视化，成功的推广，失败的学习

6.3 度量体系设计原则

度量是融合落地中最容易走偏的环节。以下是几条关键原则：

1. 团队度量给团队用：速度、燃尽图、缺陷密度等数据首先服务于团队自我改进，而非管理层监控。
2. 组织度量给组织用：交付周期、客户满意度、缺陷逃逸率等数据用于组织级决策。
3. 不要度量"过程遵从度"：度量"团队是否按流程做了"只会催生形式主义，应该度量"团队是否产出了预期的结果"。
4. 度量要有时效性：月度度量太慢，周度或 Sprint 级别的度量才能支撑快速改进。

七、从 V1.3 到 V2.0 的迁移路径

如果你的组织目前还停留在 CMMI V1.3，以下是向 V2.0 + 敏捷融合迁移的建议路径：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

迁移路径
│
├── 第一步：认知升级
│   ├── 管理层培训：理解 V2.0 的核心理念变化
│   ├── 教练团队培训：掌握 CMMI-Agile 映射方法
│   └── 输出：组织级融合转型章程
│
├── 第二步：试点验证
│   ├── 选择2-3个成熟度较高的敏捷团队作为试点
│   ├── 用映射表做实践覆盖度评估
│   ├── 实施改进干预并收集度量数据
│   └── 输出：试点报告和改进方案
│
├── 第三步：组织推广
│   ├── 建立 ETC 并赋予资源和授权
│   ├── 将试点经验提炼为可复制的实践包
│   ├── 分批次推广到更多团队
│   └── 输出：组织级实践菜单和推广计划
│
└── 第四步：持续演进
    ├── 建立度量驱动的改进闭环
    ├── 定期回顾和调整融合策略
    └── 输出：持续改进的组织文化

整个迁移周期通常在12-18个月，但关键不是"多快完成"，而是"改进是否真的在发生"。

结语

CMMI 2.0 的发布，标志着过程改进领域终于正式承认了一个事实：好的研发过程不是被"评估"出来的，而是被"实践"出来的。 敏捷提供了实践的载体和节奏，CMMI 提供了实践的完整性框架和治理视角。两者融合的关键，不在于你能否在评估中展示敏捷实践的证据，而在于你的团队是否真的在日常工作中受益于这些实践。

当一个团队的 Retrospective 不再需要 QA 提醒就能产出有价值的改进项，当燃尽图成为团队自发的导航工具而非汇报材料，当新人入职后能通过团队 Wiki 快速理解"我们为什么这样做"——这个时候，CMMI 的 ML3 能力不需要任何评估师来认证，它已经长在团队的肌肉记忆里了。

过程改进的终极目标不是证书，而是让改进成为组织的本能。