DoR 到底是什么 | IDCF-技术圈

来源：敏捷传习录
作者：陈连生

最近有人问我DoR怎么用，也有问我什么是DoR。我对这个问题并没有直接给予回答，而是问了另一个问题，这个问题就是：“你用DoR到底准备达成什么目的？”

奇怪的是，很多人完全无法回答这个问题。其实描述DoR干什么以及怎么用，只需要回答一个问题就够了。

准备好了么？

没错，就是这个问题。下面让我们慢慢说。

DoR 是Definition of Ready的简称，可以翻译为“准备好的定义”或者“Ready的定义”。

DoR 本质上是一个“准入门槛”，满足“只有……才……”这种描述结构，或者具体一点，就是“只有你满足了DoR的要求，你才能正式开始开发”。如果你有Kanban 的使用经验，你就比较好理解DoR的概念，它就是将任务卡片从Selected列移动到Doing 列时，所需要满足的规则。

所以，现在我们可以有个基本概念。DoR 就是当团队需要投入人力去开发某个功能时所需要被询问和判断的标准。

常见的DoR

在实际使用中，我们常见的DoR 有以下常见的类型：

任务已经被分解，并且用户故事点数不超过5点；
业务流程明确，并且至少主流程具有线框图；
验收标准已经完备。

所有的这些DoR 可以独立存在，也可以组合存在。这取决于团队、PO 和SM 之间达成的共识即可。

DoR的必要性

在实际的开发过程中，DoR 是很有必要的，它使得我们在投入实际的人力之前，确认所有的前置条件都已经完成，降低了开发过程中被中断的风险，确保人力投入的效益。

比较常见的可能产生中断的风险有：

依赖问题。这里的依赖主要是一些技术层面的依赖，有时也会包含一些外部资源的依赖；
用户故事过大，导致不能一个迭代完成；
用户故事理解不到位，开发过程中过多的依赖PO 反复澄清。

上述内容，都会导致开发过程未竟全功，或者产生浪费。通过这种方式，改善了开发流程的效率。

DoR的副作用

准确来说，当你正确使用DoR 的时候，不太会有什么副作用，毕竟作为预防性措施，通过消耗一些成本来规避风险，本身无可厚非。但如果对DoR 使用错误，会直接将敏捷变成瀑布。

在此之前，先看一张图，也就是Stage-Gate，门径模式。

（Stage-Gate）

Gate，也就是门，可以看作是对DoR的验证。而验证标准，就是DoR本身。此时，DoR 成为了标准。

换一种说法就是“当你在这个Gate满足了DoR 时，你才能进入下一个阶段，即Stage”。如果你没有满足DoR 的标准呢？那对不起，要么就到此结束，要么就拿回去修改，反正你过不去。

这么说，你是不是明白了一些？没错，DoR 本身是担任了守门员的角色，确保“符合标准的才能过去，否则就过不去”。如上文所述，这在一定程度上，降低了风险。

到这里，都没有问题，过了Gate 之后，我们在Stage依然有很多工作可以去做，此时进行迭代、增量是完全没问题的。

但是，但是，万事就怕一个但是。

这个“但是”就出在对DoR 的设定上，这也就是DoR 使用过程中唯一的一个禁忌，即“将DoR 做成了一个绝对的标准，而非指导意见。”

怎么解释？

看个例子。如果我将某个用户故事的DoR 设定为“只有到所有的页面原型都完成后，才可以进入开发阶段”，这时会发生什么？

此时研发人员需要等待PO或者BA或者其他角色，将所有的页面prototype，甚至是高保真原型画出来后，才可以工作。但此时，如果所有的原型都开发完成了，对于产品的流程就已经完全敲定了，后续研发将会彻底变成一个“对已知的、明确的设计”而进行的开发。此时瀑布反而是最好的开发模型。而如果再遇到一些返工、用户feedback导致的修改，那么已经完成的工作可能会被抛弃，这直接导致了大量的浪费。然后你回头看看，你发现，这不就是瀑布模型么？

所以，比较好的DoR 应该是这样——“当主体流程页面原型出来后，就可以进入开发阶段”。

不要小看了这一点点的修改，这个修改直接将“协商”引入到DoR 当中了，它使得研发人员、PO可以就DoR 进行协商产生标准，而不是过去冰冷的标准。“主体流程”是什么？包含哪些页面？这些都可以讨论后得到。虽然这个过程留下了一些不确定性，但它使得增量、迭代、反馈成为了可能，也可以让我们不用等待过长的时间，从而让我们可以更快的开始我们的工作。

所以，当你使用DoR 的时候，只需要绕开唯一的一个禁忌后，你将如鱼得水。

真的需要DoR 么

这个问题很难回答，根据咨询师的习惯，一般是回答“这不好说”。

DoR 的存在，一定是降低了流动，这点当我们抛出Stage-Gate模型时就已经注定了。但我的对此的观点比较乐观：在实际敏捷实践过程中，我们需要一些妥协。

诚然DoR 降低了流动性，但这同时也降低了开发过程中，因为前期沟通、拆分或者其他原因，导致的风险，你可以将DoR 视作一种“预防性成本”，这在项目管理中非常常见，尤其是在团队敏捷转型时，这种做法可以很好的从过去瀑布->敏捷的过程中，实现平稳过渡。

当你的团队越来越敏捷时，我们建议减少DoR的条数，逐步放开原先卡在流动上的关卡，以一种更加温和的方式，接受敏捷过程中，需求不确定带来的风险。此时团队的做法是：接受不确定性带来的风险，迎来更大的收益。这里请注意，能这么做的原因，是因为我们有团队的敏捷能力作为降低风险的backup，而不是靠着一身正气去面对。

此时，答案比较明确了：如果你的团队足够敏捷且你愿意接受“高风险高回报”的模式，不设定DoR 也无可厚非；如果你希望平衡一些，那么使用DoR 可以让你更加平稳的进行开发工作；如果你要将DoR 做成绝对的标准，那么请你回去用瀑布。

玩乐高，学敏捷，【规模化敏捷联合作战沙盘之「乌托邦计划」】，2022年5月28-29日成都高新区，7月16-17日北京东城区将举办线下公开课，将“多团队敏捷协同”基因内化在研发流程中，为规模化提升研发效能保驾护航！!🏰⛴

企业组队和个人均可报名参加，一起挑战极客乌托邦