Definition of Done（完成定义，简称 DoD）是团队对“一项工作算不算真正完成”达成的一致判断标准，通常写成一份可逐条核对的清单。它约束的是完成的质量门槛，回答“做到什么程度算完成”，与描述“这次要做成什么”的验收标准分工不同。本文说明 DoD 的定义、覆盖范围、运行方式，并用示例辨析常见误解。
要点总览（TL;DR）
- Definition of Done（完成定义，简称 DoD）是团队对“一项工作算不算真正完成”达成的一致判断标准，通常写成一份可逐条核对的清单。
- DoD 覆盖代码评审、测试通过、文档更新、部署可演示等通用质量条件；单个需求的具体业务条件属于验收标准，Sprint 目标、迭代评审、需求池维护各归其位。
- DoD 通常分层组织：团队级条目适用于所有工作项，类型级条目按需求、缺陷、技术任务等补充；在计划、执行、标记完成前和评审展示前反复对照。
- DoD 与验收标准判断对象不同，与口头约定的差别在于可核对性，与质量门禁、发布标准的执行环节不同；三者可以相互引用，但适用对象不同。
- DoD 需要随团队成熟度调整，依据是反复出现的质量缺口；把 DoD 当任务清单、当验收标准、或认为一旦定下永不调整，是三种常见误解。
Definition of Done 的直接答案
Definition of Done 的中文常译为“完成定义”，简称 DoD。它是一份由团队共同确认的完成判断清单，逐条列出增量在质量、测试、文档、评审等方面需要达到的状态；只有全部满足，工作项才被认定为完成。它解决的是“完成”口径不一致的问题：同一句“做完了”，在开发、测试和产品负责人那里可能指向不同状态，DoD 把这些理解统一到同一组可核对的条件上。
可以直接引用的定义是：DoD 是团队对工作项完成质量门槛的共享约定，以可核对的条目形式说明增量必须达到的状态，用于在迭代中判断一项工作是否真正完成。它关注完成的质量条件，不规定这项工作具体要实现什么功能，后者由验收标准承担。
DoD 包括什么、不包括什么
DoD 覆盖的是“完成时必须成立”的质量与交付条件，典型类别包括：代码完成并通过评审、自动化测试通过、必要的回归测试完成、相关文档更新、用户可见的变更经过确认、部署到约定环境并可演示等。条目应当可核对，能给出明确的通过或不通过判断，避免“质量良好”“基本可用”这类无法验证的表述。
需要区分的是，DoD 与验收标准（Acceptance Criteria）分工不同。验收标准针对单个需求或用户故事，描述这个需求要满足的具体业务条件，例如某类用户能完成某项操作、某类输入会得到某种提示；DoD 针对所有工作项共同适用，描述任何增量完成时都要满足的质量门槛。一个需求可以有自己的验收标准，同时仍要满足团队统一的 DoD。
DoD 也不同于 Sprint 目标、迭代评审和需求池维护。Sprint 目标说明本次迭代要达成什么方向性结果；迭代评审用于检视增量并收集反馈；需求池维护负责需求的收集、排序与细化。这些机制各自回答不同问题，DoD 只承担完成判断这一项职责。
| 内容 | 是否属于 DoD | 归属机制 |
|---|---|---|
| 代码通过评审、测试通过、文档更新等通用质量条件 | 属于 | DoD |
| 某需求具体的业务行为与输入输出条件 | 不属于 | 验收标准 |
| 本次迭代要达成的方向性结果 | 不属于 | Sprint 目标 |
| 向相关方展示增量并收集反馈 | 不属于 | 迭代评审 |
| 需求的收集、排序与细化 | 不属于 | 需求池维护 |
DoD 如何起作用：从条目到判断
DoD 的作用方式是把抽象的质量要求转成一组可逐条勾选的判断条件，并在工作项从进行中走向完成时实际对照执行。条目通常分层组织：团队级 DoD 适用于所有工作项，规定共同的质量底线；增量级或工作项类型级的 DoD 在团队级基础上补充特定类型的条件，例如面向用户的功能需要额外的可用性确认，涉及数据变更的工作需要额外的回滚验证。分层的好处是共同条件只写一次，特殊条件按需追加。
使用时机上，DoD 在几个节点被反复对照：开始一项工作前，团队据此了解完成需要哪些动作，把测试、文档、评审纳入计划；开发过程中，成员按条目准备相应产物；工作项准备标记完成时，逐条核对是否满足，未满足的条目继续留在进行中；迭代评审展示增量前，再确认展示的内容符合 DoD。这样 DoD 成为日常判断依据，而不只是写在文档里的声明。
DoD 应随团队成熟度调整。团队刚建立时，条目可以少而具体，先保证能执行；随着自动化测试、持续集成、评审习惯逐步稳定，再把相应条件写入 DoD，提高门槛。调整的依据通常是反复出现的质量问题：某类问题多次在完成后才暴露，就考虑把对应检查加入 DoD。调整应由团队共同讨论确认，避免个人单方面加严或放宽。
- 团队级条目：适用于全部工作项的共同质量条件。
- 类型级条目：针对需求、缺陷、技术任务等不同工作项补充的条件。
- 使用节点：计划时纳入、执行中准备、标记完成前核对、评审展示前确认。
- 调整依据：反复出现的质量缺口与团队实际能力，经团队确认后更新。
当 DoD 条目需要在多人之间传递和核对时，记录方式会影响它是否真的被执行。ONES 敏捷研发管理解决方案打通「需求-研发-测试」一站式研发管理全流程，将需求提出方、产品经理、研发、测试等角色连接起来；在迭代计划会议上，产品负责人与团队对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务将需求拆分，方便后续处理和跟踪。测试工程师可根据迭代要完成的需求与验收标准编写测试用例，未通过用例可转换为缺陷并指派工程师修复。团队可以把完成判断所需的检查动作落到这些子任务、测试用例和缺陷流转中，让 DoD 条目在交接时有对应的承载位置；ONES Wiki 支持文档关联任务，也便于把团队共同的完成约定与相关工作项放在一起查阅。
容易混淆的相邻概念
DoD 最常被混用的对象是验收标准。两者的判断对象不同：验收标准判断“这个需求做对了没有”，内容随需求变化；DoD 判断“这项工作达到完成状态没有”，内容对团队内工作项普遍适用。一个需求通过验收标准，仍可能因为测试未回归、文档未更新而不满足 DoD。
DoD 与口头约定的差别在于可核对性。口头说“做完就行”没有列出条件，不同成员会按各自理解判断，出现分歧时缺少共同依据；写成条目的 DoD 让每个人面对同一组条件，判断结果可以复现。DoD 与质量门禁、发布标准有联系也有区别：质量门禁和发布标准通常作用于代码合并、版本发布等环节，由流程或工具强制执行；DoD 作用于工作项的完成判断，范围更贴近日常协作。两者可以相互引用，例如把“通过发布前检查”作为 DoD 的一条，但它们的适用对象和触发时机不同。
| 概念 | 判断对象 | 典型触发时机 | 与 DoD 的关系 |
|---|---|---|---|
| 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 是团队共享的完成约定，应由团队共同讨论确认，而不是由个人单方面加严或放宽。修改的常见触发点是反复出现的质量缺口：某类问题多次在标记完成后才暴露，团队就讨论是否把对应检查加入 DoD。产品负责人、开发、测试都应参与，确保条目既能反映质量要求，也在团队当前能力范围内可执行。
