CMMI在研发团队落地，关键是把模型条款转成项目里可执行的动作、可检查的产出和可追溯的记录。比较稳妥的路径是从当前最痛的1—2个过程域切入，先在一个项目或一条产品线跑通一个完整迭代，再按评估差距逐步扩展。下面按范围确定、流程映射、角色交付物、迭代示例和完成检查五步展开。
要点总览（TL;DR）
- CMMI落地的起点是划定范围：先明确覆盖项目、首批1—2个过程域、目标等级和时间窗口，再选一个业务价值明确、周期完整的试点项目执行。
- 把模型条款拆成“目的—期望产出—可执行动作”三层，映射到需求、计划、评审、测试等现有环节，同一环节的动作合并执行、合并记录。
- 落地需要明确过程改进负责人、项目经理、技术负责人和质量角色的分工，交付物随动作产生，证据以能证明执行、可追溯为限。
- 判断落地是否有效看三条：记录可追溯、动作可复现、偏差有处置；出现文档与执行两张皮、记录后补、角色空转时应回到映射表和角色分工排查。
- 首批过程域连续两个迭代记录完整、偏差关闭稳定后，再按同样方法每次引入1—2个过程域扩展。
先定范围：CMMI落地从哪个层级和过程域开始
CMMI落地的第一步是划定边界。范围过大，团队会在短时间内被大量实践要求压垮；范围过小，又难以形成可评估的过程能力。建议先回答三个问题：这次落地覆盖哪些项目、首批做哪几个过程域、目标成熟度等级和时间窗口是什么。
组织级与项目级的落地层级需要区分。组织级负责定义过程资产、裁剪规则和度量口径，项目级负责按裁剪后的流程执行并产生记录。常见做法是先在组织层明确一套最小过程集，再选一个项目作为试点执行。试点项目的选择标准包括：业务价值明确、团队配合度高、周期完整可观察。
首批过程域的选择依据现状差距和业务痛点，而非模型条款的排列顺序。可以用两个维度筛选：一是当前问题发生的频率和影响，例如需求变更频繁导致返工、评审流于形式、测试缺陷漏到上线；二是该过程域改进后能否在一个迭代内看到变化。首批控制在1—2个过程域，原因是团队注意力有限，过程改进需要配套培训、记录和复盘，同时推进多个过程域容易导致执行走形、记录后补。
范围说明应写成一份可核对的文档，至少包含以下要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 覆盖项目 | 试点项目名称及涉及的产品线 | 某产品线A的客户端研发团队 |
| 首批过程域 | 1—2个，写明选择理由 | 需求管理、项目策划 |
| 目标等级 | 本次落地对应的成熟度目标 | 以二级实践要求为参照 |
| 时间窗口 | 试点周期与检查节点 | 两个迭代，约8周 |
| 裁剪说明 | 哪些实践暂不纳入及原因 | 组织级培训体系暂缓 |
范围说明的完成标志是：项目成员能说清本次要改什么、不改什么，以及检查时间点。范围确定后，再进入流程映射，避免边做边改范围。
把CMMI实践要求翻译成研发流程动作
模型条款本身是描述性的，落地需要把它拆成团队每天能执行的动作。拆解时按“目的—期望产出—可执行动作”三层展开。以需求管理为例：目的是让需求来源、变更和状态可追踪；期望产出包括需求清单、变更记录、需求与任务及测试的关联；可执行动作则是需求提出时登记来源和优先级、变更时走评审并更新状态、开发前确认验收标准。
映射到现有研发环节时，优先复用团队已经在做的动作。需求评审、设计评审、代码评审、测试用例评审通常已有形式，需要补充的是记录方式和检查点。可以直接对应的做法包括：已有的周会任务分派对应项目策划中的任务分解；已有的缺陷跟踪对应问题解决中的缺陷管理。需要新增的往往是轻量记录，例如变更影响分析的一句话说明、评审结论的通过或退回标记、风险登记表中的责任人和应对措施。
映射结果建议整理成一张表，按过程域、研发环节、动作、产出物四列组织：
| 过程域 | 研发环节 | 动作 | 产出物 |
|---|---|---|---|
| 需求管理 | 需求提出与评审 | 登记来源、优先级、验收标准；评审结论留痕 | 需求条目、评审记录 |
| 需求管理 | 需求变更 | 评估影响范围，更新关联任务和测试 | 变更记录、影响分析说明 |
| 项目策划 | 迭代计划 | 分解任务、估算工作量、识别依赖和风险 | 迭代计划、风险清单 |
| 项目监控 | 日常跟踪 | 更新任务状态，记录偏差和纠正措施 | 状态记录、问题跟踪项 |
| 验证 | 评审与测试 | 按检查单执行评审，记录缺陷并闭环 | 评审记录、缺陷记录 |
要避免为每个实践单独造一套流程。判断标准是：如果两个实践要求的动作发生在同一环节、由同一角色完成，就合并为一次执行、一份记录。映射表完成后，团队应能用它回答“这个实践在我们项目里具体做什么、留下什么”。
当这些动作需要在工具中持续执行时，研发管理平台可以承载需求条目、任务状态、评审记录和缺陷闭环的关联。以ONES为例，其项目管理、测试管理和知识库等模块可用于组织需求、任务与测试活动，并保留跨环节的操作记录；这类平台的作用是让映射后的动作有统一入口，减少线下表格和事后补录。具体模块配置需按团队实际流程确定。
角色与交付物：谁来做、留下什么证据
落地执行需要明确四类角色的分工。过程改进负责人负责维护过程资产、组织培训和检查，不直接替项目做决策；项目经理负责在迭代中落实过程要求、组织评审和跟踪偏差；技术负责人负责设计、开发和评审环节的技术判断与记录质量；质量角色负责检查交付物完整性、汇总不符合项并推动闭环。小团队中一人可兼多职，但职责要在角色表中写明，避免检查时无人认领。
每类交付物应明确责任人、产生时点和评审方式。交付物清单可以按下表组织：
| 交付物 | 责任人 | 产生时点 | 检查方式 |
|---|---|---|---|
| 落地范围说明 | 过程改进负责人 | 启动前 | 项目负责人确认 |
| 过程域映射表 | 过程改进负责人与项目经理 | 启动前 | 团队评审 |
| 迭代计划与风险清单 | 项目经理 | 迭代计划会 | 技术负责人确认 |
| 需求与变更记录 | 需求负责人 | 需求提出或变更时 | 评审会留痕 |
| 评审记录与缺陷记录 | 评审组织者、测试负责人 | 评审和测试执行时 | 质量角色抽查 |
| 迭代复盘记录 | 项目经理 | 迭代结束 | 过程改进负责人复核 |
证据留存遵循最小化原则：能证明动作已执行、结果可追溯即可，不必为每个动作写长篇文档。例如评审记录保留参与人、检查项结论和待办事项；变更记录保留变更原因、影响范围和审批结论。记录应随动作发生同步产生，事后补录会削弱证据的可信度。
角色冲突常见于项目经理同时承担过程改进职责，导致执行和检查混在一起。处理方式是把检查动作交给独立的质量角色或轮值评审人，项目经理保留执行责任；若人员确实无法分开，至少在复盘中引入外部视角，对记录完整性做交叉核对。
一个迭代周期的落地示例
以下为演示情景，用于说明执行方式，不代表特定团队的真实数据。背景设定：一个约十人的客户端研发团队，首批选择需求管理和项目策划两个过程域，以一个两周迭代为试点周期。
计划阶段的输入是产品需求池和上一迭代遗留问题。动作包括：需求负责人整理本迭代候选需求，补齐来源、优先级和验收标准；项目经理在计划会上分解任务、估算工作量，识别外部依赖并登记风险；团队确认哪些需求进入本迭代。输出是迭代计划、需求条目和风险清单，完成标志是每条需求都有验收标准、每项风险都有责任人和应对措施。
执行阶段的输入是迭代计划和日常任务。动作包括：开发前组织需求澄清和设计评审，评审结论记录在对应需求下；开发过程中任务状态随进展更新，遇到阻塞登记为问题跟踪项并指定处理人；测试阶段按用例执行，缺陷关联到需求和任务。输出是评审记录、状态记录和缺陷记录。这一阶段的检查点是周中跟踪：项目经理核对任务状态与实际进展是否一致，偏差是否已有纠正措施。
复盘阶段的输入是本迭代的全部记录。动作包括：对照映射表逐项检查动作是否执行、记录是否完整；统计需求变更次数、评审发现的问题数、缺陷闭环情况；对未执行或执行走形的项分析原因，判断是流程设计问题还是执行问题。输出是复盘记录和下一迭代的调整项。完成标志是每个偏差都有处置结论：修正流程、补充培训或调整范围。
这个示例体现的结构是：每个阶段都有明确输入、动作和输出，过程要求嵌入在原有研发活动中，记录随动作产生。团队跑通一个周期后，再评估是否引入新的过程域。
完成检查：判断落地是否真的发生
判断落地是否有效，可以按五个方面逐项核对。范围方面：范围说明是否覆盖试点项目、首批过程域、目标等级和时间窗口，团队成员是否知晓。映射方面：每个首批过程域是否有对应的研发环节、动作和产出物，是否存在同一动作重复记录的情况。角色方面：每类交付物是否有明确责任人，检查职责是否与执行职责分离。记录方面：记录是否随动作产生，能否从需求追溯到任务、评审和测试。复盘方面：偏差是否有处置结论，调整项是否进入下一迭代。
通过标准可以归纳为三条：记录可追溯，即从任一需求或缺陷能查到相关评审、变更和测试记录；动作可复现，即换一个迭代或换一个成员按同样方式执行仍能产出合格记录；偏差有处置，即检查中发现的问题有明确的责任人和关闭时间。
常见失效信号包括：文档与执行两张皮，体系文件写得很全但项目里按老办法做；记录后补，检查前集中补填评审和变更记录；角色空转，质量角色只签字不检查，过程改进负责人只发模板不跟进。出现这些信号时，应先回到映射表检查动作是否过重，再检查角色分工是否清晰。
下一轮扩展过程域的判断条件是：首批过程域连续两个迭代记录完整、偏差关闭率稳定，且团队对现有动作的额外负担可接受。满足条件后，按同样的范围确定和映射方法引入下一个过程域，每次仍控制在1—2个，避免一次性铺开。扩展时同步更新过程资产和检查清单，保持组织级定义与项目级执行一致。
常见问题
CMMI落地一定要先做正式评估吗？
不一定。正式评估用于确认组织过程能力达到某个等级，而落地阶段的目标是让实践要求进入日常研发活动。更常见的顺序是先按现状差距选定1—2个过程域，在试点项目中执行两个迭代，用记录和复盘确认动作能稳定执行，再决定是否申请正式评估。评估机构选择和评估流程细节不在本文范围内，需要另行了解。
团队规模小、一人兼多职时，角色分工怎么处理？
小团队可以一人兼多职，但要在角色表中写明每类交付物的责任人和检查方式。关键是把执行职责和检查职责尽量分开：项目经理负责在迭代中落实过程要求，记录完整性检查交给质量角色或轮值评审人。人员确实无法分开时，至少在复盘中引入外部视角做交叉核对，避免执行和检查由同一人完成而失去约束。
试点项目跑完一个迭代，怎么判断可以扩展到更多过程域？
可以看三个条件：首批过程域连续两个迭代的记录完整，能从需求追溯到任务、评审和测试；检查中发现的偏差有明确责任人和关闭时间，关闭情况稳定；团队对现有动作的额外负担可接受，没有出现集中补记录的情况。三个条件都满足后，按同样的范围确定和映射方法引入下一个过程域，每次仍控制在1—2个。
记录后补是常见问题，怎么减少这种情况？
记录后补通常说明动作设计过重或记录入口分散。可以先回到映射表，检查每个实践要求的记录是否必要、是否能在原有环节顺手完成；再把需求、任务、评审和缺陷的记录集中到统一入口，让记录随状态更新自然产生。检查时重点看记录时间与动作时间是否一致，而不只看记录是否齐全。
CMMI落地和ASPICE这类行业标准是什么关系？
CMMI关注组织过程能力的成熟度，ASPICE面向汽车软件研发过程，两者在需求管理、项目策划、评审与追溯等实践上有交集，但条款体系和评估方式不同。已经按行业标准建设流程的团队，可以把已有实践作为映射基础，减少重复建设；具体条款对应关系需要按各自模型逐项核对，不能直接等同。
