交付后频繁返工、评审时对“是否完成”各执一词，往往源于团队对“完成”的理解停留在口头层面。DoD（完成定义）把这份共识变成逐条可核验的清单，让任务在进入评审前先过一遍检查。本文按建立现状基线、写出可核验条目并嵌入流程、用指标验证效果三步展开，并说明推行代价与校准方法；ONES可用于承载DoD条目和核验记录。
要点总览（TL;DR）
- 先翻查近一两个迭代的返工记录，按需求理解偏差、测试遗漏、文档缺失、验收口径不一致分类，区分哪些返工源于完成标准模糊，据此设定可观察的改进目标。
- 把DoD条目写成能判断真假的检查项，按任务级和迭代增量级分层维护，每条指定核验人和核验时点，核对动作放在进入评审之前。
- 评审和验收以DoD清单为判断依据，争议回到具体条目讨论；每次回顾固定一个校准环节，依据本期返工记录增删修订条目。
- 推行前评估前提与代价：团队需有稳定迭代节奏和可回溯的返工记录，初期核对会增加检查工作量，条目过严可能拖慢交付。
- 用返工任务占比、评审退回次数、交付后补做工单数、质量争议记录数按迭代对照基线，看趋势并排除人员变动、需求规模等干扰因素。
先看清现状：返工从哪来、争议卡在哪
起草DoD之前，先回答一个具体问题：过去一两个迭代里，哪些交付被打回、为什么被打回。凭印象列条目容易写成“加强测试”“注意文档”这类无法落地的要求，而从返工记录反推，条目才有针对性。建议由迭代负责人或质量角色牵头，用半天时间翻查近期任务、缺陷单和评审记录，形成一份现状基线表。
统计时按原因分类，而不是按人归类。常见类别包括：需求理解偏差（做出来的和提出方想的不一致）、测试遗漏（用例没覆盖关键路径）、文档缺失（交付物缺少说明或变更记录）、验收口径不一致（评审时才发现双方对范围理解不同）。每类记录出现频次，并标注对应的争议场景，例如“评审会上对是否算完成争论超过20分钟”“上线后被要求补做导出功能”。
| 返工原因分类 | 出现频次（近2个迭代） | 对应争议场景 | 是否可归因于完成标准模糊 |
|---|---|---|---|
| 需求理解偏差 | 示例：6次 | 评审时提出方认为范围未覆盖 | 是，验收口径未提前写明 |
| 测试遗漏 | 示例：4次 | 上线后出现明显路径缺陷 | 是，未约定必测场景 |
| 文档缺失 | 示例：3次 | 交接时被要求补写说明 | 是，未约定交付物清单 |
| 外部依赖延迟 | 示例：2次 | 接口联调推迟导致返工 | 否，属外部原因 |
表格中的数字为演示情景，团队应以自身记录替换。区分归因很重要：完成标准模糊造成的返工才是DoD能作用的部分，外部依赖、需求临时变更等需要另找机制处理，混在一起会让后续验证失真。基线最后落到改进目标上，用可观察指标表述，例如“下个迭代因验收口径不一致导致的评审退回从6次降到3次以内”“交付后补做工单数下降”。目标不必追求归零，先定一个可对照的方向。
常见误区：DoD写成口号或清单失控
不少团队推行过DoD，效果却不明显，问题通常出在写法和使用方式上。识别这些失效机制，可以避免重复踩坑。
条目无法核验。“代码质量良好”“测试充分”“文档齐全”这类表述在评审时仍然只能靠主观判断，争议从“是否完成”转移到“算不算良好”，返工照旧。可核验的条目应当能被第三方判断真假，例如“新增接口均有对应的自动化用例并通过”“变更说明已更新到发布文档”。
条目过多过细。一份三四十条的清单，团队在每次交付前逐条核对不现实，最后往往只勾选前几条或整体跳过，清单沦为形式。条目数量应与单次交付的检查时间相匹配，通常单个任务级控制在五到八条，迭代增量级再补充若干条。
单方面制定。由管理者或质量角色独自写完直接下发，开发和测试不认同条目，争议会转向“这个标准是否合理”，评审变成对标准本身的辩论。DoD需要在团队内共同确认，尤其是核验人和被核验人对同一条目理解一致。
长期不更新。技术栈升级、发布流程调整后，旧条目与实际交付动作对不上，团队逐渐不再参考。DoD应随迭代回顾定期修订，把新出现的返工原因补进去，把已不适用的条目删掉。
优先改进动作：写出可核验的DoD并嵌入交付流程
改进的核心是把DoD从一份文档变成交付流程中的一个检查节点。以下动作按顺序推进，每一步都对应减少某类返工或争议。
从高频返工原因反推条目
打开现状基线表，针对频次最高的两三类原因各写若干条目。每条写成可判断真假的检查项，并标注核验方式：看代码、跑用例、查文档、演示操作。例如针对“测试遗漏”，条目可写为“关键路径用例已执行且结果记录在测试报告中”，核验方式是查看测试执行记录；针对“文档缺失”，写为“接口变更已同步到接口文档并有变更说明”，核验方式是查阅文档版本。
按交付层级区分条目
单个任务级和迭代增量级关注点不同，用一套标准覆盖所有场景会导致要么过严拖慢小任务，要么过松漏掉集成问题。任务级条目聚焦该工作项自身的产出，如代码提交、单元测试、变更说明；增量级条目聚焦整体可交付，如回归测试通过、部署脚本可用、用户可见的验收演示完成。两层清单分开维护，评审时按层级取用。
明确核验人和核验时点
每条条目指定由谁在什么时点核对。常见安排是：开发自检代码与单元测试条目，测试核对用例执行条目，产品负责人核对验收演示条目。核验时点放在任务进入评审之前，形成“自检通过才提评审”的惯例，把争议拦截在评审会之前，减少评审退回。
以清单作为评审和验收的判断依据
评审时逐条对照DoD，符合即通过，不符合则说明缺哪条、由谁补。争议出现时回到条目本身讨论“这条是否满足”，而不是争论“我觉得还没完成”。这能把情绪化的质量争议转化为对具体检查项的确认，也便于记录争议原因用于后续校准。
在回顾中固定校准环节
每次迭代回顾留出固定时间，对照本期返工记录检查DoD：哪些返工是本应被某条目拦住的，说明条目缺失或核验未执行；哪些条目本期从未触发问题，考虑是否冗余。增删修订后更新清单版本，并在下次迭代计划时同步给全员。校准的依据是记录，不是感觉。
在工具层面，DoD条目可以作为工作项的检查项或子任务承载，核验结果随工作项状态流转留下记录；需求与验收标准在迭代计划时对齐，测试用例与缺陷跟踪衔接提测环节，返工和退回情况可从过程数据中回溯。ONES的敏捷研发管理方案覆盖需求、研发、测试的衔接，并记录缺陷分布、工作项滞留时间等过程数据，可作为承载DoD条目与核验记录的载体之一，具体配置方式需结合团队实际流程确定。
适用前提与代价：推行DoD需要投入什么
DoD不是零成本的管理动作，推进前需要评估团队是否具备条件、愿意付出相应投入。
前提条件。团队已有基本的迭代节奏和评审环节，交付物有相对固定的形态；返工问题能够被记录和回溯，否则基线无从建立，后续也无法验证效果。若团队尚处于流程搭建初期，先稳定迭代节奏，再引入DoD更稳妥。
投入代价。起草第一版DoD通常需要一次专门的工作坊或回顾时间；此后每轮校准占用部分回顾时长。初期逐条核对会增加单次交付的检查工作量，团队可能感觉节奏变慢，这部分成本需要用返工减少来抵消，通常在两三个迭代后趋于平衡。
风险与取舍。条目过严会拖慢交付，尤其在发布节奏紧张的阶段；条目过松则拦不住返工。建议从覆盖高频返工原因的最小条目集开始，按实际效果逐步增补，而不是一次写全。条目数量与可执行性之间的平衡需要团队自己判断。
组织条件。评审、测试、开发需要对同一份清单达成认可。单方面推行时，被核验方容易把清单视为额外负担，核验流于形式。让各角色参与条目制定，并明确每条由谁核验，是持续执行的基础。
效果验证：用哪些指标判断返工和争议是否减少
改进是否生效，需要用改进前的基线做对照，而不是凭一次回顾的感受下结论。选取与目标直接相关的几项指标，按迭代观察趋势。
| 指标 | 基线值（改进前） | 观察周期 | 可能的干扰因素 |
|---|---|---|---|
| 返工任务占比 | 示例：近2个迭代平均18% | 连续3个迭代 | 需求规模变化、人员变动 |
| 评审退回次数 | 示例：每迭代6次 | 连续3个迭代 | 评审范围调整 |
| 交付后补做工单数 | 示例：每迭代5个 | 连续3个迭代 | 发布节奏变化 |
| 质量争议记录数 | 示例：每迭代4条 | 连续3个迭代 | 记录习惯改变 |
表中数值为演示假设，团队应填入自身基线。解读时注意三点：一是看趋势而非单点，一个迭代的下降可能来自需求变小或人员充足；二是排除干扰，人员变动、需求规模、发布节奏调整都会影响指标，需在对比时说明；三是区分相关与因果，指标改善的同时若流程还有其他变化，不能全部归功于DoD。
若指标没有改善，先回到DoD条目本身检查：是否覆盖了真实返工原因，核验是否真的在执行，条目是否被评审环节实际使用。常见情况是条目写了但没人核对，或核对发生在评审之后，此时调整执行方式比否定做法更有效。验证的终点不是数字好看，而是团队在评审时能指着清单说清“完成”指什么，返工原因能被逐条对应到检查项上。
常见问题
团队规模小、迭代节奏还不稳定，适合现在就推行DoD吗？
可以先做简化版。前提是交付物有相对固定的形态、返工能被记录下来，否则基线无从建立。若迭代节奏尚不稳定，建议先稳定评审环节和任务拆分方式，再引入DoD。起步时只针对频次最高的返工原因写三到五条任务级条目，跑两三个迭代看效果，再考虑补充增量级条目。
DoD和验收标准（AC）有什么区别，需要两份都写吗？
两者作用范围不同。验收标准针对单个需求或用户故事，说明这个需求做成什么样算满足；DoD是团队层面的通用完成标准，适用于所有工作项，例如代码提交、测试执行、文档更新等。实践中两份都需要：验收标准随需求走，DoD作为进入评审前的通用检查。写DoD时避免把某个需求特有的验收条件塞进去，否则清单会不断膨胀。
条目写了但评审时没人核对，怎么让DoD真正被执行？
先检查核验时点是否放在了评审之前。若核对发生在评审会上，时间压力下容易被跳过。可以把核验设为提评审的前置动作，由开发自检、测试核对用例、产品负责人核对验收演示，各自对自己的条目负责。另外在回顾中统计“哪些返工是本应被条目拦住的”，用具体案例说明条目未执行的代价，比反复强调纪律更有效。
DoD条目应该多久校准一次，由谁发起？
建议每个迭代回顾固定留出一段校准时间，由迭代负责人或质量角色牵头，全员参与。校准依据是本期返工记录和评审争议记录，而不是个人感受：本应被拦住却没拦住的返工，说明条目缺失或核验未执行；长期未触发问题的条目，考虑是否冗余。修订后更新清单版本，在下一次迭代计划时同步给全员，避免新旧版本混用。
指标没有改善，是不是说明DoD这个方法没用？
先排查执行层面再下结论。常见情况包括条目没有覆盖真实返工原因、核验流于形式、核对发生在评审之后。也可能是指标受干扰，例如需求规模变小、人员变动或发布节奏调整。建议回到DoD条目本身逐条对照返工记录，确认覆盖范围和执行情况；若条目和执行都到位而指标仍无变化，再考虑调整指标口径或改进方向。
