团队对“完成”的理解不一致，往往在交付后才暴露：开发认为代码提交即完成，测试认为验证通过才算完成，产品负责人则期待文档和上线准备一并就绪。DoD（完成定义）用来统一这个判断口径。本文给出DoD条目的写法、从零制定的五步流程、角色分工、持续校准机制和落地检查清单，帮助团队把返工问题转化为可核验的交付标准。
要点总览（TL;DR）
- DoD是团队对所有工作项通用的完成门槛，验收标准针对单个需求；条目按“动作+可观察结果+核验方式”写，避免“质量达标”这类无法判断的表述。
- 制定从盘点近几个迭代的返工与争议入手，把高频问题转成候选条目，经团队工作坊逐条确认后公示，先在下一个迭代试运行再固化。
- 校准靠固定节奏与触发条件：每个迭代回顾会留出时间审视，同类缺陷重复、返工集中、工具或合规变化时发起临时校准，增删条目都记录原因与责任人。
- 产品负责人守边界、开发测试给核验手段、Scrum Master或facilitator组织并留痕、团队整体确认、管理层提供时间与工具条件。
- 用条目可核验性、执行一致性、争议下降、返工归因、校准留痕和成本匹配六项检查判断DoD是否真正生效。
先定口径：DoD要写清哪些内容
DoD是一份团队共同认可、可逐项核验的交付标准清单，适用于团队所有工作项；验收标准针对单个需求，描述该需求特有的业务行为。两者边界清晰：验收标准回答“这个需求做对了什么”，DoD回答“任何工作项要标记完成，必须满足哪些通用条件”。把需求细节塞进DoD，会让通用门槛变成逐条定制的清单，反而难以执行。
条目写法建议采用“动作+可观察结果+核验方式”的结构。可观察结果指交付前能直接看到的状态，核验方式是判断通过与否的具体手段。例如“代码已合并主干并通过流水线静态检查”，动作是合并，可观察结果是主干上的提交记录与流水线报告，核验方式是查看流水线状态。反例是“质量达标”“沟通充分”这类口号式条目，不同人理解不同，交付前无法给出通过或不通过的判断。
DoD适合分层设计，避免一份清单覆盖所有情况：
| 层级 | 适用范围 | 条目示例 |
|---|---|---|
| 团队级通用DoD | 所有工作项 | 代码已合并主干并通过流水线静态检查；相关文档已更新到团队文档库 |
| 工作项类型级DoD | 需求、缺陷、技术任务分别补充 | 缺陷：已补充回归用例并在缺陷记录中关联；技术任务：已更新架构说明或接口文档 |
| 迭代级补充条件 | 当前迭代的特殊要求 | 本迭代涉及对外接口变更，需完成联调验证并留存联调记录 |
分层的作用是控制检查成本：通用条目每次都要过，类型级条目只在对应工作项上执行，迭代级条件随迭代结束自然失效，不会长期堆积成负担。
制定DoD的操作步骤
制定DoD的起点是团队真实的返工与争议，而非行业模板。以下五步给出每步的输入、做法与输出，完成标志是团队在下一个迭代能按同一口径判断完成。
第一步：盘点返工与争议点。输入是近几个迭代的缺陷记录、评审意见和返工工时。做法是按问题类型归类，统计哪些环节反复出问题，例如接口联调失败、文档缺失、测试环境未验证。输出是一份问题清单，标注出现频次和影响范围。
第二步：把高频问题转成候选条目。做法是对每个高频问题追问“交付前做什么检查可以拦住它”，按“动作+可观察结果+核验方式”写成候选条目，并标注核验责任人和所需工具。输出是候选条目表，每条附上来源问题，便于工作坊讨论时有据可依。
第三步：团队工作坊逐条确认。做法是团队共同过一遍候选条目，逐条判断本迭代能否执行：能执行的保留，需要新工具或额外时间投入的标记为暂缓并写明前提条件。输出是达成共识的条目清单，以及暂缓条目及其启用条件。
第四步：写入团队工作约定并公示。做法是把确认后的条目整理成正式版本，明确生效时间和适用范围，放在团队都能看到的位置，作为迭代执行的唯一口径。输出是一份带版本号的DoD文档。
第五步：在下一个迭代试运行并收集阻力。做法是在迭代执行中记录每条目的实际检查耗时、被跳过的情况和争议点，在回顾会上汇总。输出是试运行反馈记录，作为首次校准的输入。试运行一个迭代再固化，比一次性定稿更贴近团队实际能力。
角色分工与各自交付物
DoD停留在文档里，通常是因为没有人对起草、执行和维护负责。下表按角色列出职责与可交付物，团队规模较小时一人可兼多角，但职责本身需要明确。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品负责人 | 确认DoD与验收标准的边界，防止把需求细节塞进通用门槛 | 验收标准清单；对DoD条目边界的确认意见 |
| 开发与测试 | 提供可核验的技术条目与验证手段，说明检查所需工具和时间 | 技术类候选条目；核验方式说明 |
| Scrum Master或团队facilitator | 组织制定工作坊，维护DoD版本与变更记录 | 工作坊纪要；DoD版本记录与变更日志 |
| 团队整体 | 在迭代中执行DoD，在回顾会上提出调整建议 | 执行反馈；校准提案 |
| 管理层 | 为DoD要求的检查活动提供时间与工具条件，例如流水线、测试环境、文档空间 | 资源与工具支持决定 |
需要说明的是，DoD的最终确认权在团队整体，facilitator负责组织与留痕，不代替团队做判断。管理层提供条件支持，也不直接修改条目内容。
持续校准：节奏、触发条件与版本管理
DoD需要随团队能力和业务风险同步演进，校准机制包括固定节奏、触发条件、变更规则和版本记录四部分。
固定节奏。每个迭代回顾会留出固定时间审视DoD执行情况，例如15到20分钟，检查哪些条目被跳过、哪些条目检查成本过高、哪些返工没有被覆盖。固定节奏保证校准不依赖偶发讨论。
触发条件。出现以下情况时，可在回顾会之外发起临时校准：同类缺陷重复出现；交付后返工集中在某一环节；团队引入新工具、新环境或新的合规要求；团队能力明显变化，例如新成员加入或测试自动化程度提升。
校准动作。新增条目需说明它解决的具体问题，并给出核验方式；删除条目需说明该风险已被其他机制覆盖，例如已由流水线自动拦截。增删都应在回顾会上由团队确认，避免个人单方面修改。
版本管理。记录每条条目的增删时间、原因和责任人，保留历史版本。版本记录的价值在追溯：当返工再次出现时，可以判断是条目缺失、条目执行不到位，还是条目已被删除但风险并未真正覆盖。
防止膨胀。条目数量和检查成本需与迭代节奏匹配。定期合并重复条目，把低频或高成本的检查降级为专项检查，例如每季度做一次而非每个工作项都做。校准节奏可参考下表：
| 场景 | 校准时机 | 参与角色 | 产出 |
|---|---|---|---|
| 常规审视 | 每个迭代回顾会 | 团队整体 | 条目增删建议与执行反馈 |
| 重复缺陷触发 | 缺陷复盘后 | 开发、测试、产品负责人 | 新增或修订条目提案 |
| 工具或合规变化 | 变化落地前 | facilitator、相关角色 | 条目调整与启用条件 |
| 季度整理 | 每季度一次 | facilitator牵头 | 合并、降级或删除低频条目 |
变更记录模板可包含字段：条目内容、变更类型（新增/修改/删除）、变更原因、关联问题或缺陷、责任人、生效日期、历史版本号。这些字段足以支撑后续追溯。
示例：一个团队如何把返工问题变成DoD条目
以下为演示情景，用于说明从问题到条目再到校准的完整链路。某团队连续两个迭代在交付后出现两类返工：接口联调失败导致联调阶段反复修改，文档缺失导致接手人员重复询问。
问题归因后确认两点：联调验证没有纳入完成判断，开发在本地验证通过即标记完成；文档更新没有纳入完成判断，交付时才发现接口说明缺失。转化后的条目示例如下：
- 涉及对外接口的工作项，已完成与依赖方的联调验证，并在工作项中留存联调记录（核验方式：查看联调记录与依赖方确认）。
- 接口或配置发生变更的工作项，已更新对应接口文档，文档链接附在工作项中（核验方式：打开文档确认内容与变更一致）。
试运行一个迭代后，团队发现联调记录逐条留存成本过高，部分小改动也要走完整联调。校准会上调整为：涉及对外接口变更的工作项全量核验，内部接口改动改为抽样核验，抽样比例由测试在迭代内确定。文档条目保留，因为缺失导致的返工更集中。
校准后可观察的变化指标包括：联调阶段返工次数、文档相关询问次数、评审会上关于“是否完成”的争议次数。这些指标在迭代回顾会上对照，用于判断条目是否有效，而非作为考核依据。
当DoD条目需要落到工作项上执行时，团队可以把条目转化为工作项状态流转前的检查项，让“完成”的判断有统一入口。ONES支持在工作项类型上配置状态与字段，团队可将关键条目设为完成前的必填检查，变更记录随工作项留存，便于回溯某次交付是否满足当时的DoD版本。这一衔接适合条目已稳定、需要减少人工漏检的团队；条目仍在频繁调整时，先用文档版本管理即可。
完成检查：DoD是否真的在起作用
DoD机制是否落地，可以用以下清单逐项核对。建议在每个迭代回顾会或每季度整理时执行一次。
- 条目可核验性：每条是否有人能在交付前明确判断通过与否；是否存在“质量达标”这类无法判断的表述。
- 执行一致性：迭代内是否存在绕过DoD直接标记完成的情况；如有，记录原因并判断是条目不合理还是执行不到位。
- 争议下降：评审会上关于“是否完成”的争论是否减少；争议是否从“算不算完成”转向具体的条目讨论。
- 返工归因：交付后返工是否可追溯到DoD未覆盖的环节；可追溯的返工是否已转化为候选条目。
- 校准留痕：变更记录是否完整、可追溯；每条增删是否写明了原因和责任人。
- 成本匹配：条目检查耗时是否与迭代节奏匹配；是否存在长期被跳过或形式化执行的条目。
检查结果指向两类动作：条目本身有问题时进入校准流程；执行有问题时回到团队工作约定，明确责任人和检查方式。DoD的价值在于让“完成”成为可讨论、可验证、可演进的标准，返工和争议的减少是这一机制生效的自然结果。
常见问题
DoD条目定得越细越好吗？条目太多执行不下去怎么办？
条目细到能被明确判断通过与否即可，继续细化会推高每条工作项的检查成本。常见信号是某些条目长期被跳过或形式化打勾，这说明检查成本与迭代节奏不匹配。
处理方式有三类：把重复条目合并；把低频或高成本的检查降级为专项检查，例如每季度做一次而非每个工作项都做；把只适用于特定类型工作项的条件移到类型级DoD，避免所有工作项都承担。调整时在回顾会上由团队确认，并记录原因。
团队刚开始用DoD，第一个迭代就发现条目执行不了，应该直接删掉吗？
先区分是条目本身不合理，还是执行条件不具备。条目无法判断通过与否、或检查成本明显超出收益，属于条目问题，应进入校准流程修订或删除；条目合理但缺少工具、环境或时间，属于条件问题，可以标记为暂缓并写明启用前提，同时由管理层协调资源。
无论哪种情况，删除条目都要说明该风险是否已被其他机制覆盖，例如已由流水线自动拦截。没有覆盖就删除，等于把返工风险重新放回交付后。
多个团队共用一套DoD，还是各团队自己定？
组织层面可以给出通用底线条目，例如代码合并与流水线检查、文档更新要求，用于统一对外交付的基本口径；团队级DoD在此基础上补充本团队真实的返工点。各团队的技术栈、依赖方和缺陷分布不同，完全共用一套条目容易出现有的团队负担过重、有的团队覆盖不足。
如果采用组织底线加团队补充的结构，需要明确两层条目的维护责任：底线条目由组织层面按固定节奏审视，团队条目由团队在回顾会上校准，变更都保留记录，便于追溯某次交付适用的是哪一版标准。
DoD和验收标准在评审会上总是混在一起讨论，怎么分开？
讨论时先问一句：这条判断是针对这一个需求特有的业务行为，还是任何工作项完成前都要满足的通用条件。前者归入验收标准，由产品负责人维护；后者归入DoD，由团队整体确认。
如果发现某条需求细节被反复写进DoD，说明边界需要重申：DoD回答“标记完成必须满足哪些通用条件”，需求细节留在验收标准里。评审会上出现“算不算完成”的争议时，先对照当前版本的DoD逐条核对，再判断是条目缺失还是执行不到位。
引入新工具或流水线后，原来手工检查的DoD条目怎么处理？
先确认新工具是否真正覆盖了原条目要拦住的返工风险，例如静态检查已由流水线自动执行并阻断不合格提交。确认覆盖后，可以把手工条目改为“查看流水线检查结果”，或从DoD中删除并在变更记录中写明风险已由自动化机制承接。
如果工具只覆盖部分场景，保留条目但缩小适用范围，例如仅对特定类型工作项要求人工核验。工具变化属于临时校准的触发条件，调整应在变化落地前完成，避免迭代执行期间口径不一致。
