就绪定义

DoR通常在Scrum流程中使用，作为用户故事能够进入Sprint的指导意见。

2008年 第一次正式说明“就绪定义”（当时叫 ready-ready，就绪的就绪）

https://scrumftw.blogspot.com/2008/10/ready-ready-definition-of-ready-for.html

Scrum指南中也有关于就绪的描述，但没有作为Scrum指南的术语。

Scrum指南推荐用Backlog Refinement这个活动来促进业务和开发的沟通并对需求理解一致，从而“就绪”）
https://www.scrum.org/resources/blog/why-isnt-definition-ready-described-scrum-guide

DoR可以有效防止“低质量需求”流入研发侧，产生浪费。例如：需求描述不清晰、需求价值不明确、外部依赖没有提前识别，故事过大不确定的风险高，故事过大无法在一个迭代完成，无容易测试验收，等等情况。

通过DoR，可以促进业务和开发之间的沟通和对齐，减少歧义、误解和误会。
通过DoR，可以保证产品符合用户的真实需求，从而保证产品质量。

在平日的Backlog refinement活动中，业务和开发一起沟通，梳理需求的细节以符合DoR。

最迟在计划会结束时，用户故事符合DoR，进入当次迭代。

自管理团队通过团队公约进行必要的流程和约束，DoR就是其中一项公约。

DoR需要由敏捷团队共同讨论并达成共识，而不是领导或干系人自行决定。如果团队成员不认可或不理解，被动执行的效果大打折扣，敏捷团队的主动性和自组织能力也会降低。

每个团队的DoR可能有所不同。

DoR不是一步到位的，是在迭代中根据团队能力经验和项目阶段进行逐渐完善。

经常会在回顾会中找到的改善点，从而改进DoR。

以下是DoR的一个例子（团队可以自行开发适合于自己的DoR）：

1 . DoR和DoD的关系：

• DoR是“就绪定义”，表示“该需求已就绪，可以进入迭代”。DoD是“完成定义”，表示“该需求已完成，可以交付使用”。

• DoR有助于输出高质量的用户故事，让开发过程更加高效和准确，符合用户真实需求，保证产品的外部质量。而DoD有助于输出高质量的代码，从而保证产品的内部质量。

2 . DoR和AC的关系：

• DoR是团队对需求就绪定义的一致标准。

• AC是针对每个需求的，是这条需求具体需要符合的验收标准。每个用户故事的AC都是独特的。

• DoR中包含“明确的AC”。

3 . 为什么Scrum指南中没有DoR？

DoR虽然可以帮助提高产品代办事项的质量，但它经常成为开发团队和产品负责人之间的“契约”，成为顺序执行的门槛：只有符合DoR整个检查表的PBI才会被选择用于Sprint Backlog，会增加不必要的过程开销。

Scrum指南为“就绪定义DoR”提供了另一个方案: Backlog refinement 待办事项精化，作为一项持续和频繁的活动来澄清和改进产品待办事项，提高其质量并就绪于下个Sprint的开发。

请参考
https://www.scrum.org/resources/blog/why-isnt-definition-ready-described-scrum-guide

1. https://scrumguides.org/

2. http://scrumbook.org.datasenter.no/value-stream/product-backlog/definition-of-ready.html

3. https://www.scrum.org/resources/blog/why-isnt-definition-ready-described-scrum-guide

此处仅以《京东敏捷实践指南》为例。 每个优秀敏捷团队的DoR都有着自己的成功故事，期待你自己的成功案例！

京东ME团队的DoR:

• 用户故事、业务逻辑、验收标准清晰

• 有优先级排序

• 第三方依赖时间确定

• 有业务期望上线时间

• 有干系人

• 交互、视觉、切图完成