Definition of Done（完成定义，简称 DoD）是团队对“一个工作项算不算真正完成”达成的一致判定标准。它用一份可检查的条件清单说明增量是否达到可交付质量，对同类工作项统一适用；它说明完成的含义与边界，与针对单个需求的验收标准分工不同。
要点总览（TL;DR）
- Definition of Done（完成定义，简称 DoD）是团队共同约定的、对同类工作项统一适用的完成条件清单，用来判断增量是否达到可交付质量。
- DoD 覆盖质量条件与可交付状态，不覆盖具体实现步骤、个人任务拆解和需求优先级；它与针对单个需求的验收标准层级不同，需要同时满足。
- 一份可用的 DoD 通常按代码与评审、测试通过、文档更新、可部署或可演示等类别组织，条件要能换人复核，并在完成判定与评审环节逐项核对。
- DoD 随团队成熟度调整，调整应经团队讨论形成新版本，避免个人私自加严或放宽。
- 常见误解包括把 DoD 当成验收标准、当成个人承诺、写成无法验证的口号，后果是完成口径不一、返工与交付争议。
Definition of Done 的直接答案
Definition of Done 的中文通常译为“完成定义”，在敏捷团队中简称 DoD。它回答的核心问题只有一个：一个工作项在什么条件下才算完成。这个问题看似简单，实际决定了团队对“完成”的共识是否一致。没有统一口径时，开发人员说“做完了”可能指代码写完，测试人员说“做完了”可能指用例跑通，产品负责人说“做完了”可能指可以给用户演示，三种理解并存就会在交付环节产生争议。
DoD 由团队共同约定，而不是由某个人单独制定。约定过程本身有价值：它迫使团队把隐含的质量期待说出来，形成可共同遵守的规则。约定完成后，DoD 对同一类工作项统一适用，例如所有用户故事共用一份 DoD，所有缺陷修复共用另一份 DoD。统一适用意味着它不因某个需求紧急而临时放宽，也不因某个人经验丰富而默认跳过。
DoD 常见的载体形式包括：一份列在团队空间中的检查项清单、写在任务模板里的完成条件字段、贴在看板上的团队约定文档，或者评审会议中逐项核对的检查表。形式可以灵活，关键是团队成员能随时查阅、在判定时逐条对照。一份可直接引用的定义是：DoD 是团队共同约定的、对同类工作项统一适用的完成条件清单，用来判断增量是否达到可交付质量。
DoD 的边界：包括什么、不包括什么
把 DoD 的范围划清楚，能避免它变成什么都往里装的筐。DoD 覆盖的是质量条件与可交付状态，也就是“达到什么程度才算完成”；它不覆盖具体实现步骤、个人任务拆解和需求优先级，这些属于执行与规划层面的内容。
| 维度 | DoD 包括 | DoD 不包括 |
|---|---|---|
| 内容性质 | 质量条件、可交付状态、团队级统一要求 | 具体实现步骤、技术方案选型 |
| 适用范围 | 对同一类工作项统一适用 | 针对单个需求的具体验收条件 |
| 管理层面 | 完成的判定口径 | 个人任务拆解、需求优先级排序 |
| 与其他约定的关系 | 与验收标准配合使用 | 替代 Sprint 目标或迭代流程 |
DoD 与验收标准的区别是边界问题中最常被问到的一点。验收标准针对单个需求，描述这个需求要满足哪些具体业务条件，例如“用户提交订单后 3 秒内收到确认邮件”；DoD 则是通用要求，对同类工作项都成立，例如“代码通过评审、自动化测试通过、相关文档已更新”。验收标准回答“这个需求做对了吗”，DoD 回答“这类工作项按团队标准做完了吗”。两者层级不同，需要同时满足。
DoD 与 Sprint 目标、迭代流程也有分工。Sprint 目标说明这一轮迭代要达成什么业务结果，迭代流程规定计划、执行、评审、回顾如何开展，DoD 则规定每个工作项在流程中被判定完成的质量门槛。DoD 不替代 Sprint 目标，也不规定迭代会议怎么开，它只在“完成判定”这个节点上起作用。
DoD 由哪些条件组成
一份可用的 DoD 通常按条件类别组织，而不是把所有要求混成一段话。典型类别包括：代码与评审，例如代码已提交、通过同伴评审、符合团队编码规范；测试通过，例如单元测试与自动化测试通过、必要的回归测试完成；文档更新，例如接口文档、使用说明或变更记录已同步；可部署或可演示，例如构建产物可部署到测试环境、功能可在评审中演示。
条件应可检查、可验证，避免模糊表述。“代码质量良好”无法判定，“代码通过至少一名同伴评审且静态检查无阻断项”可以判定。“测试基本通过”无法判定，“相关自动化测试全部通过，未通过用例已记录并评估”可以判定。写 DoD 时可以用一个简单测试：换一个不熟悉该需求的团队成员，能否仅凭这条条件判断通过与否。如果答案是否定的，这条条件就需要改写。
DoD 的生效方式是在评审与交付环节逐项核对。团队在将工作项状态改为“完成”之前，对照 DoD 清单逐条确认；在 Sprint 评审中，展示的增量也应满足 DoD，否则不进入可交付范围。逐项核对的价值在于把判定从个人感觉变成共同检查，减少“我以为完成了”的情况。
DoD 随团队成熟度调整。团队初期可能只要求代码评审与基本测试通过；随着自动化测试覆盖提升、发布流程规范，DoD 可以加入更严格的条件，例如性能基线检查、安全扫描通过。调整应经过团队讨论并形成新版本，避免个人私自加严或放宽。调整频率不宜过高，每次迭代都改会让判定口径失去稳定性。
当团队把完成口径落到协作工具中时，需要的是让条件可查、状态可追踪、评审有记录。ONES 敏捷研发管理解决方案打通需求、研发、测试流程，将需求提出方、产品经理、研发、测试等角色连接起来；在迭代计划中，产品负责人与团队就需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，测试工程师依据验收标准编写并执行测试用例，未通过用例可转为缺陷提交。团队可以把 DoD 作为完成判定的共同约定，借助需求状态、子任务与看板跟踪逐项确认的结果，让“完成”在交接时有据可查。
DoD 与相邻概念的区别
DoD 容易与几个相邻概念混淆，用同一口径对照能看清各自的位置。下表从适用对象、回答的问题和典型内容三个角度做区分。
| 概念 | 适用对象 | 回答的问题 | 典型内容 |
|---|---|---|---|
| Definition of Done | 同一类工作项，团队统一适用 | 这类工作项达到什么质量才算完成 | 代码评审、测试通过、文档更新、可演示 |
| 验收标准（Acceptance Criteria） | 单个需求或用户故事 | 这个需求要满足哪些具体业务条件 | 特定输入下的预期行为、边界条件 |
| Sprint 完成定义 | 一轮迭代的增量 | 本轮迭代产出是否达到可发布状态 | 增量集成、整体可演示、无阻断缺陷 |
| 发布就绪 | 一次发布 | 是否具备上线条件 | 部署检查、回滚方案、上线审批 |
| 任务清单（To-Do） | 个人或小组的执行事项 | 还有哪些动作要做 | 待办事项、负责人、截止时间 |
| 质量门禁 | 流程中的检查节点 | 是否允许进入下一阶段 | 自动化检查规则、阻断条件 |
DoD 与验收标准的层级差异最值得强调：验收标准是需求级的，每个需求可以不同；DoD 是团队级的，同类工作项共用。一个需求同时满足自己的验收标准和团队的 DoD，才算真正完成。Sprint 完成定义可以理解为 DoD 在迭代增量层面的延伸，关注整轮迭代的产出是否可交付；发布就绪则更靠近上线环节，关注部署与运维条件。任务清单记录“要做什么动作”，DoD 判定“做到什么程度算完成”，两者用途不同，不能互相替代。
DoD 与质量门禁有相近之处：两者都设置检查条件。差异在于质量门禁通常嵌入流程节点，由规则或审批自动触发，偏重阻断与放行；DoD 是团队对完成含义的约定，偏重共同判定与质量共识。实践中可以把 DoD 的部分条件转化为质量门禁中的自动检查，但 DoD 本身仍需要团队在评审中逐项确认。
具体例子与常见误解
以下为演示情景，用于说明判定过程，不代表真实客户实践。假设团队有一个用户故事：“已登录用户可以在订单列表页按时间筛选订单。”该故事的验收标准包括：选择最近 7 天时只显示 7 天内订单；无结果时显示空状态提示；筛选条件在刷新后保留。团队共用的 DoD 包括：代码通过同伴评审；相关自动化测试通过；接口文档已更新；功能可在 Sprint 评审中演示。
开发完成后，团队成员逐项核对：代码已提交并通过一名同伴评审，满足第一条；筛选逻辑的单元测试与回归测试通过，满足第二条；订单查询接口的文档已同步更新，满足第三条；在测试环境可以演示筛选与空状态，满足第四条。同时，三条验收标准也逐条验证通过。此时该用户故事才被标记为完成。如果只满足验收标准而文档未更新，按 DoD 判定仍不算完成；如果代码写完但测试未跑，同样不算完成。这个例子说明 DoD 的作用是把“完成”从单点判断变成多项条件的共同确认。
常见误解之一是把 DoD 当成验收标准。表现是团队只写每个需求的具体条件，没有共用完成口径，结果不同需求的“完成”含义各不相同。修正动作是单独维护一份团队级 DoD，并在每个工作项完成时对照它。
常见误解之二是把 DoD 当成个人承诺。表现是某成员说“我保证做完了”，但无法逐条说明依据。DoD 是团队约定，判定应基于可检查的条件和记录，而不是个人保证。修正动作是在评审中逐项核对，把核对结果记录在工作项或评审记录中。
常见误解之三是把 DoD 写成无法验证的口号，例如“高质量交付”“用户满意”。这类表述无法判定通过与否。修正动作是把每条条件改写为可观察的结果，例如“关键路径自动化测试通过率 100%”“评审中完成功能演示并记录反馈”。
这些误解带来的后果是完成口径不一、返工增加和交付争议：开发认为完成、测试认为未完成，交接时反复确认；或者增量在评审时才暴露文档缺失、测试未覆盖，导致返工。团队可以用三个具体动作修正：第一，把 DoD 写成可逐条核对的清单并放在团队可见位置；第二，在每次完成判定时逐项确认并留下记录；第三，在回顾会议中检查 DoD 是否仍匹配当前成熟度，按需调整并同步全员。这样 DoD 才能持续作为团队对“完成”的统一约定发挥作用。
常见问题
团队刚开始用 DoD，条件写几条比较合适？
起步阶段建议聚焦能稳定执行的条件，例如代码通过同伴评审、相关自动化测试通过、必要文档已更新、功能可演示。条数不是关键，关键是每条都能被团队成员逐条核对。条件过多而无法执行，会让 DoD 在完成判定时被跳过；条件过少又无法覆盖主要质量风险。可以先运行一到两个迭代，再根据实际返工点补充条件。
DoD 和验收标准冲突时以哪个为准？
两者通常不冲突，因为它们回答的问题不同。验收标准针对单个需求的业务条件，DoD 是同类工作项共用的质量门槛。判定完成时需要同时满足：需求自身的验收标准全部通过，团队的 DoD 条件也逐项确认。如果出现看似冲突的情况，多半是某条验收标准被误写成了通用质量要求，或者 DoD 里混入了只适用于个别需求的条件，应当把内容归位到正确的层级。
不同工作项类型可以共用一份 DoD 吗？
可以按类型分别约定。用户故事、缺陷修复、技术任务的完成条件往往不同，例如缺陷修复可能额外要求回归验证与根因记录。团队可以维护一份通用 DoD，再为特定工作项类型补充附加条件。需要避免的是每个需求各写一套完成口径，那样 DoD 就失去了统一判定的作用。
DoD 调整后，之前已标记完成的工作项要重新判定吗？
一般不需要追溯重判。DoD 的调整面向后续工作项，团队在调整时说明生效时间即可。如果新条件涉及已交付增量的明显质量风险，可以在回顾中评估是否需要补充处理，但这属于风险应对，而非把历史工作项全部退回。保持调整记录与生效范围清晰，能减少交接时的口径争议。
把 DoD 条件配置到协作工具里，能替代团队逐项确认吗？
工具可以帮助条件可查、状态可追踪、评审有记录，例如把完成条件写进任务模板、用需求状态与看板跟踪进度、在测试环节依据验收标准执行用例并把未通过用例转为缺陷。逐项确认仍需团队在完成判定和评审中完成，因为部分条件涉及判断，例如文档是否真正同步、演示是否覆盖关键路径。工具承接记录与跟踪，团队承担判定与共识。
