敏捷开发Scrum工具的DoD怎么定义：一份可落地的检查项

敏捷开发中，团队在迭代评审上最容易争执的一句话，往往是某项工作到底算不算做完。开发认为功能已经跑通，测试认为边界场景还没覆盖，产品认为验收条件没有写清楚。争论的表象是人的分歧，根子通常是团队缺一份共享的完成定义，也就是DoD。DoD把完成从个人感觉变成一份可以逐条核对的共同标准。 无论团队使用哪款敏捷开发Scrum工具来记录工作项，都需要先把这份标准说清楚，否则工具里记录的只是一个状态，而不是真正的完成。下面从定义、边界、检查项到落地动作，给出一套可以直接拿去用的方法。

一、DoD是什么：先给一个能独立理解的定义

1. 官方定义：团队对增量质量的共同约定

《Scrum指南》2020版（Ken Schwaber与Jeff Sutherland）把完成定义界定为：DoD是对增量所需质量措施的正式描述，当产品待办列表项满足完成定义时，增量才真正产生。简单说，它规定了增量要满足哪些质量条件才算完成。该版本还把承诺引入每一个工件，增量对应的承诺正是完成定义。这意味着DoD不是某个人的私人标准，而是整个Scrum团队共同遵守、用来判断增量是否可交付的约定。

2. DoD与验收标准不是一回事

很多人把完成定义和验收标准混着用，其实两者作用对象并不相同，下表把差异摊开。

验收标准回答的是这条需求要做成什么样，DoD回答的是任何一条需求做完都必须满足哪些质量条件，两者叠加，一条需求才算真正完成。 需要说明的是，验收标准属于常见的补充实践，并非Scrum框架的硬性要求，缺少它团队也能正常运作。

3. 为什么完成必须由团队共同定义

如果每个角色各自解释完成，评审就会变成反复解释各自理解的场合。开发按代码能跑判断，测试按用例跑通判断，产品按体验符合预期判断，三套标准并行，冲突就会被推迟到交付前集中爆发。由整个团队共同约定并遵守，DoD才可能成为稳定的判断依据。 如果组织层面已经有一套统一的质量标准，团队需要至少遵守这套标准，再在此基础上按自身情况细化。

二、团队对完成的判断为什么总对不上

1. 常见的四种完成口径

团队对完成的默认理解，通常落在下面四种里。

• 自述完成：执行人说做完就算做完，没有外部确认。
• 提交完成：代码提交、文档写了，但没人验证是否符合预期。
• 测试完成：测试跑通了用例，但用例本身未必覆盖真正的验收标准。
• 验收完成：验收人对照事先约定的标准逐条确认，并留下证据。

前三种口径看起来更快，代价是把问题推迟到发布之后才暴露。口径越松，返工成本越高，只是这部分成本往往被推迟到后续迭代承担。

2. 缺少DoD的典型信号

• 每次迭代评审都在争论某项工作到底算不算完成。
• 上个迭代已经完成的功能，这个迭代又冒出一批Bug。
• 估算越来越不准，迭代计划逐渐失去参考价值。
• 代码评审、单元测试、文档这些质量动作被一拖再拖，技术债持续累积。

经验上，出现其中任意两条，基本可以判断团队的完成定义已经流于形式。

三、一份可落地的DoD检查项长什么样

1. 用四层结构组织检查项

一份好用的DoD不该是一长串杂乱条目，而应按交付链路分层。常见做法是分成产品、代码、测试、发布四层，每层只回答该环节的质量底线是什么。分层的好处是便于逐条核对，也便于后续按层加严。

2. 一份可直接套用的检查项清单

下表给出一份分层检查项示例，团队可在此基础上按自身情况增删。

清单的价值不在条目多少，而在于每一条都能被第三方快速判断真假，并对应一份可查的证据。 写不出证据形式的条目，通常还不是合格的检查项。

3. 从轻到重，分三级加严

• 起步级：只覆盖最关键的质量底线，先保证需求澄清、代码评审、用例通过、可回滚。
• 稳定级：补充自动化测试覆盖、性能与安全的基本检查、文档同步。
• 严格级：引入发布评审、灰度验证、监控与告警确认等更高门槛。

DoD不是一次写死的清单，而是随团队成熟度分阶段加严的约定。 一上来就按最高标准执行，团队容易让清单流于形式。

四、怎么一步步定义出团队的DoD

1. 第一步：把现有隐性标准写下来

先把团队里已经默认执行的动作收集出来，比如提交前自测、合并前评审。这一步不是发明新标准，而是把大家心照不宣的做法显性化。

2. 第二步：共同拟定并试用一个迭代

由整个团队一起讨论，写出一份初版清单，并在一个迭代内试用。试用期只做一件事：观察每条检查项在真实工作里是否可行、是否被漏掉。

3. 第三步：评审时逐条核对并留下证据

在迭代评审中逐条核对，同时记录每条检查对应的证据。核对的目的不是考核个人，而是找出定义模糊或无法验证的条目。例如把主观的体验良好，改写为主流程用例全部通过、关键边界场景有回归记录。

4. 第四步：稳定后逐步加严

当现有条目被稳定执行后，再按第三节的三级路径往上加一档。每次只加严少量条目，避免一次性抬高门槛导致执行走形。

五、把DoD落到工具里，避免流于形式

1. 让工作项与检查项绑定

清单写在文档里容易被遗忘，只有挂进日常工作项，DoD才会真正生效。以禅道项目管理软件为例，需求、任务、用例、Bug、发布处在同一条链路上，团队可以把每条检查项对应到工作项的状态上，让完成条件成为流转的前提，而不是事后补记；这套从需求到发布的衔接方式，在其产品与研发管理方案中有更完整的说明。

2. 用证据与回退入口约束状态流转

如果状态迁移不需要任何输入，它就会退化成进度汇报的装饰。让每次完成都要求一份证据，并保留一条退回路径，DoD才不会形同虚设。 退回时保留返工原因，团队才能看到真实的通过率。

3. 多团队协作共用同一份DoD

当多个团队共同开发一个产品时，各自维护一套完成定义，会导致各自的交付物难以拼装为一个完整增量。多团队相互约定并遵守同一份DoD，通常是跨团队交付能被验收的前提，在接口和依赖较多的场景里尤其明显。

六、FAQ

1. DoD和就绪定义（DoR）需要一起用吗？

不一定，但配合使用通常更顺。就绪定义管的是工作进入迭代前的条件，DoD管的是交付时的质量底线，两者作用点不同。团队可以先落地DoD，再根据返工情况决定是否引入DoR。

2. 迭代周期很紧，DoD会不会拖慢交付？

短期看，核对会占用一些时间；长期看，它把返工和争议提前消化。如果周期确实吃紧，可以先保留最关键的质量底线，其余条目留到后续迭代补充。

3. 新成员加入后，怎么快速对齐团队的DoD？

把DoD作为入职材料的一部分，并安排一次结对或演练，让新成员在真实工作项上走一遍核对流程，通常比单纯阅读清单更有效。

4. DoD和验收标准发生冲突时以哪个为准？

两者一般不冲突：验收标准管这条需求做成什么样，DoD管所有需求的质量底线。如果某条验收标准与DoD矛盾，通常说明需求边界或质量约定需要由团队和产品负责人一起重新澄清。