DoR 到底是什么

近期，关于描述性操作要求（DoR）的使用和定义引起了一些讨论。针对提出的问题，“DoR的目的是什么？”很多人难以回答。然而，了解DoR的作用和使用方法只需回答这个问题即可。

在实践中，DoR通常有以下几种类型：

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

这些DoR可以单独或组合使用，具体取决于团队、产品负责人（PO）和Scrum Master（SM）之间的共识。

正确使用DoR通常不会有副作用，因为它们是预防性措施，用于规避风险。但错误使用DoR可能会导致敏捷开发退化为瀑布模型。Stage-Gate（门径模式）是一个例子，其中Gate可以视为DoR的验证点，DoR成为了进入下一阶段（Stage）的标准。

如果DoR被设置为绝对标准而非指导意见，就会出现问题。例如，如果用户故事的DoR被设定为所有页面原型完成后才能进入开发阶段，那么研发人员将不得不等待所有原型完成，这实质上是瀑布模型的体现。这样的做法可能导致返工或用户反馈引起的修改，造成资源浪费。

相反，更好的DoR应该允许在主流程页面原型完成后即可开始开发，这样的修改引入了协商，允许团队就DoR达成共识，而不是遵循冰冷的标准。这种做法留下了一些不确定性，但促进了增量、迭代和反馈，减少了等待时间，使得团队可以更快开始工作。

总之，避开DoR的唯一禁忌，团队将能够灵活高效地运用DoR。作者邀请读者分享他们关于DoR的看法和经验。