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

Sun, 05 Jul 2026 22:45:00 +0800

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 的设计逻辑是"先定义过程，再执行过程，最后度量过程"，强调文档驱动和阶段门控。这套体系在大型军工、金融、电信等重监管行业确实发挥了巨大作用，但也暴露出三个结构性问题：

痛点	具体表现	根因分析
过程与实践脱节	评估时补文档，评估后回到老路	过程域定义过于抽象，缺乏落地抓手
评估成本过高	一次 ML3 评估需要6-12个月准备期	证据收集依赖人工，自动化程度低
与敏捷天然冲突	迭代交付 vs 阶段评审，自组织 vs 过程资产库	框架设计时未充分考虑敏捷场景

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 和敏捷放在一起审视，会发现一个非常清晰的互补结构：

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

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

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

维度	CMMI 的表达	敏捷的表达
透明度	过程资产库、度量数据库、状态报告	可视化看板、燃尽图、信息辐射器
持续改进	组织过程焦点（OPF）、因果分析	Sprint Retrospective、Kaizen
质量保证	PPQA（过程和产品质量保证）	Definition of Done、验收测试
风险管理	RSKM（风险管理过程域）	迭代式交付降低风险、Spikes

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

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

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

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

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

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

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

3.1 组织级过程域

CMMI 过程域	核心要求	敏捷落地实践	融合要点
OPD（组织过程定义）	建立标准过程资产库	Scrum 流程框架、QA 流程规范	过程资产不是静态文档库，而是团队 Wiki 上持续更新的"工作协议"和"流程模板"
OPF（组织过程焦点）	识别改进机会，推动过程改进	敏捷教练、ScrumMaster、差距分析、Retrospective	将 Retrospective 的改进项与组织级改进路线图对齐，让团队级改进能上升到组织级
OT（组织培训）	确保人员具备所需技能	团队教练（Team Coach）、技术工作坊、Dojo	培训不再是年度计划中的课堂授课，而是嵌入 Sprint 的"学习型 Sprint"和结对学习

3.2 项目级过程域

CMMI 过程域	核心要求	敏捷落地实践	融合要点
IPM（集成项目管理）	协调多团队交付	Scrum of Scrums、Scaled Agile	多团队协调不靠项目经理"盯"，而靠跨团队 Sync 和共享看板
PMC（项目监控）	跟踪项目状态和偏差	每日站会、Sprint 评审、燃尽图、可视化看板	监控从"月度报告"变为"实时可视化"，偏差在日级别被发现和纠正
PP（项目计划）	制定可行的项目计划	发布计划、Sprint 计划、团队速度（Velocity）	计划不再是年初的一次性动作，而是每个 Sprint 的滚动规划，用速度数据替代拍脑袋估时
RSKM（风险管理）	识别和缓解风险	迭代管理风险、Backlog 中标注风险项	风险不再单独写"风险登记册"，而是作为 Backlog 的一类条目被持续跟踪和化解
PI（产品集成）	确保组件集成正确	持续集成、每日构建、Feature Toggle	集成从"阶段性活动"变为"每次提交都触发"，CI Pipeline 就是集成过程的自动化实现

3.3 工程级过程域

CMMI 过程域	核心要求	敏捷落地实践	融合要点
RD（需求开发）	开发和分析客户需求	产品负责人（PO）、用户故事挖掘、Backlog 梳理	需求从"需求规格说明书"变为"持续梳理的 Backlog"，PO 是需求开发的持续责任人
REQM（需求管理）	管理需求变更和追溯	Product Backlog、Sprint 目标、验收条件	Backlog 天然就是需求管理工具，Sprint 目标确保每个迭代的需求聚焦
TS（技术解决方案）	设计和实现解决方案	简单设计、演进式设计、编码规范、结对编程、TDD	设计不是一次性的"概要设计+详细设计"，而是随代码一起演进，TDD 保证设计意图被代码忠实表达
VER（验证）	确认工作产品满足规格	测试前置、测试驱动开发、自动化测试	验证从"开发完再测"变为"先写测试再写代码"，自动化测试是持续验证的基础设施
VAL（确认）	确认产品在目标环境中满足需求	验收条件、Sprint 评审、UAT	确认从"上线前验收"变为"每个 Sprint 的 Review"，用户持续参与确认过程

3.4 支持级过程域

CMMI 过程域	核心要求	敏捷落地实践	融合要点
CM（配置管理）	管理工作产品版本和变更	共享代码仓库、自动化构建、自动部署	Git + CI/CD Pipeline 就是现代化的配置管理系统，每次提交都有版本追溯
PPQA（过程和产品质量保证）	客观评价过程和产品质量	可视化看板、敏捷教练、团队协议、自组织	QA 不再"检查文档是否齐全"，而是教练角色——帮助团队遵守自己制定的工作协议
MA（度量和分析）	收集和分析度量数据	团队速度、燃尽图、Lead Time、Cycle Time	度量数据不再为评估服务，而是团队自我改进的反馈信号
DAR（决策分析和解决）	结构化决策过程	团队工作协议、决策模板、ADR（Architecture Decision Records）	决策过程从"领导拍板"变为"团队共识"，ADR 记录每次重要技术决策的背景和理由
SAM（供应商协议管理）	管理外部供应商	客户协作、合同敏捷化	从"甲乙方对立"转向"协作伙伴关系"，合同中嵌入敏捷条款

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

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

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

4.1 什么是 ETC

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

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

4.2 ETC 的核心职能

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

4.3 ETC 与 CMMI OPF 的融合

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

OPF 要求	ETC 的实现方式
评估当前过程	通过敏捷成熟度评估（而非 CMMI 正式评估）获取基线
识别改进机会	从各团队 Retrospective 中提取共性主题
制定改进计划	形成季度改进路线图，与业务目标对齐
实施改进	通过工作坊、教练辅导、工具引入落地
评估改进效果	用度量数据验证改进是否产生了可观察的变化

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 避免形式主义的五个检查点

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

形式主义自检清单
□ 看板上的卡片是团队自己写的，还是 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 推荐工具链

融合需求	推荐工具	作用
过程资产库	Confluence / Notion	替代传统的"过程资产库"，团队可协作编辑
需求追溯	Jira / Azure DevOps	Backlog 天然实现需求追溯，Epic→Story→Task 的层级结构
度量可视化	Grafana / Power BI	自动从工具链抽取数据，生成燃尽图、速度趋势图
持续集成	Jenkins / GitHub Actions / GitLab CI	将 PI、VER、CM 三个过程域自动化
决策记录	ADR（Architecture Decision Records）	结构化记录技术决策，满足 DAR 过程域要求
知识管理	内部 Wiki + 实践社区	替代传统的"经验教训数据库"

6.2 关键治理机制

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

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

6.3 度量体系设计原则

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

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

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

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

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

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

结语

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

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

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

Scrum on 文艺技术笔记