完成定义（Definition of Done，DoD）适合用在交付物需要被多人共同判定“是否真的做完”的研发管理场景，典型包括迭代交付验收、跨角色协作交接、质量门禁与发布前检查、外包或跨团队交付确认。是否值得引入，取决于团队交付节奏是否稳定、能否就检查项达成一致，以及是否愿意为核验投入时间。本文按采用条件、适用场景、投入前提、暂缓条件与试点方法逐项说明，帮助团队判断自身情况。
要点总览（TL;DR）
- 完成定义适合交付物需要多人共同判定“是否真的做完”的场景，典型包括迭代交付验收、跨角色协作交接、质量门禁与发布前检查、外包或跨团队交付确认。
- 值得采用的前提有三条：交付节奏相对稳定、多角色参与判定、检查项可观察；采用后验收判断从个人经验转为团队共同约定。
- 引入需要前期共同写出检查项、在状态流转中设置核对动作与责任人、借助工具承载并定期修订，基础前提是团队已有工作项管理和状态流转。
- 需求方向频繁大幅变动、团队规模很小且标准高度默契、尚无基本工作项管理、或检查流于形式时，宜先暂缓，可用轻量检查清单过渡。
- 是否推广可用一个迭代或一类工作项试点验证，以验收分歧和交接遗漏的实际观察作为判断依据，不做收益量化承诺。
什么情况下值得为团队引入完成定义
当团队反复出现“开发说做完了、测试说没法测、产品说还差一点”的验收分歧时，引入完成定义就有明确价值。这类分歧通常源于交付标准停留在个人经验和口头默契中，每个人对“完成”的理解不同，交接时才发现遗漏。DoD的作用是把这些隐含标准写成团队共同认可的检查项，让验收判断有据可依。
值得采用的前提可以归纳为三条：
- 交付节奏相对稳定。团队按迭代或固定周期交付，工作项有明确的开始与结束节点，检查项才有稳定的适用对象。若交付物形态每次差异很大，统一检查项难以覆盖。
- 多角色参与判定。开发、测试、设计、产品等角色需要共同确认交付物是否可用。参与判定的角色越多，口头默契越容易失效，书面约定的收益越明显。
- 检查项可观察。完成条件能够转化为可核对的事实，例如“代码已合并至主干”“测试用例已执行并通过”“相关文档已更新”。无法观察的条件难以执行，也容易变成形式。
采用后的直接作用是：验收判断从依赖个人经验转为依据共同约定，交接时双方对照同一份检查项，减少“以为对方已经处理”的遗漏。需要说明的是，DoD能改善的是判定依据和交接清晰度，团队效率或质量指标是否提升，取决于执行情况和团队基础，本文不做量化承诺。
完成定义解决的是哪类交付判断问题
研发交付中，“完成”一词常被不同角色赋予不同含义。开发认为功能代码写完即完成，测试认为缺少可测环境和用例说明就不算完成，产品则认为文档和上线说明未补齐。这类理解差异在交接点集中暴露，表现为返工、等待和验收争议。DoD针对的正是这类判断问题：它不规定某个功能做成什么样，而是规定一个工作项被团队认定为完成时必须满足哪些通用条件。
其作用机制有两层。第一，统一检查项：团队共同列出完成前必须核对的条目，例如代码评审通过、单元测试覆盖、测试环境验证、相关文档更新。第二，统一判定时点：明确在哪个状态转换前执行核对，例如工作项从“开发中”进入“待测试”前，或从“待验收”进入“已完成”前。两层结合，使“完成”从主观判断变为可逐项核对的约定。
DoD与单条需求的验收标准需要区分。验收标准针对具体需求，描述这个功能应满足的业务行为，例如某个字段的校验规则或某个页面的交互结果；DoD是团队级通用门槛，适用于所有工作项，描述任何交付物完成前都应满足的条件。两者配合使用：验收标准回答“这个需求做对了没有”，DoD回答“这个工作项可以算完成了吗”。
DoD的价值落在减少返工争议和交接遗漏上，它不替代测试、代码评审或需求评审。测试验证功能正确性，评审把关方案质量，DoD确保这些动作在标记完成前确实被执行。把DoD理解为“完成前的核对清单”，比把它当作质量保障手段更贴近其实际作用。
哪些研发管理场景适合使用完成定义
DoD的适用性体现在具体场景中。以下四类场景对“完成”判定的一致性要求较高，适合引入团队级完成定义。每个场景的检查重点不同，团队可据此调整检查项方向。
| 场景 | 适用条件 | 检查重点方向 |
|---|---|---|
| 迭代交付验收 | 团队按迭代交付，工作项有明确的状态流转 | 代码合并、测试执行、验收标准核对、文档更新是否在进入完成状态前逐项确认 |
| 跨角色协作交接 | 开发、测试、设计之间存在明确的交接节点 | 交接物是否齐全，例如可测环境、用例说明、设计稿标注、接口说明 |
| 质量门禁与发布前检查 | 存在进入下一环节或发布的前置条件 | 缺陷修复情况、回归测试结果、发布说明与回滚方案是否就绪 |
| 外包或跨团队交付 | 交付方与接收方分属不同团队或组织 | 书面约定的交付物清单、验收方式、问题反馈时限是否明确 |
迭代交付验收场景。每个工作项进入完成状态前，团队对照检查项逐条核对。适用条件是迭代节奏稳定、工作项状态定义清晰。检查重点在于确认测试已执行、验收标准已满足、相关文档已同步，避免工作项在“看起来做完”时被提前关闭。
跨角色协作交接场景。开发向测试提测、设计向开发交付标注、产品向研发移交需求说明时，交接双方对“交付物是否齐全”常有分歧。DoD可以把交接物清单写入约定，例如提测前需提供可运行环境、变更说明和自测记录。适用条件是交接节点固定、交接物可列举。
质量门禁与发布前检查场景。当团队需要判断某批工作项是否可以进入发布环节时，DoD可作为前置核对依据，检查缺陷修复、回归结果和发布材料是否齐备。适用条件是发布流程有明确的准入要求，检查项与发布风险对应。
外包或跨团队交付场景。交付方与接收方缺少日常默契，验收分歧更容易发生。用书面完成定义明确交付物范围、验收方式和反馈时限，可以减少来回扯皮。适用条件是双方愿意在合作开始前就交付标准达成书面一致。
引入完成定义需要投入什么
DoD的成本主要在前期的共同讨论和后续的持续维护，工具承载则决定执行是否便利。团队在决定引入前，可以按以下投入项评估自身能否承担。
- 前期投入：共同写出检查项。由团队集体讨论，列出完成前必须核对的条目，形成书面约定。讨论过程本身也是对齐理解的过程，检查项数量宜精简，聚焦真正影响交接和验收的条件。
- 流程投入：设置核对动作与责任人。明确在哪个状态转换前执行核对、由谁负责确认、发现未满足项时如何处理。核对动作嵌入现有流程，避免额外增加会议。
- 工具承载：把检查项落到工作项状态或检查清单中。检查项需要便于执行和留痕，否则容易停留在文档里无人对照。ONES Project 支持自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；团队可以借助状态流转和任务拆分，把完成前的核对动作对应到具体工作项上。ONES 敏捷研发管理解决方案将需求提出方、产品经理、研发、测试等角色连接在同一流程中，交接双方查看同一工作项的状态与记录，减少信息不对称。工具能承载流程，检查项的具体内容仍需团队自行约定。
- 维护投入：定期修订检查项。交付形态变化后，原有检查项可能失效或冗余。团队宜在迭代回顾等固定节点检视检查项是否仍适用，及时增删。
引入DoD还有一个基础前提：团队已有基本的工作项管理和状态流转。如果工作项本身记录不全、状态定义混乱，检查项无处附着，执行也无从谈起。此时应先理顺工作项与状态，再考虑引入完成定义。
哪些情况下应先暂缓使用完成定义
DoD并非所有团队都需要的必选项。以下情况引入完成定义，收益有限甚至可能增加负担，宜先暂缓。
- 需求方向频繁大幅变动、交付物形态尚不稳定。此时统一检查项难以覆盖实际交付内容，写出的约定很快过时，维护成本高于收益。团队可先稳定交付形态，再提炼通用条件。
- 团队规模很小且交付标准高度默契。成员之间长期协作、交接频繁且分歧少时，书面约定的边际收益有限。此时口头对齐加简单清单即可满足需要。
- 尚无基本工作项管理、状态流转混乱。检查项需要附着在工作项和状态上，流程基础缺失时，先理顺工作项记录和状态定义，比引入DoD更紧迫。
- 存在把DoD当成形式化打勾的倾向。如果检查项无人维护、核对流于形式，DoD会变成额外负担，还可能给人“已核对”的错觉。出现这种迹象时，应暂停执行并重新讨论检查项是否有效。
暂缓不等于放弃。团队可以先用轻量检查清单过渡：针对当前最常出问题的交接环节，列三五条核对项，在交接时口头或书面确认。待交付节奏稳定、分歧点清晰后，再把清单升级为团队级完成定义。
如何用小范围试点判断是否值得推广
是否推广DoD，可以用一个迭代或一类工作项的试点来验证，以实际观察代替主观判断。试点步骤建议如下：
- 确定试点范围。选择一个迭代，或一类交接问题较多的工作项，例如提测环节或发布前检查。范围宜小，便于观察和调整。
- 记录试点前的对照情况。在试点开始前，简单记录当前验收争议、返工和交接遗漏的典型情形，作为后续对比的参照。记录以事实描述为主，不必建立复杂指标。
- 试点中观察执行情况。重点看两件事：检查项是否被真实执行，还是被跳过或补勾；交接和验收时是否仍有明显遗漏。执行情况比检查项写得多漂亮更重要。
- 试点后由团队评审。在迭代回顾或专门讨论中，由参与成员评估检查项是否有效、哪些条目多余、哪些遗漏需要补充，并决定保留、修订还是停止。
判断标准以可观察的交接与验收情况为主：验收分歧是否减少、交接时是否少出现“以为对方已处理”的遗漏、检查项是否被持续执行。这些观察足以支撑团队决定是否扩大使用范围。DoD是否带来效率或质量指标的改善，受团队基础和执行质量影响，试点阶段不宜以此作为唯一判断依据，也不做量化承诺。
常见问题
完成定义和单条需求的验收标准有什么区别，两者需要同时用吗？
两者回答的问题不同。验收标准针对具体需求，描述这个功能应满足的业务行为，例如字段校验规则或页面交互结果；完成定义是团队级通用门槛，适用于所有工作项，描述任何交付物完成前都应满足的条件，例如代码评审通过、测试已执行、文档已更新。
两者配合使用更有效：验收标准回答“这个需求做对了没有”，完成定义回答“这个工作项可以算完成了吗”。只有验收标准时，团队容易在测试、文档等通用环节遗漏；只有完成定义时，具体需求的业务正确性缺少判定依据。
团队刚开始用完成定义，检查项写多少条比较合适？
没有统一数量要求，判断依据是检查项能否被真实执行。起步阶段宜精简，聚焦当前最常出问题的交接和验收环节，例如提测前的环境与自测记录、完成前的测试执行与文档同步。条目过多会增加核对负担，反而容易催生补勾和跳过。
试点一个迭代后，团队可以检视哪些条目真正拦住了遗漏、哪些从未发挥作用，据此增删。检查项随交付形态变化定期修订，比一次性写全更重要。
完成定义需要强制卡住状态流转吗，还是靠团队自觉核对？
两种方式各有适用条件。强制校验适合遗漏代价较高的环节，例如发布前检查或对外交付确认，未满足条件时不允许进入下一状态；靠自觉核对适合团队成熟度较高、检查项仍在磨合的阶段，避免流程过重影响正常流转。
无论哪种方式，都需要明确由谁在哪个状态转换前执行核对、发现未满足项时如何处理。缺少责任人的检查项容易停留在文档里无人对照。
外包或跨团队交付时，完成定义应该由哪一方来写？
宜由交付方与接收方共同商定，并在合作开始前形成书面一致。交付方单方面写出的标准，接收方未必认可；接收方单方面提出要求，交付方可能认为超出范围。共同商定的内容通常包括交付物清单、验收方式、问题反馈时限和返修责任。
这类场景中，完成定义的作用是减少验收分歧，条款应尽量可核对，例如交付物以什么形式提交、由谁在多久内确认。约定形成后，双方按同一份标准执行验收。
试点结束后，团队判断保留还是停止完成定义，主要看什么？
以可观察的交接与验收情况为主：验收分歧是否减少、交接时是否还出现“以为对方已处理”的遗漏、检查项是否被持续真实执行。这些现象在试点前后可以直接对比，足以支撑团队决定保留、修订还是停止。
如果检查项普遍被跳过或事后补勾，说明当前约定与团队实际交付不匹配，应先修订条目或暂停执行，重新讨论哪些条件真正影响交接和验收。效率或质量指标的变化受多种因素影响，试点阶段不宜作为唯一判断依据。
