落地Definition of Done（DoD）的关键，是把“完成”从个人判断变成团队共同认可、可逐项核对的清单：先由团队共同起草一份覆盖代码质量、测试、文档、评审与可交付状态的DoD，明确每条标准的验证方式和证据；再把它挂到工作项状态流转的“完成”关口，让每次交付按同一口径检查；最后通过迭代回顾定期修订，处理标准过松或过严的问题。落地不是一次性写文档，而是让DoD成为团队日常交付的检查依据。
要点总览（TL;DR）
- DoD是团队对“工作项完成”的共同约定，约束通用质量底线；验收标准约束单个需求的功能边界，两者分工不同。
- 起草DoD从近期返工、漏测、上线后问题反推条目，按代码质量、评审、测试、文档、可部署分组，每条写清验证方式与证据形式。
- 把DoD绑定到工作项状态流转的完成关口，未满足条目按退回、挂起、标注例外三种方式处理，并留下可查证据。
- 开发自查、测试与产品负责人分别把关对应条目，团队负责人组织起草、推动执行并维护版本记录。
- 在迭代回顾中检查退回原因与上线问题，识别过松或过严信号，按触发条件修订并记录生效迭代。
先明确DoD要解决什么问题、覆盖哪些层级
DoD回答的是一个具体问题：一个工作项在什么条件下可以被称为“完成”。它约束的是团队交付的通用质量底线，对每个工作项都适用。与之相邻的验收标准（Acceptance Criteria）约束的是单个需求的功能边界，说明这个需求要做成什么样才算满足业务预期。两者的关系可以这样理解：验收标准决定“做对的事”，DoD决定“把事做完整”。一个需求即使满足了全部验收标准，只要代码未评审、测试未通过、文档未更新，按DoD仍然不能标记完成。
DoD通常分两层来写，避免一份清单承担过多职责。
| 层级 | 适用范围 | 主要内容 | 维护者 |
|---|---|---|---|
| 团队级DoD | 本团队所有工作项 | 代码规范、评审要求、测试通过标准、文档更新、可部署状态 | 研发团队共同维护 |
| 产品级/组织级DoD | 跨团队交付或对外发布 | 发布说明、合规检查、安全扫描、上线审批等组织统一要求 | 产品负责人或质量负责人牵头 |
团队级DoD是本文的重点，它由团队自己起草、自己执行、自己修订，条目数量控制在团队能逐项核对的范围内。产品级DoD作为上层约束，团队级DoD在其基础上补充本团队的具体做法，两者冲突时以更严格的要求为准。规模较小的团队可以只维护一份团队级DoD，把组织统一要求并入其中，等跨团队协作增多再拆分。
需要划清边界的是：DoD定义“完成的标准”，不负责安排“什么时候做、由谁做”。迭代如何规划、回顾会如何组织，属于迭代管理的范畴；需求如何收集、优先级如何排序，属于需求池管理的范畴。本文只讨论完成定义本身的起草、嵌入、分工与维护。
起草DoD：从现有交付问题反推清单条目
从零写一份DoD，容易写成“代码质量要好、测试要充分”这类无法核对的表述。更有效的做法是从团队近期真实发生的交付问题出发，反推需要哪些检查条目。具体分四步。
第一步，收集输入。回顾最近一到两个迭代中出现的返工、漏测和上线后问题，每个问题记录三件事：发生了什么、在哪个环节被漏掉、如果当时检查了什么就能提前发现。例如“上线后发现接口未做异常处理导致报错”，漏掉的是代码评审中的异常分支检查；“测试环境通过但生产配置缺失”，漏掉的是部署清单核对。这些案例就是DoD条目的来源。
第二步，按维度分组列条目。把收集到的问题归入代码质量、测试验证、文档、评审、可部署状态五个维度，每个维度写出对应的检查条目。条目用“动词＋对象＋标准”的句式，避免形容词。示例如下：
| 维度 | 条目示例 | 验证方式 | 证据形式 |
|---|---|---|---|
| 代码质量 | 代码已通过静态检查，无新增严重告警 | 查看检查报告 | 检查报告链接 |
| 评审 | 至少一名非作者成员完成代码评审并批准 | 查看评审记录 | 评审意见与批准状态 |
| 测试验证 | 新增功能有对应测试用例且全部通过 | 执行测试并查看结果 | 测试记录或用例执行结果 |
| 文档 | 接口变更已更新接口文档，操作变更已更新使用说明 | 核对文档版本 | 文档链接 |
| 可部署状态 | 构建产物可部署到测试环境并完成一次验证 | 实际部署验证 | 部署记录 |
第三步，为每条附上验证方式与证据形式。一条DoD如果说不清“怎么验证、留下什么”，执行时就会退回到主观判断。验证方式要具体到动作，证据形式要具体到可查看的载体。团队可以接受口头确认的条目，应明确写出“由谁确认”，避免无人负责。
第四步，团队评审定稿。把初版清单拿到团队会议上逐条讨论，重点处理三类条目：团队认为不必要、验证成本过高、当前做不到的。对暂时做不到但确实重要的条目，标注为“下阶段目标”而不是直接删除，保留改进方向。完成标志是：团队对每条内容无争议，每条都有明确的验证方式和证据形式，清单获得团队共同认可并记录版本。
把DoD挂到工作项状态流转的完成关口
清单写完放在文档里，执行时很容易被跳过。让DoD真正生效的做法，是把它绑定到工作项的状态流转上，尤其是从“开发中”进入“完成”或“待验收”的那一步。
| 状态流转 | DoD检查点 | 需要留下的证据 | 未满足时的处理 |
|---|---|---|---|
| 开发中 → 待评审 | 代码已提交、静态检查通过、评审已发起 | 提交记录、检查报告、评审请求 | 退回开发中，补齐后重新提交 |
| 待评审 → 待测试 | 评审已批准、测试用例已编写 | 评审批准记录、用例链接 | 挂起，等待评审完成 |
| 待测试 → 待验收 | 测试全部通过、文档已更新、构建可部署 | 测试结果、文档链接、部署记录 | 退回待测试或标注例外并说明原因 |
| 待验收 → 完成 | 验收标准满足、DoD全部条目核对完毕 | 验收记录、DoD核对结果 | 不进入完成状态 |
证据留痕的方式要与团队现有工具衔接。测试结果可以来自测试用例执行记录，评审记录可以来自代码评审系统，文档链接指向团队知识库中的对应页面。关键在于证据与工作项关联，检查时能从一个入口看到全部依据，而不是分散在多个系统里靠人回忆。
未满足条目时的处理需要事先约定，避免每次临时争论。常见做法有三种：条目属于硬性要求且可快速补齐的，退回上一状态；条目依赖外部条件暂时无法满足的，挂起并记录阻塞原因；条目确实不适用于当前工作项的，标注例外并由指定角色确认。例外不能成为常态，如果同一类例外反复出现，说明该条目需要重新评估。
在工具承载上，ONES 支持自定义需求状态与多种属性，团队可以按上述流转设置状态节点；ONES Wiki 支持文档关联任务，便于把文档类证据挂到工作项上；测试与缺陷数据互通，测试结果和缺陷状态可以作为测试类条目的核对依据。具体检查点是否强制校验，需要团队结合自身配置确定。
角色分工：谁起草、谁检查、谁维护DoD
DoD由团队共同拥有，但不同环节需要明确的责任人，否则容易出现“大家都认可、没人执行”的局面。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 开发人员 | 起草代码质量、评审、可部署类条目；提交时按条目自查并附证据 | 条目草案、自查记录、代码与构建产物 |
| 测试人员 | 起草测试验证类条目；执行测试并记录结果；对测试类条目把关 | 测试条目、测试记录、缺陷清单 |
| 产品负责人 | 起草文档与验收相关条目；确认验收标准与DoD的衔接；参与条目争议裁决 | 文档条目、验收记录、裁决意见 |
| Scrum Master或团队负责人 | 组织起草与评审会议；推动DoD进入状态流转；在回顾中主持执行情况检查；维护版本记录 | 会议记录、DoD版本记录、回顾改进项 |
检查环节遵循“谁交付、谁自查，谁把关、谁确认”的原则。开发人员在工作项提交前按DoD逐项自查并附上证据，测试人员和产品负责人分别对测试类、文档与验收类条目确认。团队负责人不代替成员检查，而是确保检查动作发生、证据可查。
DoD的变更需要明确批准权限。建议由团队负责人在团队达成共识后批准变更，涉及产品级要求的条目需产品负责人共同确认。变更必须留下记录：改了什么、为什么改、从哪个迭代开始生效。没有记录的变更会让团队对“当前标准是什么”产生分歧。
一个研发团队的DoD落地示例
以下为演示情景，用于说明清单与检查走查的完整过程，不代表真实客户案例。
某六人研发团队负责一个内部业务系统的迭代开发。团队在回顾中发现，近两个迭代有三次上线后问题，分别源于接口异常未处理、测试用例遗漏边界场景、部署配置未同步。团队据此起草了团队级DoD：
- 代码质量：静态检查无新增严重告警；关键逻辑有异常处理。
- 评审：至少一名非作者成员完成评审并批准。
- 测试验证：新增功能有对应用例，覆盖正常与边界场景，全部通过。
- 文档：接口变更更新接口文档，配置变更更新部署说明。
- 可部署：构建产物在测试环境完成一次部署验证。
一次工作项的检查走查如下。开发人员完成“订单查询接口增加分页参数”的开发后，先自查：静态检查报告无严重告警，异常分支已处理；发起评审，一名同事批准并留下意见；编写了正常分页与超出范围两类用例并执行通过；更新了接口文档中的参数说明；在测试环境部署验证通过。随后工作项从“开发中”流转到“待测试”，测试人员核对用例执行记录后确认测试类条目，产品负责人核对接口文档后确认文档类条目，工作项进入“待验收”，最终完成。
争议处理示例：某次工作项涉及一处内部工具脚本，团队对“是否需要更新接口文档”产生分歧。处理方式是：确认该脚本不对外提供接口，文档类条目不适用，由产品负责人标注例外并记录原因；同时在回顾中讨论是否需要在DoD中补充“内部工具类工作项的文档要求”，最终增加一条“内部工具需在知识库留下使用说明”，从下个迭代生效。
用回顾与度量维护DoD，避免过松或过严
DoD写完之后会随团队能力变化而失效。过松的DoD让问题继续流出，过严的DoD让交付节奏被检查拖慢。维护机制的核心是在迭代回顾中固定检查DoD的执行情况与条目有效性。
回顾时可以看三类信息：本迭代有多少工作项在完成关口被退回、退回原因集中在哪些条目；上线后问题中是否有DoD本应拦截却未拦截的；团队成员是否反映某些条目验证成本过高。这些信息帮助判断DoD是否需要调整。
| 信号 | 可能原因 | 调整方向 |
|---|---|---|
| 上线后同类问题反复出现 | DoD缺少对应条目，或条目验证方式太模糊 | 补充条目，明确验证方式与证据 |
| 大量工作项在完成关口被退回同一类条目 | 条目要求超出当前团队能力，或流程前置不足 | 评估条目是否分阶段引入，或把检查前移到开发过程 |
| 检查流于形式，证据缺失仍被放行 | 条目过多、核对成本高，或缺少责任人 | 精简条目，明确把关角色 |
| 团队普遍认为检查拖慢交付 | DoD过严或验证方式低效 | 合并重复条目，改用自动化检查替代人工核对 |
修订的触发条件建议明确写下来：出现DoD未拦截的上线问题、同一例外反复出现、团队能力或技术栈发生明显变化、连续两个迭代出现同类退回。触发后由团队负责人在回顾中提出，团队讨论形成变更，记录版本与生效迭代。ONES 支持通过燃尽图、工时日志、持续集成报告等数据报表复盘迭代进度、质量和成本偏差，并可用 ONES Wiki 沉淀经验，这些数据可以作为判断DoD是否有效的参考。
落地完成检查：逐项核对DoD是否真正生效
判断DoD是否落地，不看文档写得多完整，而看团队日常交付是否真的按它执行。以下清单可逐项核对：
- DoD清单由团队共同讨论形成，成员能说出主要条目及其含义。
- 清单有版本记录，每次变更都记录了改了什么、为什么改、从哪个迭代生效。
- 工作项在进入完成状态前，按DoD逐项核对，核对结果与证据可在工作项上查到。
- 完成关口被退回的工作项有明确原因，原因能对应到具体条目。
- 迭代回顾中有DoD执行情况的讨论记录，过松或过严的信号被识别并处理。
- 例外标注有指定角色确认，且例外没有在同一类条目上反复出现。
- 新成员入职后，能依据DoD独立判断一个工作项是否可以标记完成，无需逐次询问老成员。
- 上线后问题复盘时，能说清该问题是否属于DoD应覆盖的范围，以及是否需要补充条目。
这份清单中，前两项检验DoD是否被共同认可，中间四项检验它是否进入日常流程，最后两项检验它是否形成团队能力。多数条目能稳定满足时，DoD已经从一份文档变成了团队的交付习惯；若多项长期不满足，应回到起草与嵌入环节，检查条目是否可核对、检查点是否真正卡在状态流转上。
常见问题
团队规模很小，还需要区分团队级和产品级DoD吗？
规模较小的团队可以先只维护一份团队级DoD，把组织统一要求并入其中，条目数量控制在能逐项核对的范围内。等跨团队协作增多、对外发布需要统一合规检查时，再把产品级或组织级要求拆出来单独维护。拆分的目的在于让每份清单的维护者和适用范围清晰，与团队人数没有必然关系。
某个DoD条目在当前工作项上确实不适用，怎么处理才不破坏规则？
建议事先约定例外处理方式：由指定角色确认后标注例外，并记录不适用的原因。例外需要可追溯，例如在回顾中检查同一类例外是否反复出现。如果某类例外连续出现，说明该条目本身需要重新评估，应进入修订流程，而不是继续逐次标注例外。
DoD条目太多导致检查成本高，应该删减还是保留？
先区分两类条目：能拦截真实问题且验证动作简单的保留；验证成本高但价值有限的，考虑合并或改用自动化检查替代人工核对。也可以把部分检查前移到开发过程中，减少完成关口的集中核对压力。删减的依据来自回顾中的退回记录和上线问题，而非单纯凭感觉压缩条目数量。
DoD和验收标准在检查时如何衔接，避免重复核对？
验收标准针对单个需求的功能边界，由产品负责人在验收环节确认；DoD针对所有工作项的通用质量要求，在状态流转的完成关口核对。两者检查对象不同，可以在同一工作项上分别核对：先确认验收标准满足，再按DoD逐项检查代码、测试、文档与可部署状态，证据分别留痕即可。
DoD修订后，正在进行中的工作项按哪个版本执行？
建议在变更记录中写明生效迭代，新版本从约定迭代开始适用于新进入完成关口的工作项。已在途工作项可按原版本执行完毕，避免中途更换标准造成争议。具体切换方式由团队在回顾中商定并记录，保持口径一致即可。
