DoR 和 DoD 是敏捷中两个最基本也是最有用的概念，是“以终为始”落实的关键。
循环迭代
为了把产品做的更好，我们需要不停地迭代和改进产品。在每个迭代中我们关注两件事：
- 什么样的需求才可以开始做（准入条件，DoR）
- 做成什么样子需求才算做完（准出条件，DoD）
把没有完成或没有细化的用户需求放到迭代中，会在开发阶段产生各种问题，因为它遵循一个古老的原则：“进去的是垃圾，出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发，不太可能产出高质量的代码。
一个“准备好”放入迭代的需求应该是清晰的，可行的，可测试的：
- “清晰的”意味着所有的团队成员对该需求达成了共识。通过协同编写用户故事，对高优先级事项添加验收标准，有利于需求的澄清。
- “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。
- “可行的”意味着根据 DoD，该条目能够在一个迭代中完成。否则，条目需要进一步的分解。
DoR 是什么
DoR: Definition of Ready
DoR 是一个待办需求（backlog）是否能够被团队接受，可以作为开发候选所需要达到的最小要求，是团队对产品负责人 PO 提出的要求。
DoR 的一些例子
- 用户故事是清晰的
- 用户故事是可测试的
- 用户故事是可行的
- 用户故事已定义
- 用户故事验收标准已定义
- 用户故事依赖已明确
- 用户故事已由开发团队做过粒度划分
- Scrum 团队已接受 UI 原型设计
- 指定场景下的性能指标已明确
- 指定场景下的可扩展性指标已明确
- 指定场景下的安全指标已明确
- 验收用户故事的人已明确
- 团队都清楚用户故事所表达的意思
DoD 是什么
DoD: Definition of Done
“DoD” 是开发团队在交付用户需求需要达到的最低验收条件，是产品负责人 PO 对开发团队的要求或者共同协商的约定，以保证交付质量。
“DoD”通常会说明：
- 用户故事所处的系统环境（哪个版本的 Linux、Android、iOS 或者浏览器）？
- 需要输出什么样的文档（自动生成的 Javadoc，还是完整的终端用户手册）？
- 有什么质量要求（用于演示的基本功能，还是一个功能完整，健壮的 APP）？
- 有什么安全要求（无安全要求，还是从代码评审、代码扫描到网络安全配等各方面都要求做安全审查）？
- 有什么扩展性要求（10 个并发，还是 10 万个并发）？
DoD 的一些例子
- 代码已完成（所有代办事项已经完成编码）
- 代码已注释、已提交。版本库当前版本能正常运行
- 结对检视已完成（或者采用结对编程），代码符合开发标准
- 构建没有错误
- 单元测试全部通过
- 部署到测试环境并通过系统测试
- 通过 UAT（用户验收测试）并签字确认符合需求。
- 任何编译/部署/配置变化都已实现/记录/沟通。
- 相关文档/图表已完成或已更新
- 任务剩余的小时数已设置为 0，任务已关闭
DoD 要考虑的维度
为 Sprint 中任务给出明确的“Done”定义是非常重要的，但即使你遵循这个最佳实践，最终仍然会有集成问题，会存在 Bug，以及晚期的需求变更。所以，对于大型复杂产品，在正式发布前，单独计划 1 ～ 2 个 Sprint，专门做 Bug 修复，也是合理的。
关于 DoD 的例子，通常需要从几个维度考虑。
1）需求/用户故事 DoD
- 用户故事的描述及拆解符合 INVEST；
- 用户故事有验收标准 AC(Acceptance Criteria)。
2）开发任务 DoD
- 代码已经提交到 Git;
- 代码通过单元测试；
- 代码经过 Code Review;
- 代码通过集成测试。
3）迭代 DoD
- 所有代码通过静态检测，严重问题都已修改；
- 所有新增代码都经过 Code Review；
- 所有完成的用户故事都通过测试；
- 所有完成的用户故事得到 Product Owner 的验证。
4）发布 DoD
- 完成发布规划所要求的必须具备的需求；
- 至少完成一次全量回归测试；
- 符合质量标准(Quality Gate)，譬如所有等级为 1、2 的缺陷均已修复；3、4 级缺陷不超过 10 个；
- 有 Release Notes；
- 有用户手册；
- 产品相关文档已全部更新；
- 代码已部署到发布服务器上，并冒烟通过；
- 原始需求提交人完成 UAT；
- 对运维、市场、客服的新功能培训已完成。
Tips：DoD 必须是团队共同讨论出来的，团队愿意共同遵守的原则，一旦确定，团队就应共同遵守。
DoD 和 DoR 应该上墙
无论是用物理的 Kanban、TaskBoard，还是电子的，建议将定义清晰的 DOD，显式的张贴出来，便于所有人对齐想法。
并且在板子上进行挪动时，无论是挪到 Done 的专题，还是拉到下一个状态，都可以随时看到 DoD 的标准，提醒所有人遵守并检查。保证每个人对一件工作是否完成有一个统一的认识，交付和接纳时时也保持清晰的交接界面。
DoR 和 DoD 另外的用法
DoR 和 DoD 的本意是创建一份简明的文档，用于在项目干系人，PO 和开发团队间达成一致。但是，随着越来越多的工作被外包或分包， DoR 和 DoD 也更多的用于合同协议和 SOW，用以清楚、准确阐述对于需完成工作的期望。
DoR 和 DoD 是很实用的项目范围商议工具，因为它们定义了期望和双方的职责；DoR 帮助客户产出良好的用户故事，为开发团队所用；DoD 帮助交付伙伴根据整体项目需求产出可工作的产品增量，而不仅仅是特定的用户故事功能。
小结
DoR 和 DoD 就像流水线上的两道关，一个管进，一个管出。我们不像牛那么厉害，吃的是草，挤出的是奶。
对团队来说，第一道关更加重要，正如前面所说的，进去的是垃圾，出来的也是垃圾。没有 DoR 的把关，后面的持续改进，工程实践效果都不会太好。