完成定义（Definition of Done，DoD）落地，核心是把“什么算做完”从口头共识变成一份分层、可逐项核验的清单，并嵌入研发流程的固定节点：需求进入开发前确认适用层级，开发与测试按清单自检，评审以清单作为通过依据，交付后按清单复盘修订。本文按分层、条目写法、角色职责、流程节点、完整示例和落地检查的顺序展开，适合研发负责人或敏捷实践者照着建立并运行这套机制。
要点总览（TL;DR）
- 落地完成定义的第一步是分层：团队级定所有工作项的完成底线，迭代级追加当前增量的条件，条目级针对缺陷修复、接口变更等特定类型补充，三层取并集、冲突从严。
- 条目要写成“对象+动作+可观察结果或证据”，把“质量达标”“文档齐全”改写成可查看的检查结果和证据位置，团队级控制在五到八条。
- 角色分工要落到人：产品负责人确认适用层级，开发自检留证，测试核验测试条目，技术负责人牵头起草修订并审批例外，例外必须留记录。
- 清单要挂到流程节点上使用：需求确认时标注层级，开发测试阶段逐条自检，评审以清单判断通过与否，交付后汇总未通过项和例外作为修订输入。
- 用分层是否清晰、条目是否可核验、职责与例外是否明确、节点是否真正使用、修订是否运转五项定期核对，按缺口确定改进方向。
先定层级：团队级、迭代级与条目级DoD怎么划分
第一步是确定建哪几层清单。一份清单包打天下的问题在于：通用条目覆盖不到特殊工作类型，特殊条目又会让普通任务负担过重。按团队级、迭代级、条目级三层划分，可以让每层只承担自己的职责，下层在上层基础上追加条件。
团队级DoD是所有工作项通用的最低完成底线，由团队共同约定并长期有效，例如“代码已合并到主干”“单元测试通过”“相关文档已更新”。迭代级DoD针对当前迭代增量交付的附加条件，随迭代目标变化，例如本迭代要求“新接口完成联调并留存联调记录”“性能敏感模块完成基准测试”。条目级DoD针对特定类型工作项补充，例如缺陷修复要求“有复现步骤和回归验证记录”，接口变更要求“接口文档与调用方确认一致”。
| 层级 | 适用范围 | 维护人 | 生效方式 |
|---|---|---|---|
| 团队级DoD | 团队全部工作项 | 技术负责人牵头，团队评审通过 | 团队评审后发布，版本化保存，变更需团队确认 |
| 迭代级DoD | 当前迭代内的交付增量 | 产品负责人与技术负责人共同拟定 | 迭代启动时确认，随迭代计划一并发布 |
| 条目级DoD | 特定类型工作项，如缺陷修复、接口变更 | 对应领域负责人起草，技术负责人审核 | 挂到该类型工作项的模板或检查项中，随类型定义生效 |
层级之间遵循继承与追加原则：条目级在团队级基础上追加，迭代级在团队级基础上追加，三层同时适用时取并集。出现冲突时，以更严格的条件为准；如果某条团队级条目对特定工作类型确实不适用，应在条目级清单中显式写明豁免理由，而不是默认跳过。这样既保留底线，又让例外有据可查。
把完成条件写成可核验条目：编写规则与正反示例
清单失效最常见的原因是条目写成口号，评审时无法判断通过与否。可核验条目的基本结构是：对象、动作、可观察结果或证据。读者拿到条目后，能回答“看什么、在哪看、看到什么算通过”。
编写时先剔除模糊词。“基本完成”“质量达标”“文档齐全”这类表述没有判定标准，应改写为具体对象和证据。例如“代码质量达标”改为“静态检查无新增严重级别问题，检查报告附在工作项中”；“文档齐全”改为“接口文档已更新并在文档库发布，链接附在工作项评论中”。
按常见维度，可以这样写条目：
- 代码：变更已合并到目标分支，提交记录关联工作项编号。
- 测试：新增或修改的逻辑有对应测试用例，测试执行结果已记录；缺陷修复附回归验证记录。
- 文档：受影响的接口文档、使用说明已更新，文档链接附在工作项中。
- 评审：至少一名非作者完成代码评审并留下评审意见，意见已处理或明确记录不处理理由。
- 部署：构建产物已生成并可追溯到本次变更，部署到目标环境的记录可查。
条目数量与颗粒度需要取舍。团队级清单建议控制在五到八条，覆盖代码、测试、文档、评审等底线；条目过多会让自检流于形式，过少则留下明显缺口。颗粒度以“一名团队成员能在几分钟内判断通过与否”为准，需要长篇解释才能判断的条目应拆分或改为附证据。
角色与职责：谁写、谁核验、谁批准例外
清单无人维护或核验流于形式，通常是因为职责没有落到具体角色。落地时至少明确四类角色的分工，并为例外放行设定审批路径。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 确认需求适用的DoD层级，参与迭代级条目拟定，判断业务侧完成条件是否满足 | 需求上的适用层级标注、迭代级DoD草案 |
| 开发 | 按清单自检，提供代码、测试、构建等证据，发起评审 | 工作项中的自检记录与证据链接 |
| 测试 | 核验测试相关条目，确认回归范围与结果，记录未通过项 | 测试执行记录、缺陷与回归验证记录 |
| 技术负责人 | 牵头起草与修订团队级DoD，审核条目级清单，审批例外放行 | 团队级DoD版本、例外审批记录 |
清单的起草、评审、发布与修订由技术负责人牵头，团队评审通过后发布，每次修订保留版本记录，避免新旧条目混用。例外放行由申请人写明未满足的条目、原因、影响范围和补救计划，技术负责人审批，产品负责人知会；审批记录与工作项关联保存，作为后续复盘和修订清单的输入。核验证据由提交方提供，统一保存在工作项或关联文档中，评审时直接查看，不依赖口头说明。
嵌入流程节点：从需求确认到评审的操作步骤
清单只有挂到流程节点上才会被真正使用。下表按节点列出输入、动作、输出与完成标志，团队可据此逐项对照执行。
| 流程节点 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 需求进入开发前 | 需求描述、工作项类型 | 产品负责人确认适用DoD层级，把团队级与条目级清单附到工作项 | 带适用清单的工作项 | 工作项上能看到适用层级和条目 |
| 开发与测试阶段 | 适用清单、变更内容 | 开发按清单逐项自检并留下证据，测试核验测试相关条目 | 自检记录、测试记录、证据链接 | 每条适用条目都有对应证据或明确的未完成说明 |
| 评审环节 | 工作项、证据、清单 | 评审人逐条对照清单判断通过或不通过，未通过项写明原因 | 评审结论与未通过条目清单 | 评审结论明确，未通过项有责任人和处理计划 |
| 交付后 | 评审结论、例外审批记录 | 记录未通过条目与例外情况，汇总为清单修订输入 | 未通过项与例外台账 | 台账更新，并在下次修订时被讨论 |
这些动作需要承载在工作项和文档上：清单附在工作项中，证据以链接或附件形式留存，例外审批记录与工作项关联。ONES 可围绕需求、工作项和迭代组织协作，支持自定义需求状态与属性，并支持文档关联任务、在文档中插入工作项列表，适合把清单、证据和审批记录放在同一处供评审查看。具体配置方式需结合团队实际流程在工具中确认。
示例：一个团队从零建立并运行DoD的过程
以下为演示情景，用于说明连续过程，不代表真实客户案例。
某十人左右的研发团队长期存在“提测后反复返工”的问题：开发认为功能写完即完成，测试发现缺少回归验证和文档更新，评审时各方对是否通过各执一词。团队决定用一个月建立并运行DoD。
第一周起草第一版清单。技术负责人召集开发、测试、产品负责人开一次两小时的会议，按团队级先写底线条目，共七条，覆盖代码合并、测试通过、文档更新、代码评审、构建可追溯等；同时为缺陷修复和接口变更各起草三条条目级条目。清单在团队评审会上逐条讨论，删去两条无法判断的表述，改写为带证据要求的条目，形成第一版并版本化保存。
第二至三周试运行。团队选取一个迭代的全部工作项，在需求确认时标注适用层级，开发自检并附证据，评审按清单逐条判断。试运行暴露三个问题：部分条目证据要求不明确，开发不知道该附什么；迭代级条目在迭代中途才补充，导致前期工作项未按新条目核验；例外放行没有记录，复盘时说不清哪些条目被跳过。
第三周末修订。团队把证据要求写进条目本身，明确迭代级条目在迭代启动时一次性确认，并增加例外审批记录模板，要求写明未满足条目和补救计划。修订后的第二版在下一个迭代运行，评审时未通过项明显减少，返工主要集中在试运行阶段暴露的文档更新环节，团队据此又补充了一条文档条目。
这个过程的迁移要点是：先建团队级底线，再按工作类型补条目级；试运行选一个迭代，暴露问题后集中修订一次；例外必须留记录，否则清单会在不知不觉中被绕过。
完成检查：判断DoD是否真正落地的核对项
运行一段时间后，用下面的清单逐项核对，判断落地是否到位，并据此确定下一步改进方向。
- 清单存在且分层清晰：团队级、迭代级、条目级各有明确范围和维护人，版本可追溯。
- 条目可核验：每条包含对象、动作和可观察结果或证据要求，没有“基本完成”“质量达标”一类表述。
- 证据要求明确：每条适用条目都能说清证据是什么、保存在哪里。
- 角色职责明确：起草、评审、发布、修订和例外审批各有责任人，例外有记录。
- 流程节点真正使用清单：需求确认时标注层级，开发与测试自检留证，评审以清单判断通过与否。
- 修订机制运转：未通过项和例外情况被记录，并在固定周期内进入清单修订讨论。
未达标时的改进方向按缺口对应处理：条目不可核验，回到编写规则逐条改写并补证据要求；流程节点未使用清单，检查工作项上是否附了适用清单、评审是否真的逐条对照；例外频繁出现，分析是条目过严还是执行不到位，前者修订条目，后者明确责任；修订机制停摆，把清单复盘固定到迭代回顾的议程中，指定负责人跟踪。核对结果建议每季度复看一次，让清单随团队交付方式的变化持续更新。
常见问题
团队刚开始推行完成定义，应该先建哪一层清单？
建议先建团队级清单，把代码合并、测试通过、文档更新、代码评审等所有工作项都适用的底线条目定下来，由技术负责人牵头起草、团队评审通过后版本化发布。团队级稳定运行一段时间后，再针对缺陷修复、接口变更等高频特殊类型补条目级清单，迭代级条目则在每次迭代启动时随迭代目标确认。这样起步负担小，也避免一开始就写出大量无人使用的条目。
条目级清单和团队级清单冲突时怎么处理？
按继承与追加原则处理：条目级在团队级基础上追加条件，三层同时适用时取并集，出现冲突以更严格的条件为准。如果某条团队级条目对特定工作类型确实不适用，应在条目级清单中显式写明豁免理由并留下记录，由技术负责人审核，而不是在执行时默认跳过。这样既保留底线，也让例外有据可查，复盘时能说清哪些条目被豁免、为什么。
例外放行频繁出现，说明清单有问题还是执行有问题？
需要区分两种情况。如果例外集中在某几条条目上，且申请人给出的理由反复相似，可能是条目过严或不适应该类工作，应在修订时调整条目或补充豁免条件；如果例外分散、理由多为时间紧或流程没走完，则更可能是执行不到位，需要明确责任并在评审中坚持逐条对照。无论哪种情况，例外都应写明未满足条目、原因、影响范围和补救计划，由技术负责人审批、产品负责人知会，记录与工作项关联保存，作为修订清单的输入。
清单条目数量多少合适，条目太细会不会影响效率？
团队级清单建议控制在五到八条，覆盖代码、测试、文档、评审、构建可追溯等底线即可。颗粒度以一名团队成员能在几分钟内判断通过与否为准：需要长篇解释才能判断的条目应拆分，或者改为要求附上证据。条目过多会让自检变成走过场，过少则留下明显缺口。迭代级和条目级清单按当前迭代目标和特定工作类型的实际风险补充，不必追求覆盖所有情况。
完成定义和迭代评审是什么关系，本文为什么不展开评审的具体做法？
完成定义提供的是评审时判断通过与否的依据，评审本身怎么组织、什么时候开、谁参加，属于迭代管理的范围。本文聚焦清单怎么分层、条目怎么写、角色怎么分工、清单挂到哪些流程节点，以及如何检查落地效果。团队在把清单嵌入评审环节时，只需确保评审人逐条对照清单给出通过或不通过的结论，未通过项写明原因和责任人；评审流程的完整设计可参考迭代管理相关内容。
