1、DoD 是什么

DoD = Definition of Done，译为完成定义，是用于把控研发质量的第二道门。它是需求准出的标准，通常呈现为一份清单形式的简短文档，定义了用户故事被视为「完成」所需要达到的最低验收条件，常由产品负责人 PO 和开发团队共同协商决定。DoD也是验收标准，它是Story开发完成后，确保可以交付使用验收标准，包括AC、测试、bugfix、部署等条目，所以DoD标准的目标只有一个：是否可以交付使用（ship it）。

2、DoD 的价值

DoD 通过建立通用的标准，确保团队每位成员对价值增量的完成具有相同的理解，避免了团队内外潜在的认知偏差；同时，清单内容还能提升团队的信息透明度，辅助工作点数的评估和计划制定，推进故事的完成。

3、DoD 的内容范围

Brian Will 指出 DoD 通常会说明以下内容：

• 用户故事所处的操作环境和集成级别（哪个特定版本的 Linux、Android、iOS 或浏览器）？
• 需要输出什么级别的文档（自动生成的 Javadoc，还是完整的终端用户手册）？
• 有什么质量期望（用于演示的基本功能，还是功能完整且健壮的应用程序）？
• 有什么安全期望（无需安全审查，还是需要从代码审查、代码扫描到网络安全配置等各方面都要进行安全审查）？
• 有什么可扩展性期望（用于演示的 10 个并发，还是扩展至10 万个并发用户）？

4、DoD 的不同维度

Scrum 联盟按照需求的不同层次，将 DoD 分成三种级别：用户故事DoD、冲刺DoD 和发布DoD。

用户故事DoD

也称功能/需求DoD。它声明了故事可交付的底线，即用户故事应完成哪些事情才可以被判定为开发完成，达到可交付的标准。用户故事DoD 的制定可以从以下两方面考虑：

• 用户故事的描述及拆解符合 INVEST；
• 用户故事有验收标准，即 Acceptance Criteria。

冲刺DoD

或迭代DoD，定义了每个 Sprint 需要完成哪些事情，其输出才是可交付的。通常包含以下内容：

• 所有代码通过静态检测，严重问题都已修改；
• 所有新增代码都经过 Code Review；
• 所有完成的用户故事都通过测试；
• 所有完成的用户故事得到 PO 的验证。

发布DoD

发布DoD 定义了增量交付的最低要求，可以参考以下内容辅助制定。

• 完成发布规划所要求的必须具备的需求；
• 至少完成一次全量回归测试；
• 符合质量标准 (Quality Gate)，譬如所有等级为 1、2 的缺陷均已修复，3、4 级缺陷不超过 10 个；
• 有发布通知，即 Release Notes；
• 有用户手册；
• 产品相关文档已全部更新；
• 代码已部署到发布服务器上，并冒烟通过；
• 原始需求提交人完成 UAT；
• 对运维、市场、客服的新功能培训已完成。

此外，在子任务层面，敏捷团队也可以通过开发任务DoD 更好地规范任务完成，比如：

• 代码已经提交到 Git；
• 代码通过单元测试；
• 代码经过 Code Review；
• 代码通过集成测试。

5、DoD要回答的问题

• 技术规范（代码评审、压力测试、编码规范）
• 运行环境兼容性，例如Linux系统要求，Andriod/IOS/Browser版本兼容性
• 自动生成API文档，手动更新用户手册
• 验收目标（试用/演示/正式投入市场）
• 安全性
• 并发规模

6、DoD 的参考例子

• 代码已完成（所有代办事项已经完成编码）
• 代码已注释、已提交，版本库当前版本能正常运行
• 结对检视已完成（或者采用结对编程），代码符合开发标准
• 构建没有错误
• 单元测试全部通过
• 部署到测试环境并通过系统测试
• 通过 UAT（用户验收测试）并签字确认符合需求
• 任何编译/部署/配置变化都已实现/记录/沟通
• 相关文档/图表已完成或已更新
• 任务剩余的小时数已设置为 0，任务已关闭