Definition of Done（完成定义，简称DoD）适合用在需要统一“什么算做完”判断标准的研发管理场景。它把“基本完成”“差不多了”这类模糊说法变成可核对的清单，让开发、测试、产品在交付前对同一件事有共同判断。迭代交付验收、跨角色交接、发布前检查、外包交付和缺陷修复闭环是典型适用场景；需求高度不确定、团队协作纪律尚弱时，宜先小范围试点，暂缓全面推行。
要点总览（TL;DR）
- DoD适合需要统一“什么算做完”判断标准的场景：迭代交付验收、跨角色交接、发布前检查、外包交付、缺陷修复闭环。
- DoD的价值在于把隐含的完成判断变成团队共识清单，减少环节间退回和验收争议；它与单个需求的验收标准、测试用例分属不同层次。
- 推行DoD需要前期共同制定清单、明确各角色职责，并嵌入迭代计划、评审、验收和回顾的既有节奏。
- 需求高度不确定、协作纪律尚弱、把清单用作个人考核或清单过长时，宜先小范围试点或暂缓全面推行。
- 试点选一个迭代或一类工作项，观察退回次数、验收争论和交接等待是否减少，再决定是否扩大。
先给结论：哪些场景值得用Definition of Done
DoD的核心作用，是给“完成”建立一个团队共同认可、可以逐项核对的判断标准。它回答的问题很具体：一个需求、一个任务或一次修复，要满足哪些条件，团队才认为它可以交给下一环节或对外发布。只要团队在交付过程中反复出现“谁觉得算完成”的分歧，DoD就有采用价值。
值得优先采用的场景有五类：迭代交付与验收，需要每个迭代结束时对交付物形成一致判断；跨角色协作与交接，设计、开发、测试之间需要明确的交接条件；质量门禁与发布前检查，需要在发布前确认关键检查项已经完成；外包或跨团队交付，双方对交付质量的理解容易不一致；缺陷与技术支持修复闭环，需要界定修复到什么程度才算关闭。
需要谨慎或暂缓的情形同样明确：需求与交付物高度不确定，事先难以描述完成条件；团队连基本的任务拆分和状态更新都难以坚持；组织打算把DoD直接用作个人考核依据；清单越列越长，执行逐渐流于形式。这些情况下，DoD容易变成一份写了没人看的文档，先解决协作基础比推行清单更有效。
DoD解决的是什么管理问题
研发交付中的返工和验收争议，很多源于“完成”的判断不一致。开发认为代码提交、自测通过就算完成，测试认为还要覆盖异常场景，产品认为还要包含文档和上线说明。各方都没有错，但判断标准不同，结果就是交付物在环节之间来回退回，评审会上反复争论“这算不算做完”。
DoD的机制是把这种隐含判断显性化。团队在迭代开始前共同约定一份清单，例如代码已评审、单元测试通过、关键路径测试用例已执行、相关文档已更新、产品负责人已确认验收标准。每个工作项进入“完成”状态前，逐项核对清单。判断依据从个人经验变成团队共识，交接时减少口头解释，验收时减少临时加码。
需要区分DoD与相邻概念。验收标准（Acceptance Criteria）针对单个需求，描述这个需求要满足什么业务条件；测试用例描述如何验证这些条件；DoD则是跨需求、跨工作项通用的完成条件清单，回答“我们团队认为做完要满足哪些共性要求”。三者层次不同，配合使用：验收标准管“这个需求对不对”，测试用例管“怎么验证”，DoD管“交付前还差哪些动作”。
适用条件：团队与场景需要具备什么
DoD能否发挥作用，取决于场景特征与团队前提是否匹配。下表按场景类型对照适配理由与需要具备的条件。
| 场景类型 | 适配理由 | 需要具备的条件 |
|---|---|---|
| 迭代交付与验收 | 每个迭代结束都需要对交付物形成一致判断，清单可直接用于评审前自查 | 迭代周期相对稳定，需求在迭代内有基本边界，团队愿意在计划阶段共同确认完成条件 |
| 跨角色协作与交接 | 设计、开发、测试之间的交接容易因判断不同产生等待和退回 | 角色分工清晰，交接动作可以描述为具体检查项，各方参与清单制定 |
| 质量门禁与发布前检查 | 发布前需要确认关键检查项已完成，清单提供可核对的发布前依据 | 存在相对固定的发布流程，关键检查项可以事先列出，发布责任人有权限执行检查 |
| 外包与跨团队交付 | 双方对交付质量的理解容易不一致，书面清单可作为交付约定的一部分 | 合同或协作协议中能约定交付条件，双方认可同一份清单，验收人有明确判断依据 |
| 缺陷与支持修复闭环 | 修复到什么程度算关闭，常因缺少统一条件而反复 reopen | 缺陷分级基本清晰，修复验证动作可以标准化，关闭权限归属明确 |
这些场景的共同前提是：团队具备基本的协作纪律，任务有明确负责人，状态更新能反映真实进展，评审和验收有固定节奏。DoD是一份共识清单，它依赖团队愿意按清单核对，也依赖工作项状态能够被如实维护。缺少这些前提，清单本身无法替代协作习惯。
投入与前提：推行DoD要准备什么
推行DoD的投入主要在前期制定和持续维护，而不是一次性写完就结束。团队通常需要安排一到两次专门讨论，把当前交付中反复出现的退回原因、验收争议整理出来，转化为可核对的检查项。清单初版宜控制在团队能记住和执行的范围内，随后在每个迭代回顾中根据实际执行情况增删调整。
参与角色需要明确。产品负责人或需求提出方参与确认业务侧完成条件；开发负责人关注代码评审、测试覆盖和文档更新；测试负责人关注验证动作是否执行；项目管理者负责组织清单制定、跟踪执行情况并在回顾中推动修订。清单由团队共同约定，单一角色单方面制定，执行时容易失去认同。
DoD需要与现有流程衔接。迭代计划阶段确认本迭代适用的完成条件，迭代评审前按清单自查，验收环节以清单作为核对依据，回顾会议评估清单是否仍然有效。这样DoD嵌入既有节奏，不额外增加一套独立流程。
工具承载方式影响执行成本。清单可以放在团队文档中，与工作项关联，便于交付时对照；工作项状态可以按团队约定设置，使“完成”状态对应清单核对通过；测试用例与缺陷记录可以和工作项关联，形成从需求到验证的完整链路。以ONES为例，ONES Project支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；ONES Wiki支持文档关联任务，并可插入工作项列表，适合承载团队共享的完成定义清单。测试工程师可依据迭代要完成的需求与验收标准编写测试用例，未通过用例可转换为缺陷提交至项目并指派修复。这些能力用于承载清单与验证动作，具体可用功能随所选版本与配置而定。
暂缓条件：哪些情况先不要全面推行
需求与交付物高度不确定时，事先写出的完成条件很快失效。探索型项目、早期产品验证阶段，交付物本身在过程中才逐渐清晰，此时更适合用轻量的验收讨论代替固定清单，等交付形态相对稳定后再引入DoD。
团队协作纪律尚不成熟时，推行清单容易变成额外负担。任务没有明确负责人、状态长期不更新、评审会不定期召开，这些情况下先建立基本的任务拆分和状态维护习惯，再考虑统一完成标准。
把DoD当作考核工具会带来明显风险。一旦清单被用来给个人打分，成员倾向于选择容易达成的检查项，或者在工作项尚未真正完成时提前勾选，清单反而失去判断价值。DoD适合作为团队交付的自检依据，不宜直接转化为个人绩效指标。
清单过长同样会导致执行流于形式。检查项超过团队能实际核对的规模，成员会跳过核对直接标记完成。初版清单聚焦当前最常引发返工和争议的几项条件，比追求全面更有效。
试点判断：如何小范围验证是否适合
试点宜选择一个迭代或一类工作项，而不是全团队全流程同时铺开。选择近期返工较多或验收争议较集中的场景，例如某个业务模块的迭代交付，或缺陷修复的关闭环节，制定一份精简清单，在迭代内执行并记录执行情况。
试点期间重点观察几类信号：交付物因“未达完成条件”被退回的次数是否减少；评审和验收时关于“算不算做完”的争论是否减少；跨角色交接的等待时间是否缩短；清单核对是否被实际执行，还是被跳过。这些信号比主观感受更能说明清单是否贴合团队实际。
试点结束后做一次复盘，回答三个问题：清单中的检查项是否确实对应了此前的返工原因；执行成本是否在团队可接受范围内；未执行或执行走样的检查项，是清单设计问题还是协作习惯问题。如果退回和争议明显减少、执行成本可控，可以逐步扩大到更多工作项；如果清单频繁被跳过或引发新的争论，应先调整清单范围与团队协作方式，再决定是否继续推行。
常见问题
DoD和验收标准、测试用例应该怎么分工？
三者层次不同。验收标准针对单个需求，描述这个需求要满足什么业务条件；测试用例说明如何验证这些条件；DoD是跨需求、跨工作项通用的完成条件清单，回答团队交付前还要完成哪些共性动作。实践中可以这样配合：验收标准管“这个需求对不对”，测试用例管“怎么验证”，DoD管“交付前还差哪些动作”。如果团队把三者混成一份清单，容易出现单个需求的特殊条件和团队通用条件纠缠，维护成本上升。
团队刚开始推行DoD，清单应该写多少项？
初版清单宜聚焦当前最常引发返工和验收争议的几项条件，控制在团队能实际核对的范围内。清单过长时，成员容易跳过核对直接标记完成，清单反而失去判断价值。可以先从代码评审、关键测试执行、文档更新、验收确认这几类高频条件入手，在每个迭代回顾中根据实际执行情况增删。判断标准是：清单上的每一项，团队都能说清它对应此前的哪类退回或争议。
把DoD写进工作项状态或检查项，需要注意什么？
工具承载的目的是降低核对成本，而不是增加一套独立流程。可以把清单放在团队共享文档中并与工作项关联，让“完成”状态对应清单核对通过，测试用例和缺陷记录与工作项关联，形成从需求到验证的链路。以ONES为例，ONES Project支持自定义需求状态与多种属性，可将需求和相关任务规划至迭代、分配负责人；ONES Wiki支持文档关联任务并插入工作项列表，适合承载团队共享的完成定义清单。具体可用功能随所选版本与配置而定。
外包或跨团队交付时，DoD怎么落地才不容易扯皮？
关键在于把完成条件写进双方认可的交付约定，而不是只放在内部文档里。合同或协作协议中约定交付条件，双方对同一份清单达成一致，验收人按清单逐项判断。清单中的检查项要能对应可观察的交付物或验证动作，避免“质量达标”这类无法核对的表述。交付前由交付方自查、接收方按同一清单核对，出现分歧时回到清单条目讨论，比临时追加要求更容易达成一致。
试点结束后，什么信号说明可以扩大推行？
重点看几类可观察的信号：交付物因未达完成条件被退回的次数是否减少；评审和验收时关于“算不算做完”的争论是否减少；跨角色交接的等待时间是否缩短；清单核对是否被实际执行。如果退回和争议明显减少、执行成本在团队可接受范围内，可以逐步扩大到更多工作项。如果清单频繁被跳过或引发新的争论，先判断是清单设计问题还是协作习惯问题，调整后再决定是否继续。
