Definition of Done（DoD）落地的关键，是把“完成”从个人判断变成团队共同约定：按交付物类型分层定义，把每条标准写成可观察、可核验的条目，明确由谁在哪个环节检查、留下什么证据，再嵌入需求流转与评审动作，随迭代回顾持续修订。本文围绕分层结构、条目编写、落地步骤、角色分工、检查示例与完成验收展开，帮助研发团队建立一套能真正运行的DoD。
要点总览（TL;DR）
- DoD落地先分层：团队级定所有工作项的完成底线，需求、缺陷、技术任务按类型补充条目级标准，层数随团队规模与发布节奏调整。
- 每条标准写清检查对象、判断条件和证据形式，团队级控制在5至8条，条目级按类型各3至6条，必选与按需条目分开标注。
- 把DoD挂到工作项进入“待验收”或“已完成”前的状态节点，未通过检查不能流转，检查结论与证据记录在工作项中。
- 产品负责人、开发、测试、团队负责人分别承担定义、执行、核查与维护职责，跨团队共享条目由接口人共同确认口径。
- 用检查记录是否完整、条目是否随回顾修订、同类问题是否反复返工来判断落地效果，连续两个迭代出现同类遗漏即触发修订。
先定DoD的分层结构：从迭代完成到发布完成
DoD不适合写成一张覆盖所有情况的长清单。团队规模扩大、交付物类型增多后，一张清单要么过于笼统而无法判断，要么过于细碎而没人愿意逐条核对。更可行的做法是分层：团队级DoD规定所有交付物都必须满足的底线，条目级DoD针对具体需求、缺陷或技术任务补充专项标准。两层各管一段，检查时先过团队级，再过条目级。
分层数量取决于团队规模和发布节奏。单一小组、发布频率稳定的团队，两层结构通常够用；多个小组共享同一产品、发布窗口不一致时，可以在团队级之上增加产品级或发布级DoD，用于约束跨团队的集成与发布条件。层数增加意味着维护成本上升，团队应先跑通两层，再根据实际检查中反复出现的遗漏决定是否加层。
| 层级 | 适用范围 | 示例条目 | 维护责任人 |
|---|---|---|---|
| 团队级DoD | 团队所有进入“完成”状态的工作项 | 代码已合并至主干并通过持续集成；关键路径有自动化测试覆盖；变更说明已更新 | 团队负责人牵头，团队共同确认 |
| 需求级DoD | 用户故事、业务需求 | 验收标准逐条验证通过；产品负责人已确认交互与文案；相关文档已同步 | 产品负责人起草，团队评审 |
| 缺陷级DoD | 缺陷修复类工作项 | 根因已记录；回归用例已执行；受影响版本已确认 | 测试负责人与开发共同确认 |
| 技术任务级DoD | 重构、基础设施、技术债类任务 | 性能或稳定性指标达到约定阈值；回滚方案已验证；监控告警已配置 | 技术负责人 |
按交付物类型区分标准，是为了让检查对准该类工作真正的风险点：需求怕验收偏差，缺陷怕复发，技术任务怕影响面失控。分层结构确定后，团队应把每层的适用范围写清楚，避免同一工作项被两套标准重复约束。迭代节奏、需求池优先级排序等属于相邻管理动作，本文不展开，DoD只回答“什么算完成”。
把每条标准写成可核验的条目
一条合格的DoD条目，应让人在不询问作者的情况下判断通过与否。编写时包含三个要素：检查对象（检查什么）、判断条件（达到什么状态算通过）、证据形式（在哪里看到依据）。缺少证据形式的条目，往往在评审时退化为口头确认。
常见模糊表述可以通过补充对象和条件改写。“代码质量良好”改为“新增代码通过静态检查，无阻断级告警，检查报告附在任务中”；“测试充分”改为“验收标准对应的测试用例全部执行，未通过项已转为缺陷并关联本需求”；“文档已更新”改为“接口变更已更新至接口文档，文档版本号与本次发布一致”。改写后的条目更长，但检查时不需要再解释。
条目数量需要取舍。团队级DoD建议控制在5至8条，覆盖代码、测试、文档、发布四类底线；条目级DoD按交付物类型各写3至6条，聚焦该类工作最容易出问题的环节。条目过多会让检查变成填表，条目过少则漏掉关键风险。颗粒度以“一次检查能在几分钟内判断”为宜，需要长时间验证的条件应拆成独立检查动作并指定执行时点。
必选条目与按需条目要分开标注。必选条目对所有同类工作项生效，未满足即不能标记完成；按需条目写明触发条件，例如“涉及数据库变更时，需提供回滚脚本并验证”“涉及对外接口时，需完成兼容性说明”。按需条目附带触发条件，可以避免清单无限膨胀，也防止团队以“这次不适用”为由整体跳过。
落地步骤：从起草到嵌入研发流程
DoD落地是一个分阶段推进的过程，每个阶段都应有明确的输入、动作、输出和完成标志。以下步骤按顺序执行，团队可根据规模压缩周期，但不建议跳过试运行直接全面推行。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 起草 | 近期交付中反复出现的返工问题、现有评审记录 | 产品、开发、测试共同列出“完成时经常被遗漏的事项”，归并为团队级与条目级条目 | DoD初稿，含必选与按需标注 | 团队会议逐条确认，无成员对条目含义有分歧 |
| 试运行 | DoD初稿、一个迭代或两周的交付范围 | 选取1至2类工作项试点，在完成检查时逐条核对并记录判断结果 | 试运行检查记录、争议条目清单 | 试点范围内每个完成项都有检查记录 |
| 嵌入流程 | 试运行修订后的DoD | 把DoD挂到工作项从“开发中”进入“待验收”或“已完成”的状态节点，作为流转前的检查动作 | 状态流转规则与检查责任人 | 未通过检查的工作项无法进入完成状态 |
| 评审与交付前检查 | 待交付工作项、DoD清单 | 由指定角色逐条核对，记录证据位置与结论 | 检查结论与证据链接 | 所有必选条目有明确通过记录 |
| 回顾修订 | 检查记录、遗漏与争议 | 在迭代回顾中讨论条目是否仍适用，增删或改写条目 | 新版DoD与变更说明 | 修订结果已同步至团队并生效 |
嵌入状态节点是落地成败的关键动作。DoD如果只存在于文档中，检查就会依赖个人自觉；把它变成工作项流转的前置条件，团队在每次交付前都必须面对同一份清单。检查动作应尽量靠近完成时点，避免在迭代末期集中补记录。试运行阶段若发现某条目长期无法判断或反复引发争议，应回退到起草环节改写，而不是在检查时临时放宽。
在工具承载上，ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人，团队可以把DoD检查设置为状态流转前的约定动作，把检查结论记录在工作项中。测试环节，测试工程师可依据验收标准编写并执行测试用例，未通过用例可转为缺陷提交至项目并指派修复，这些记录本身就成为DoD检查的证据来源。ONES 敏捷研发管理解决方案打通需求、研发、测试流程，让检查记录与工作项状态保持在同一处，减少交付前核对信息的来回查找。
角色分工与各环节交付物
DoD无人负责时，最常见的结局是清单被跳过或长期不更新。定义、执行、核查、维护四类职责需要落到具体角色，并在每个检查环节留下可追溯的交付物。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品负责人 | 起草需求级DoD，确认验收标准与业务侧完成条件 | 需求级DoD条目、验收标准、验收确认记录 |
| 开发人员 | 执行团队级与技术任务级条目，提供代码、测试与文档证据 | 合并记录、静态检查报告、接口文档更新、回滚方案 |
| 测试人员 | 核查测试相关条目，确认缺陷状态与回归结果 | 测试用例执行记录、缺陷关联清单、回归结论 |
| Scrum Master/团队负责人 | 组织DoD起草与修订，监督检查动作执行，处理争议条目 | DoD版本记录、检查执行情况、修订决议 |
| 跨团队接口人 | 对齐共享条目的口径，确认依赖方的完成条件 | 跨团队对齐纪要、共享条目清单 |
DoD的维护与变更由团队共同决策，团队负责人负责组织讨论并记录决议，产品负责人对需求级条目的业务含义把关。变更不宜由单人随意修改，否则检查口径会随个人偏好漂移。跨团队协作时，共享条目应由各方接口人共同确认，明确以哪一方的检查记录为准，避免同一交付物在两套标准下得出不同结论。
示例：一个需求条目的DoD检查过程
以下为演示情景，用于说明检查动作如何展开，不代表真实项目数据。某研发团队接到一个需求：为订单列表增加按时间范围筛选的功能。该需求进入“待验收”前，团队按需求级DoD逐条核对。
第一条，验收标准逐条验证。检查人对照需求中列出的三条验收标准操作页面，确认筛选结果与边界时间处理符合预期，判断依据是操作录屏与测试用例执行记录。第二条，测试用例全部执行且未通过项已关联缺陷。测试人员提供执行记录，其中一条边界用例曾失败，已转为缺陷并修复，缺陷与本需求关联，判断通过。第三条，交互与文案经产品负责人确认。产品负责人在工作项中留下确认意见，判断通过。第四条，涉及接口变更需更新接口文档。开发人员提供文档版本号，与本次发布一致，判断通过。第五条为按需条目：涉及数据库查询变更，需提供性能验证结果。开发人员提供了查询耗时对比数据，判断通过。
假设其中“性能验证结果”未提供，该需求不能标记完成，处理方式是退回开发补充验证，工作项状态回退，缺陷或补充任务单独建项跟踪。所有检查结论、证据位置和判断人均记录在工作项中，形成可追溯的检查记录。这个示例说明，DoD检查的价值在于每条结论都有依据，争议发生时可以回到记录本身，而不是重新争论“算不算完成”。
完成检查：判断DoD是否真正落地
判断DoD是否落地，不看清单写得多完整，而看团队在交付前是否真的用同一份清单达成一致。以下清单可逐项核对，每项都应能找到证据来源和负责人。
| 检查项 | 通过标准 | 证据来源 | 负责人 |
|---|---|---|---|
| 分层结构已确定 | 团队级与条目级DoD均有明确适用范围 | DoD文档与版本记录 | 团队负责人 |
| 条目可核验 | 每条含检查对象、判断条件、证据形式 | DoD条目评审记录 | 产品负责人与团队 |
| 检查已嵌入流转 | 完成状态前存在检查动作，未通过无法流转 | 工作项状态记录 | 团队负责人 |
| 检查记录完整 | 近期完成项均有逐条结论与证据 | 工作项检查记录 | 各检查角色 |
| 条目持续修订 | 近几个迭代内有基于回顾的修订 | DoD变更记录 | 团队负责人 |
常见失效信号包括：检查记录集中在迭代末期补填；条目连续多个迭代未变；评审时频繁出现“这条先跳过”；同一类问题在交付后反复返工。出现这些信号，说明DoD要么与实际风险脱节，要么检查动作没有真正执行。修订触发条件可以设为：连续两个迭代出现同类遗漏、条目在检查中反复引发争议、交付物类型或发布节奏发生变化。修订节奏建议跟随迭代回顾，每次只调整少量条目，保持清单稳定可执行。
DoD落地是一个持续校准的过程。团队把分层结构、可核验条目、状态节点检查和责任分工连成一条闭环，再用检查记录和回顾修订不断校正，完成标准才会从文档变成团队共同的交付习惯。
常见问题
团队刚开始推行DoD，应该先写团队级还是先写需求级条目？
建议先写团队级DoD。团队级条目覆盖代码、测试、文档、发布四类底线，是所有工作项共用的基础，先把它跑通能让团队建立逐条核对的习惯。需求级、缺陷级和技术任务级条目可以在试运行阶段按实际交付类型逐步补充。如果团队当前返工主要集中在需求验收偏差上，也可以同步起草需求级条目，但团队级底线不宜长期缺位。
DoD条目和验收标准有什么区别，需要分开维护吗？
两者回答的问题不同。验收标准针对单个需求，说明这个需求要满足什么业务条件才算做对；DoD条目针对一类工作项，说明这类工作项完成时必须具备哪些通用条件，例如代码已合并、测试已执行、文档已更新。实践中可以分开维护：验收标准随需求编写，DoD条目由团队统一维护并在检查时逐条核对。需求级DoD中“验收标准逐条验证通过”这一条，就是把两者衔接起来的检查动作。
检查发现某条DoD长期无法判断通过与否，应该怎么处理？
这类条目通常缺少可观察的判断条件或证据形式。处理方式是回到条目编写环节改写，补充检查对象、判断条件和证据位置，而不是在检查时临时放宽标准。如果改写后仍难以判断，说明该条目可能不适合作为DoD，可以转为按需条目并写明触发条件，或从清单中移除。修订应在迭代回顾中讨论并记录决议，避免单人随意改动导致检查口径漂移。
跨团队协作时，共享的DoD条目以哪一方的检查记录为准？
共享条目应由各方接口人共同确认口径，并明确以哪一方的检查记录作为流转依据。常见做法是约定一个主责团队负责最终检查记录，依赖方提供各自环节的证据并关联到同一工作项。如果两套标准对同一交付物得出不同结论，应回到接口人对齐会议重新确认条目含义，而不是在交付时各自解释。对齐结果记入共享条目清单，后续检查按同一口径执行。
DoD检查记录需要保留多久，是否每个工作项都要逐条记录？
建议至少覆盖当前迭代和最近几个迭代，便于回顾时分析遗漏和争议。是否每个工作项都逐条记录，取决于团队对可追溯性的要求：对外交付或合规要求高的团队应逐条记录结论与证据位置；内部迭代可以按条目组记录，但必选条目的通过结论仍应可查。记录的目的是在争议发生时能回到依据本身，记录粒度过粗会让检查退化为口头确认。
