完成定义（Definition of Done，DoD）要在研发团队落地，关键是把一句“做完”拆成可逐项核对的验收条件，并放进需求进入开发、提交评审、迭代验收这三个交接点。团队先写出一份分层、可验证的条目表，明确每条由谁核对、留下什么证据，再用工作项状态和检查项承载，最后通过抽样复核与回顾持续修订。
要点总览（TL;DR）
- DoD是团队对所有工作项共用的完成门槛，验收标准是单个需求特有的验收条件，两者并存但边界要分清。
- 条目按团队级、工作项类型级、特殊场景附加项三层组织，每条写成可观察、可验证的表述，并写明核对动作与证据形式。
- 把DoD嵌入需求进入开发、提交评审、迭代验收三个交接点，用工作项检查项与状态流转承载，让核对与流转成为同一个动作。
- 内容由产品负责人与团队共同商定，开发与测试把关可执行性，Scrum Master或facilitator组织定期修订并记录变更。
- 落地效果用抽样复核判断，在迭代回顾中小步修订条目，新增条目应对应已发生的具体问题，控制条目膨胀。
先写出一份可核对的完成定义
DoD落地的第一步是产出一份团队能真实执行的条目表。编写前先厘清一个容易混淆的边界：DoD是团队对所有工作项共用的完成门槛，验收标准是单个需求特有的验收条件。前者回答“我们团队认为什么算完成”，后者回答“这个需求做到什么程度算满足”。两者可以并存，但DoD不应被写成某个需求的专属清单，否则它就会退化成验收标准，失去跨工作项的统一约束力。
按层级拆分条目
一份可用的DoD通常分三层组织，团队按自身交付物取舍：
- 团队级通用DoD：适用于所有工作项的最低门槛，例如代码已合入主干、通过持续集成、有对应测试、文档已更新、相关方已知会。
- 工作项类型级DoD：在通用条目之上按类型追加。需求类关注验收标准已逐条验证、界面或接口已联调；缺陷类关注根因已定位、回归用例已补；技术任务关注影响范围已评估、回滚方案已确认。
- 特殊场景附加项：只在特定条件下启用，例如涉及数据变更时需有迁移脚本与回滚验证，涉及对外接口时需有版本兼容说明，涉及安全敏感逻辑时需有评审记录。
每条写成可观察、可验证的表述
条目写法直接决定它能否被核对。一条合格的DoD应包含核对动作和证据形式，让不同的人核对能得出相同结论。对比下面两种写法：
| 不合格写法 | 可核对写法 | 证据形式 |
|---|---|---|
| 代码质量良好 | 合并请求已由至少一名非作者评审通过 | 评审记录与合并记录 |
| 测试充分 | 新增逻辑有单元测试，关键路径有集成测试且全部通过 | 测试报告或流水线结果 |
| 文档齐全 | 接口变更已更新接口文档，字段说明与实现一致 | 文档版本记录 |
| 需求完成 | 验收标准逐条验证通过并记录结论 | 验收核对记录 |
判断一条表述是否合格，可以用一个简单测试：换一个没参与开发的人，能否仅凭这条描述判断“通过”还是“不通过”。如果答案依赖主观感受，就需要补充可观察的动作或产物。
初版控制在实际可执行的条目数量
初版DoD最容易犯的错误是一次写满理想清单，条目多达二三十条，结果每次核对都草草打勾。更稳妥的做法是先选出团队当前交付中真正会检查的条目，团队级控制在五到八条，类型级每类三到五条，附加项按需启用。条目少但每条都被真实核对，比条目全但无人细看更有价值。后续再随能力提升逐步补充。
完成这一节的标志是：团队产出一份分层DoD初版条目表，每条包含条目内容、适用层级、核对方式、证据形式四列，并经过团队会议确认。
把DoD嵌入研发流程的三个交接点
条目写在文档里不会自动生效，它需要在工作项流转的关键节点被真正调用。研发流程中有三个交接点最适合承载DoD核对：需求进入开发、提交评审、迭代验收。每个交接点都有明确的触发时点、核对人和未通过处理方式。
| 交接点 | 触发时点 | 核对内容 | 核对人 | 未通过处理 |
|---|---|---|---|---|
| 进入开发前 | 需求从待开发转入开发中 | 与需求描述相关的就绪条目，如验收标准已明确、依赖已确认、影响范围已评估 | 产品负责人与开发负责人 | 退回需求池补充信息，不进入开发 |
| 提交评审时 | 开发完成、发起合并请求或提测 | 开发自检通用条目与类型条目，如代码评审、测试通过、文档更新 | 开发本人自检，评审人复核 | 打回修改，工作项保持在进行中 |
| 迭代验收时 | 迭代末对工作项做验收 | 逐条核对全部适用条目并记录证据 | 产品负责人或质量角色 | 未通过项回流至待处理，不进入已完成 |
进入开发前：先确认就绪条目
需求刚进入开发时，部分DoD条目已经可以先行确认，例如验收标准是否清晰、外部依赖是否就绪、是否涉及特殊场景附加项。这一步的价值在于把“做完才发现条件不具备”的风险前移。核对结果作为需求能否进入开发的判断依据，未满足就绪条目的需求留在待开发状态，补充信息后再流转。
提交评审时：以条目为核对依据
开发完成提交评审时，开发者先按DoD自检，把每条对应的证据附在工作项上，例如评审链接、测试结果、文档变更记录。评审人不再凭印象判断，而是逐条对照条目确认。这样评审讨论会集中在具体条目上，减少“我觉得还差点什么”这类无法收敛的争论。
迭代验收时：逐条核对并记录证据
迭代末的验收是DoD最完整的执行场景。验收人逐条核对适用条目，通过的打勾并记录证据位置，未通过的写明原因。只有全部适用条目通过，工作项才能进入已完成状态。未通过项回流到待处理，由团队决定是当迭代内修复还是排入后续迭代。
用工作项状态与检查项承载条目
如果DoD只存在于一份独立文档中，核对时需要在文档和工作项之间来回切换，执行成本高，容易流于形式。更有效的做法是把条目做成工作项上的检查项，随状态流转逐项勾选，证据以附件、评论或关联记录的形式留在工作项内。这样DoD核对与工作项流转是同一个动作，历史记录也可追溯。ONES的工作项支持检查项与状态流转配置，团队可以把分层DoD条目配置为对应工作项类型的检查项，在状态变更时要求完成核对，使条目在流程中自然被执行，而不依赖额外提醒。
角色分工与各环节交付物
DoD的责任如果只落在一个人身上，要么条目脱离实际，要么核对无人执行。合理的分工是内容共同商定、执行各负其责、维护专人组织。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品负责人 | 与团队共同商定DoD内容，确认与验收标准的边界，在进入开发前核对就绪条目 | 确认后的DoD条目表、需求就绪核对记录 |
| 开发人员 | 参与条目可执行性把关，提交评审前自检并附证据 | 自检记录、评审与测试证据 |
| 测试或质量角色 | 把关测试类条目的可验证性，参与迭代验收核对 | 测试结果、验收核对记录 |
| Scrum Master或团队facilitator | 组织DoD的定期修订，跟踪核对执行情况 | 修订记录、抽样复核结果 |
条目可执行性的把关值得单独强调。产品负责人更了解业务完成度，开发和测试更清楚某条技术条目是否真的可验证。例如“性能达标”这类表述，需要开发补充具体的验证方式和阈值口径，否则验收时无法判断。因此DoD内容应由产品负责人与团队共同商定，技术类条目的可执行性由开发和测试确认。
DoD变更需要留下记录并通知到团队。变更记录至少包含修改的条目、修改原因、生效时间。通知方式可以是在团队例行沟通中同步，也可以在工作项模板或团队文档中标注版本。变更生效后，新进入流程的工作项按新版本核对，已在途的工作项由团队约定是否追溯，避免同一迭代内标准不一致引发争议。
一个研发团队的落地示例
以下示例按通用研发场景设定，用于演示从条目编写到验收核对的完整过程，不对应具体企业。
示例背景
一个六人研发小组，负责一个内部业务系统的迭代开发，每两周一个迭代，工作项类型包括需求、缺陷、技术任务。团队此前没有正式DoD，完成与否主要靠口头确认，经常出现提测后才发现文档没更新、缺陷修复没有回归用例的情况。
示例DoD条目
| 条目 | 适用层级 | 核对方式 | 证据形式 |
|---|---|---|---|
| 合并请求已由至少一名非作者评审通过 | 团队级 | 查看合并记录 | 评审与合并记录 |
| 新增逻辑有单元测试且流水线通过 | 团队级 | 查看流水线结果 | 构建与测试报告 |
| 验收标准逐条验证通过 | 需求类 | 对照验收标准逐条确认 | 验收核对记录 |
| 缺陷根因已定位并补充回归用例 | 缺陷类 | 查看根因说明与用例 | 缺陷记录与用例链接 |
| 涉及数据变更时有迁移与回滚验证 | 附加项 | 查看脚本与验证结果 | 迁移脚本与验证记录 |
一次工作项的核对过程
以一个“订单导出增加筛选条件”的需求为例。进入开发前，产品负责人核对就绪条目：验收标准已写明支持的筛选字段和导出格式，依赖的报表服务已确认可用，需求进入开发。开发完成后提交评审，开发者自检团队级条目，附上合并请求链接和流水线结果，评审人对照条目确认通过。迭代验收时，验收人逐条核对：团队级条目已通过，需求类条目对照验收标准逐条验证筛选字段与导出结果，全部通过后工作项进入已完成。
未通过条目的处理
同一迭代中另一个缺陷工作项在验收时未通过：根因已定位，但回归用例尚未补充。验收人记录未通过原因，工作项回流至待处理。团队在迭代内安排补充用例，完成后重新走验收核对，通过后才进入已完成。这个过程让“缺陷修复”的完成标准从“改好了”变成“改好且有回归保护”，后续同类问题可以被用例拦截。
落地完成检查与持续修订
DoD是否真正落地，不能只看有没有文档，要看条目是否被核对、未通过项是否回流。团队可以用一份检查清单在落地初期逐项判断。
落地初期的完成检查清单
- 团队已产出一份分层DoD条目表，每条包含核对方式与证据形式。
- 三个交接点都有明确的核对责任人和记录位置。
- 工作项上能直接看到适用条目，核对与状态流转在同一处完成。
- 抽查最近一个迭代的已完成工作项，每条适用条目都有对应证据。
- 存在未通过条目回流处理的记录，且回流后重新核对通过才关闭。
- DoD变更留有记录，团队知晓当前生效版本。
用抽样复核判断执行情况
条目写了不等于被核对。团队可以每个迭代随机抽取若干已完成工作项，检查每条适用条目是否有证据支撑。抽样发现的问题通常集中在两类：一类是条目本身不可验证，需要改写；另一类是核对被跳过，需要调整流程约束或提醒方式。抽样复核由Scrum Master或facilitator组织，结果在回顾中讨论，不针对个人追责，重点是找出条目和执行方式的问题。
在迭代回顾中修订条目
DoD应随团队能力提升而演进。触发修订的常见情形包括：同类问题反复出现，说明缺少对应条目；某条目连续多个迭代无人核对，说明它不适用或不可执行；团队引入了新的交付物类型，需要补充类型级条目。修订在迭代回顾中提出，由产品负责人与团队商定，Scrum Master记录变更并同步。修订宜小步进行，每次调整少量条目，便于观察效果。
控制条目收紧的节奏
条目持续增加会带来执行负担，最终导致核对流于形式。控制节奏的做法是：新增条目必须对应一个已发生的具体问题，而不是预想的理想状态；定期清理长期未被核对或已被其他机制覆盖的条目；团队级条目保持精简，把细分要求放到类型级或附加项中按需启用。DoD的目标是让完成标准清晰可执行，条目数量本身不是成果。
常见问题
团队刚开始推行DoD，条目应该写多少条合适？
初版以团队能真实执行为准。团队级条目控制在五到八条，工作项类型级每类三到五条，特殊场景附加项按需启用。条目少但每条都被核对，比清单很长却无人细看更有价值。后续可以随团队能力提升逐步补充，每次调整少量条目，便于观察效果。
DoD和单个需求的验收标准会冲突吗？
两者是不同层次的约束，可以并存。DoD回答“我们团队认为什么算完成”，对所有工作项通用；验收标准回答“这个需求做到什么程度算满足”，只针对单个需求。执行时先满足DoD的通用门槛，再逐条验证该需求的验收标准。如果DoD被写成某个需求的专属清单，它就会退化成验收标准，失去跨工作项的统一约束力。
条目在迭代中途发生变更，在途工作项按哪个版本核对？
需要团队事先约定并写进变更记录。常见做法是新进入流程的工作项按新版本核对，已在途的工作项由团队决定是否追溯。变更记录至少包含修改的条目、修改原因和生效时间，并在团队例行沟通或工作项模板中同步，避免同一迭代内标准不一致引发争议。
有些条目连续几个迭代都没人核对，该怎么处理？
先判断原因再决定去留。如果条目本身不可验证，需要改写为包含核对动作和证据形式的表述；如果条目与当前交付物无关，可以在迭代回顾中清理；如果条目已被其他机制覆盖，也可以移除。长期无人核对的条目留在清单里只会增加执行负担，让核对整体流于形式。
没有专门的质量角色，验收核对由谁来做？
可以由产品负责人承担验收核对，开发人员负责提交评审前的自检，测试职责由团队内承担测试工作的成员兼任。关键是每个交接点都有明确的核对人和记录位置，而不是依赖临时口头确认。团队规模较小时，Scrum Master或facilitator可以同时组织抽样复核，但核对与复核宜由不同的人执行，以便发现执行偏差。
