Definition of Done（DoD）是一组团队共同约定的完成标准，用来判断一项工作是否真正做完。它最适合交付物需要跨角色交接、质量口径容易扯皮、验收反复返工的研发场景，例如迭代交付、需求上线、缺陷修复、跨团队集成与发布。DoD 的价值在于把“完成”从个人判断变成可检查的团队约定；代价是前期需要共同定义标准并持续维护。团队规模小、交付物单一、质量口径已稳定时，可以先从一份轻量清单起步，不必一次铺开全套标准。
要点总览（TL;DR）
- DoD 适合完成口径需要跨角色统一、交接和验收容易反复返工的研发场景，典型如迭代交付、需求上线、缺陷修复、跨团队集成与发布。
- 采用前提是交付物经过两个以上角色或环节、团队已有基本交付节奏、愿意共同定义并持续维护标准；三个条件同时成立时投入产出比较清晰。
- 交付物单一、口径已稳定、协作节奏尚未形成，或标准过重、被当作考核工具时，应轻量起步、缩小范围或暂缓推广。
- 试点可先选一个迭代或一类交付物，观察交接确认、验收退回和完成状态争议的变化，再决定推广或放弃。
先给结论：DoD 在什么条件下值得采用
DoD 值得采用的核心条件，是团队对“做完”存在多种理解，并且这种分歧已经影响到交接或验收。比如开发认为代码提交即完成，测试认为用例通过才算完成，产品经理认为上线可用才算完成。三种理解并存时，工作项状态会失真，交接环节反复确认，验收阶段频繁返工。此时引入一份共同约定的完成标准，能够直接减少沟通成本和状态误判。
判断是否值得投入，可以看三个前提是否同时成立：一是交付物需要经过两个以上角色或环节，完成口径需要对齐；二是团队已有基本的迭代或交付节奏，工作项能够被拆到可检查的粒度；三是团队愿意在迭代开始前共同讨论标准，并在回顾中调整。三个条件都具备时，DoD 的投入产出比较清晰。
以下情形可以先轻量起步或暂缓：交付物高度单一、由同一角色从头做到尾，完成口径本身没有争议；团队尚未形成稳定的协作节奏，工作项粒度粗到无法逐条检查；或者团队刚引入新的研发流程，同时叠加多套标准容易造成负担。这些情况下，先用一份三到五条的简版清单，比设计完整标准体系更实际。
DoD 解决的管理问题与作用机制
DoD 的作用机制，是把“完成”的判断权从个人经验转移到团队约定。没有共同标准时，每个角色依据自己的职责边界判断工作是否结束，状态更新带有主观性。有了 DoD，工作项进入“完成”状态前需要逐条对照约定条件，判断依据变得可检查、可讨论。这种转变带来的直接效果是状态可信度提升，下游角色可以据此安排测试、集成或发布。
在交接点上，DoD 减少的是反复确认和隐性返工。开发把工作项交给测试时，如果双方对“可测试”的条件有共识，测试就不必反复询问环境是否就绪、代码是否合并、自测是否完成。争议从“你说完成了但我觉得没有”变成“这条标准是否满足”，讨论对象具体，解决路径清晰。
需要区分 DoD 与验收标准、测试用例的关系。验收标准针对单个需求，描述这个需求要满足什么业务条件才算做对；DoD 是团队对所有工作项通用的完成约定，描述任何工作项交付前要经过哪些检查。测试用例则是验证手段，用来证明需求和 DoD 条件是否满足。三者可以叠加使用：验收标准回答“做对什么”，DoD 回答“做到什么程度算完成”，测试用例回答“如何证明”。
适合采用 DoD 的研发管理场景
DoD 的适用面可以从交付交接的复杂度和质量口径的分歧程度来判断。以下场景中，完成标准不统一带来的成本比较明显，适合优先引入。
| 研发管理场景 | 适用程度 | DoD 关注点 |
|---|---|---|
| 迭代交付与版本发布 | 高 | 迭代内工作项进入完成状态前，代码合并、自测、文档、评审等条件是否满足 |
| 需求从开发到上线的跨角色交接 | 高 | 提测条件、环境就绪、上线检查项是否对齐 |
| 缺陷修复与质量门禁 | 高 | 修复验证、回归范围、缺陷关闭条件是否明确 |
| 跨团队集成与联调 | 中高 | 接口约定、联调环境、集成验证的责任边界 |
| 外包或多人协作的交付确认 | 中高 | 交付物清单、验收材料、责任归属的可检查约定 |
迭代交付与版本发布是最典型的场景。团队在迭代计划时对需求与验收标准达成一致后，设计、研发、测试人员将需求拆分为子任务推进；DoD 在这里补充的是“子任务完成”与“需求完成”之间的检查条件，避免子任务全部关闭但需求仍不具备交付条件。版本发布前，DoD 可以把发布检查项固定下来，减少每次发布前临时确认的重复劳动。
需求从开发到上线的跨角色交接，适合用 DoD 明确提测门槛。开发提交测试前需要满足哪些条件、测试通过后上线前需要哪些确认，这些内容写成团队约定后，交接双方有共同参照。缺陷修复场景同理：缺陷关闭前是否完成回归验证、影响范围是否确认，属于典型的完成口径问题，适合纳入 DoD。
跨团队集成与联调中，DoD 的作用集中在接口和环境的责任划分。两个团队各自的工作项都标记完成，集成时却发现接口字段或环境配置不一致，这类问题可以通过联调完成标准提前暴露。外包或多人协作的交付确认，则适合用 DoD 把交付材料、验收步骤写成可检查的清单，减少口头确认带来的遗漏。
这些场景在工具中的承载方式，通常是把完成标准与工作项状态、检查项关联起来。ONES 敏捷研发管理解决方案打通需求、研发、测试全流程，将需求提出方、产品经理、研发、测试等角色连接起来；ONES Project 支持自定义需求状态与多种属性，适配需求管理、任务管理、缺陷管理、迭代管理等场景。团队可以把共同约定的完成条件写入工作项属性或检查项，让状态流转与标准对照发生在同一处，减少标准写在文档里、执行靠记忆的脱节。
采用 DoD 需要的投入与前提
DoD 的落地成本主要不在编写清单，而在达成共识和持续维护。团队需要投入时间共同讨论标准，确保每个角色理解并认可这些条件。由管理者单方面下发一份清单，执行时容易流于形式，因为团队成员没有参与定义，遇到边界情况时缺乏判断依据。
标准本身需要可检查、可验证。类似“代码质量良好”“文档完整”这样的表述无法执行，需要转化为具体条件，例如“代码已合并至主干”“接口文档已更新”“自测用例已执行并通过”。条件越具体，对照成本越低，争议空间越小。同时，标准数量需要控制，一份覆盖所有情况的超长清单会增加每个工作项的关闭成本，反而促使团队绕过检查。
DoD 还需要与现有流程和工具中的状态衔接。如果团队使用看板管理任务状态，完成标准应当对应到状态流转的触发条件；如果使用需求状态自定义，可以把关键检查项作为状态变更的前置确认。ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并支持组件化设计，团队可以根据自身流程定义项目类型与相关组件，把完成标准嵌入已有的状态和评审环节，而不必另建一套流程。
最后需要建立回顾与更新机制。DoD 不是一次制定后长期不变的文档，团队应在迭代回顾中检查标准的适用性：哪些条件经常被跳过、哪些条件已经不再必要、哪些新问题需要补充。更新机制的存在，让 DoD 保持与团队实际交付方式同步。
哪些情况下应暂缓或缩小范围
交付物单一、完成口径已经稳定的团队，不必在 DoD 上重投入。如果团队长期由同一角色完成同类工作，完成标准已经形成默契，额外引入正式清单带来的收益有限，可以先保留一份简版检查项，等交付复杂度上升后再扩展。
团队尚未形成基本协作节奏时，暂缓引入完整 DoD 更稳妥。迭代周期不稳定、工作项粒度粗、角色分工不清晰的情况下，团队连“一项工作何时开始、何时交接”都未形成共识，此时制定完成标准缺乏可依附的流程节点。先建立基本的任务拆分和状态管理，再讨论完成标准，顺序更合理。
标准过重是常见的失败原因。把 DoD 写成几十条检查项，每个工作项关闭前都要逐条确认，团队会逐渐用形式化勾选代替真实检查。控制标准数量、区分不同工作类型的适用条件，比追求覆盖全面更重要。例如缺陷修复和需求开发的完成条件可以不同，不必用同一份清单约束所有工作项。
把 DoD 当成考核工具，会扭曲它的作用。如果完成标准的满足情况被直接用于个人绩效评价，团队倾向于选择容易满足的标准、回避有难度的条件，标准本身失去改进质量的意义。DoD 适合作为团队协作约定和交付检查依据，评价用途需要谨慎对待。
如何用小范围试点判断是否值得推广
试点是判断 DoD 是否适合本团队的低成本方式。选择一个迭代或一类交付物作为试点范围，例如先在一个迭代的需求交付上应用完成标准，或在缺陷修复流程中试行关闭条件。试点范围小，调整成本低，也便于观察标准与实际工作的匹配程度。
试点期间重点观察几类信号：交接环节的反复确认是否减少，验收阶段因“未真正完成”而退回的情况是否变化，跨角色对完成状态的争议是否更容易收敛，工作项关闭后是否仍频繁出现补充工作。这些信号比笼统的满意度评价更能说明 DoD 是否在起作用。同时记录标准执行中的卡点，比如某些条件难以验证、某些工作类型不适用，作为调整依据。
试点结束后做推广或放弃判断。如果交接争议和验收返工有明显改善，标准执行没有造成明显负担，可以逐步扩大适用范围，并按工作类型细化条件；如果标准频繁被跳过、团队认为检查成本高于收益，或者问题主要来自需求不清而非完成口径，则应缩小范围或暂停推广，先解决更上游的问题。试点结论以观察到的具体现象为依据，不预设量化收益。
在试点过程中，工具的作用是让标准对照有固定位置。团队可以在 ONES 中把试点范围的完成条件与工作项状态、检查项关联，观察状态流转与标准执行是否一致；测试工程师根据迭代需求与验收标准编写用例、执行测试，未通过用例可转换为缺陷并指派修复，这些环节产生的记录可以作为试点判断的依据。工具承载不替代团队共识，但能让试点过程可追溯、可回顾。
常见问题
DoD 和验收标准、测试用例应该怎么配合使用？
三者回答的问题不同：验收标准针对单个需求，说明这个需求要满足什么业务条件才算做对；DoD 是团队对所有工作项通用的完成约定，说明交付前要经过哪些检查；测试用例是验证手段，用来证明需求和 DoD 条件是否满足。
实际使用时可以叠加：需求层面写清验收标准，团队层面维护一份通用 DoD，测试环节用用例覆盖两者。需要注意的是，DoD 不宜写得和某个具体需求一样细，否则会失去通用性；验收标准也不宜承担团队通用检查的职责。
团队规模很小，还需要引入 DoD 吗？
规模本身不是决定因素，关键看完成口径是否存在分歧、交付是否需要跨角色交接。小团队如果长期由同一角色完成同类工作、完成标准已形成默契，可以先保留一份三到五条的简版检查项，不必设计完整标准体系。
当小团队开始出现开发、测试、产品多角色交接，或者交付物类型变多、验收反复退回时，再逐步扩展清单内容。轻量起步、按需扩展，比一开始就追求覆盖全面更实际。
DoD 制定后长期不更新会有什么问题？
团队交付方式会变化，标准如果长期不动，容易出现两类问题：一是部分条件已经不再适用，团队习惯性跳过，检查流于形式；二是新出现的质量问题没有纳入标准，DoD 逐渐与实际交付脱节。
建议在迭代回顾中留出固定时间检查标准的适用性：哪些条件经常被跳过、哪些已经不再必要、哪些新问题需要补充。更新机制不必复杂，关键是让 DoD 跟随团队实际交付方式同步调整。
不同工作类型可以共用同一份 DoD 吗？
可以共用一份基础约定，但建议按工作类型区分附加条件。需求开发、缺陷修复、跨团队联调的完成条件差异明显：缺陷修复更关注回归验证和影响范围确认，需求开发更关注提测条件和上线检查，联调更关注接口与环境的一致性。
做法上可以保留一份所有工作项都适用的基础清单，再为特定类型补充少量条件。这样既保持团队口径统一，也避免用一份超长清单约束所有工作项、增加关闭成本。
试点期间应该记录哪些信息，才能判断是否值得推广？
重点记录与完成口径直接相关的现象：交接环节的反复确认次数、验收阶段因未真正完成而退回的情况、跨角色对完成状态的争议是否更容易收敛、工作项关闭后是否仍频繁出现补充工作。
同时记录标准执行中的卡点，例如某些条件难以验证、某些工作类型不适用。试点结束后以这些具体现象为依据判断推广、调整或暂停，不预设量化收益；如果问题主要来自需求不清而非完成口径，应先解决上游问题。
