一句话读完
1. DoR
DoR中的R表示Story“准备就绪”，是Story“合格”的验收标准，即Story应该“长什么样”，通过DoR的Story可以从Product Backlog进入Sprint Backlog准备开发，属于Sprint开始前的需求确认阶段。
常使用INVEST原则定义DoR：
Independent：可以独立开发
Negotiable：体现用户需求
Valuable：业务价值明确
Estimatable：开发成本（时间）可预估
Testable：可测试，即本迭代可以完成，否则需拆解
一份DoR清单：
Story的业务价值清晰 Story可测试 Story技术可行 Story依赖明确 Story至少包含一个AC PO和Dev Team开会讨论Story，并达成共识 Story本迭代可以完成 Dev Team估算Story开发时间 UX线框图得到Dev Team认可 其它非业务定义，包括性能、可扩展性和安全标准等 明确Story的验收人 Dev Team演示Story
2. DoD
DoD也是验收标准，它是Story开发完成后，确保可以交付使用验收标准，包括AC、测试、bugfix、部署等条目，所以DoD标准的目标只有一个：是否可以交付使用（ship it）。
DoD一般要回答以下问题：
技术规范（代码评审、压力测试、编码规范）
运行环境兼容性，例如Linux系统要求，Andriod/IOS/Browser版本兼容性 自动生成API文档，手动更新用户手册 验收目标（试用/演示/正式投入市场） 安全性 并发规模
一份DoD清单：
代码覆盖所有AC 代码有注释 PR审核通过，合并到git master 静态代码检查并满足开发规范 可以正确构建 部署到测试环境 单元测试满足覆盖率要求，并全部通过 通过UAT测试 Story验收通过 更新相关文档和图表 关闭Story 更新接口文档，包括英文和中文
3. 对比
DoR和DoD都是验收标准，只是用在不同阶段。
DoR相对固定，而DoD则是动态的，例如，项目早期相对宽松，越接近投入市场越严格。
DoR可以理解为PO的DoD，表示“该需求明确，可以进入迭代”，DoD表示“该需求完成，可以交付使用”。
在实际实践中，早期的DoR和DoD只是简单的几句话，他们是在Retro中逐渐成型和完善，像产品一样，体现产品在每个Sprint要达到的目标。
DoR和DoD都表示“要做什么”，但DoR重在功能和特性，描述Story“要做什么”才能满足用户需要，DoD重在迭代和交付，描述开发团队“要做什么”用户才能使用。
DoR和DoD的初衷是通过一份简单的文档，在公司内部的股东、项目负责人和开发团队间达成一致，随着开发外包和分包，DoR和DoD逐渐成为甲乙双方的承包合同和SOW的一部分，甚至成为双方协商项目范围的工具，可以清晰描述需求，明确双方责任。
DoR有助于BA输出高质量的Story，而DoD有助于Dev Team输出高质量的代码。
小提示：先定义简单的DoR和DoD，迭代中逐渐完善，不要“一步到位”，不要过度设计，这也是敏捷的本质。
敏捷小抄
Product Backlog | 产品待办清单，或产品To-Do List |
Sprint Backlog | Sprint待办清单，或迭代To-Do List |
Acceptance Criteria | 验收标准，简称AC |
Product Increment | 产品增量，即每个迭代完整需求集 |
Sprint | 本意冲刺，代表一个周期固定的迭代 |
Product Owner | 项目负责人，简称PO |
Business Analyst | 业务分析师，简称BA |
开发团队 | |
Retro | 回顾会议 |
