CMMI是一套面向组织过程能力的参考模型与评估框架，用成熟度等级和实践域描述研发、服务、采购等过程的规范化程度与改进路径。本文说明CMMI的全称与定义、成熟度等级和过程域的组成机制，区分它与敏捷、ISO 9001、研发效能改进的边界，并用一个需求管理与项目策划的例子说明它在组织中如何体现。
要点总览（TL;DR）
- CMMI（能力成熟度模型集成）是面向组织过程能力的参考模型与评估框架，用成熟度等级和实践域描述改进路径，本身不是开发流程或软件产品。
- 成熟度等级从初始级递进到优化级，过程域把等级落到需求管理、项目策划等具体管理动作；阶段式表示看整体能力，连续式表示看单个过程域的短板。
- CMMI与敏捷、DevOps是互补关系，实践要求可以在迭代节奏中满足；与ISO 9001相比，它更聚焦过程能力的等级化描述与制度化。
- 常见误解是把拿证当终点、把模板堆砌当成熟；等级结论反映评估时点的实践覆盖情况，改进需要写入组织规则并持续维护。
CMMI的直接定义：它是什么、解决什么问题
CMMI的全称是Capability Maturity Model Integration，中文通常译为“能力成熟度模型集成”。它由一系列过程改进实践组成，把组织在研发、服务、采购、供应商管理等场景中的工作方式抽象成可描述、可评估的实践集合，并给出从无序到持续优化的递进路径。CMMI关注的对象是组织的过程能力，即一个团队或组织在重复执行同类工作时，能否稳定地产出可预期的结果，以及这种能力能否随业务变化持续调整。
理解CMMI需要区分三个常被混用的词：模型、评估、认证。模型是公开的实践集合与等级结构，回答“应该具备哪些管理动作”；评估是由受过训练的评估人员对照模型检查组织实际做法，回答“当前处于什么水平、差距在哪里”；认证则是评估通过后对外呈现的结果。三者是“标准—检查—结论”的关系，模型本身不发放证书，证书也不等于组织日常就在按模型运作。
CMMI要解决的是组织级问题，可以归纳为三点。第一是过程一致性：同一类项目在不同团队、不同时间执行时，关键动作是否有共同的做法，而不是依赖个别骨干的经验。第二是可预测性：进度、质量、交付范围能否在早期做出合理估计，并在执行中被跟踪和纠偏。第三是改进方向：当组织知道自己在哪些实践上薄弱时，可以按等级路径安排投入，避免一次性铺开所有管理动作。
几个关键术语需要先解释清楚。“成熟度等级”描述组织整体过程能力的阶段；“过程域”或“实践域”是模型中对某一类管理活动的成组描述，例如需求管理、项目策划、过程质量保证；“实践”是过程域下更细的可观察动作；“制度化”指做法被写入组织规则、被普遍执行并持续维护，而不是某个项目临时采用。这些术语共同构成CMMI的描述语言。
CMMI的边界：哪些内容不属于它
CMMI规定的是“应具备哪些管理结果和实践”，不规定具体开发方法。组织可以选择瀑布式、迭代式、敏捷式或混合方式开展工作，只要相应的策划、跟踪、评审、验证等实践能够被观察到。把CMMI等同于“重文档、重流程、必须写详细设计”是一种常见误读，模型并不要求特定模板或特定生命周期，落地形态取决于组织选择的表示方式和裁剪结果。
CMMI也不替代项目管理工具、代码托管平台或持续集成环境。模型描述的是管理动作与证据，工具承担的是记录、流转和留痕。一个组织可以用表格和文档管理系统满足证据要求，也可以用一体化研发管理平台承载需求、任务、评审和过程文档；工具选择属于实施层面的决策，模型本身不指定产品。
需要划清的另一条边界是研发效能改进。以度量数据驱动的小范围效能实验，例如缩短构建时长、降低需求返工率、调整发布节奏，属于研发效能诊断与持续改进的范畴，本文不展开。CMMI与这类工作有交集——两者都关心过程表现——但CMMI的切入点是组织过程能力的等级化描述与制度化，效能实验的切入点是具体指标与局部改动，读者在规划工作时宜分开立项、分别设定目标。
| 内容 | 是否属于CMMI范围 | 说明 |
|---|---|---|
| 成熟度等级、过程域、实践描述 | 属于 | 模型的核心结构 |
| 评估方法与评估结论 | 属于 | 对照模型检查组织实际做法 |
| 具体开发方法、生命周期选择 | 不属于 | 由组织按业务需要决定 |
| 项目管理工具、代码平台选型 | 不属于 | 工具承载证据，模型不指定产品 |
| 度量驱动的局部效能实验 | 不在本文展开 | 归研发效能诊断与持续改进 |
成熟度等级与过程域：CMMI的组成机制
CMMI用两级结构组织改进路径：等级回答“整体走到哪一步”，过程域回答“这一步要补哪些具体动作”。成熟度等级通常从初始级开始，向上依次经过已管理级、已定义级、已量化管理级，到优化级。初始级的工作方式依赖个人经验，结果难以预测；已管理级在项目层面建立起策划、跟踪、评审等基本管理动作；已定义级把项目层面的有效做法提炼为组织标准过程，并允许按项目特点裁剪；已量化管理级用数据对关键过程进行量化理解与控制；优化级则基于量化反馈持续改进过程本身。
过程域是把抽象等级落到具体管理动作的载体。每个过程域描述一类活动的目的与应达到的结果，例如需求管理关注需求被理解、被承诺、被跟踪变更；项目策划关注估算、计划编制与承诺；过程与产品质量保证关注检查活动是否按约定执行。等级与过程域的关系是：达到某一等级，意味着该等级对应的过程域在组织范围内被制度化，而不只是某个项目做得好。
CMMI提供两种表示方式，适用场景不同。阶段式表示以成熟度等级为主线，适合希望对外说明整体能力水平、按阶段推进改进的组织；连续式表示以单个过程域的能力等级为主线，适合已经明确短板、希望针对某一领域（如需求管理或供应商管理）单独提升的组织。两种表示使用同一套实践内容，差别在于组织改进工作的编排方式和评估结论的呈现方式。选择哪一种，取决于组织是想先建立整体基线，还是先解决特定过程的薄弱环节。
| 成熟度等级 | 核心特征 | 管理动作的重心 |
|---|---|---|
| 初始级 | 过程依赖个人经验，结果波动大 | 识别关键活动，建立最基本的记录 |
| 已管理级 | 项目层面有计划、有跟踪、有评审 | 估算、计划、跟踪、配置与质量保证 |
| 已定义级 | 组织标准过程形成，项目按需裁剪 | 过程资产积累、裁剪规则、培训与复用 |
| 已量化管理级 | 关键过程用数据描述与控制 | 度量定义、基线建立、偏差分析 |
| 优化级 | 基于数据持续改进过程本身 | 原因分析、改进试点、效果验证与推广 |
CMMI与相邻概念的区别
CMMI与ISO 9001都关注过程，但关注点不同。ISO 9001是质量管理体系标准，强调组织建立质量管理体系并满足客户与法规要求，覆盖范围可包括全部业务职能，认证审核以体系符合性为主。CMMI聚焦过程能力与改进路径，用等级描述能力递进，评估时更关注实践是否制度化、是否产生可观察的管理结果。一个组织可以同时运行质量管理体系和CMMI改进项目，两者在文件控制、管理评审等环节有重叠，但目标与评估口径不同，不宜互相替代。
CMMI评估与内部过程审计也不是一回事。内部审计通常由组织自身按既定检查表核对流程执行情况，目的是发现不符合项并推动整改，结论在组织内部使用。CMMI评估由受过训练的评估人员主持，对照模型实践收集证据、判定实践覆盖情况，形成等级或能力等级结论，通常用于对外说明或作为改进基线。审计可以成为评估前的准备手段，但审计通过不代表评估达标。
CMMI与敏捷、DevOps的关系是互补。敏捷实践强调小步交付、快速反馈和自组织团队，DevOps强调开发与运维的协作与自动化；CMMI提供的是过程能力的描述框架与制度化要求。三者可以并存：敏捷团队同样需要需求承诺、计划跟踪和评审记录，这些正是CMMI过程域关注的内容；CMMI也不要求回到重型文档流程，组织可以在迭代节奏中满足实践要求。把CMMI与敏捷对立起来，往往源于把模型要求误读为固定模板。
| 概念 | 关注点 | 与CMMI的关系 |
|---|---|---|
| ISO 9001 | 质量管理体系符合性与客户要求 | 可并行运行，目标与评估口径不同 |
| 内部过程审计 | 组织自查流程执行情况 | 可作为评估前的准备，结论不等同评估结论 |
| 敏捷方法 | 小步交付、快速反馈、团队自组织 | 互补，实践要求可在迭代节奏中满足 |
| DevOps | 开发运维协作与自动化交付 | 互补，CMMI关注过程制度化与证据 |
一个具体例子：从等级目标到日常管理动作
假设一个组织希望从初始级向已管理级推进，选择需求管理与项目策划两个过程域作为切入点。需求管理对应的日常动作包括：需求进入时形成书面记录并明确验收口径，需求变更走统一的提出、评估、批准流程，变更结果同步到计划与测试范围。项目策划对应的动作包括：依据历史数据或专家判断形成估算，编制包含任务、责任人、时间点的计划，计划经过相关角色评审并形成承诺记录。这些动作的产物是需求清单、变更记录、估算依据、项目计划与评审纪要。
评估证据通常来自过程文档与项目记录，而不是口头说明。评估人员会抽样查看若干项目的需求记录是否完整、变更是否经过批准、计划是否与实际执行对应、评审是否留下结论和跟踪项。因此，日常管理动作需要形成可追溯的记录链：需求条目关联到任务，任务关联到评审与验收，变更留下审批痕迹。记录的目的在于让过程可被检查和复用，而非应付检查。
这类记录链可以借助研发管理平台承载。以ONES为例，需求、任务、评审与过程文档可以在同一工作空间中关联：需求条目记录验收口径与变更历史，项目计划以任务和里程碑形式呈现，评审结论与跟踪项留在对应工作项下，过程文档随项目归档。这样，组织在准备评估时可以直接从系统中抽取项目样本和证据，日常执行与证据留存是同一套动作。工具承担记录与流转，过程域要求的判断与裁剪仍由组织自己完成。
围绕这个例子，有三点常见误解需要纠正。其一，把拿证当作终点。等级结论反映的是评估时点的实践覆盖情况，若日常执行回落到旧习惯，能力并不会停留在证书上；改进需要把做法写入组织规则并持续维护。其二，把模板堆砌当作成熟。大量文档若与项目实际决策脱节，既增加负担也不构成有效证据；成熟度看的是实践是否被理解、被执行、被检查。其三，把CMMI当作一次性项目。等级递进意味着组织标准过程要随业务变化裁剪和更新，优化级更是要求基于数据持续改进，这属于长期的管理工作，需要与年度改进计划结合。
常见问题
CMMI评估通过后，等级结论会一直有效吗？
等级结论反映的是评估时点组织实践的覆盖情况，属于阶段性判断。若日常执行回落到旧习惯，能力不会停留在证书上。组织通常需要把有效做法写入组织规则、纳入培训和检查，并在业务变化时更新标准过程，才能让能力维持在相应水平。评估结论的有效期与复评安排，以评估机构和所用模型版本的官方规定为准。
团队已经在用敏捷，还需要做CMMI吗？
两者不冲突。敏捷解决的是交付节奏与反馈方式，CMMI描述的是过程能力的制度化程度。敏捷团队同样需要需求承诺、计划跟踪、评审记录和变更管理，这些正是CMMI过程域关注的内容。是否需要引入CMMI，取决于组织是否有对外说明过程能力、统一多团队做法或按阶段安排改进投入的需要；如果只是提升单个团队的交付效率，可以先从研发效能诊断入手。
从初始级往已管理级推进，第一步做什么比较稳妥？
建议先选一到两个与当前痛点直接相关的过程域作为切入点，例如需求管理和项目策划，把对应的记录链建立起来：需求有书面记录和验收口径，变更走统一审批，计划有估算依据和评审结论。等这些动作在多个项目中稳定执行后，再扩展到配置管理、质量保证等过程域。一次性铺开全部管理动作，容易造成文档负担与执行脱节。
CMMI评估和公司内部的过程审计可以互相替代吗？
不能互相替代。内部审计由组织自身按检查表核对流程执行情况，结论在内部使用，目的是发现不符合项并推动整改。CMMI评估由受过训练的评估人员主持，对照模型实践收集证据并判定实践覆盖情况，形成等级或能力等级结论。审计可以作为评估前的准备手段，帮助组织提前发现记录缺口，但审计通过不代表评估达标。
过程记录一定要用专门的研发管理平台吗？
模型不指定工具，表格、文档管理系统或一体化研发管理平台都可以承载证据。区别在于记录链的完整性和抽取效率：当需求、任务、评审和变更分散在多个地方时，准备评估需要人工汇总，日常执行与证据留存也容易脱节。选择工具时，重点看它能否让需求条目、计划任务、评审结论和过程文档相互关联，便于按项目抽样查看。
