Scrum协作稳定性保障——DoR和DoD

Posted 2021-04-25 我是程序员

在Scrum框架中，我们知道最终交付给客户的产品，是通过一个又一个的Sprint迭代产生的。那么如何保证每个Sprint是高效的呢？这涉及到很多方面，但最重要的是团队之间的信息透明，即DoR(Definition of Ready)和DoD(Definition of Done)。

简单来说，DoR是一个Sprint迭代正常开启的先决条件，即需求池中的PBI（Project Backlog Item）是否满足加入迭代的要求。而DoD则是Sprint产物验收的标准。

我们只能把需求池Project Backlog 中已经认为是“Ready”状态的需求加入到马上要开始的迭代中，同时在Sprint启动之前，我们也需要明确Sprint及其每一个Backlog什么标准叫做“Done”。当我们团队内部对于DoR和DoD拥有一致的认识时，整个Sprint和团队协作才能达到最理想的专业和效率状态。

当产品待办事项或增量被描述为“完成”时，每名团队成员都必须对“‘完成’意味着什么”有着相同的理解。在此基础上，每个产品待办事项一旦被放入 Sprint ，都应该包含一组由更为具体的完成和检验标准组成的核对清单，并对全员透明。这样做的目的是：

• 指导开发团队在 Sprint 计划会上选择适量的产品待办事项和讨论实现思路；

• 在团队内部就质量和完整性建立共识；

• 限制返工的成本；

• 减少开发团队与产品所有者、产品相关方之间的误解。

DoR和DoD随着经验是不断变化和发展的

每个 Sprint 的“完成定义”与“潜在可交付”越接近越好。不过需要注意的是，随着 Scrum 团队的成熟，工作流程和方式的改进，“完成”定义的要求也会更为严格。如果此前 Scrum 团队对“完成”的要求较低，那前面的 Sprint 遗留和累积下来一些“已完成”的工作一旦影响到产品发布，Scrum 团队就需要安排一个额外的 Sprint 来处理它们。

此消彼长的，DoD的要求越来越严格，DoR的定义就会相应的变得更少一些。

具体的建议

前面关于DoR和DoD都还是很抽象地说明了意义和价值，并没有回答什么样的是“Ready”和“Done”。

DoR

A definition of ready deals with the user story, wherein the user story is ready to be taken into a sprint. It doesn’t need to be “100 % defined” covering all the acceptance criteria. However, it should be “ready enough” only when the team is confident that they can successfully deliver the user story.

一个准备好的用户故事至少要能够回答

• 这个用户故事的意义和目的是什么？

• 我们在实现什么东西？比如能够回答“我想要xxxx”，并且要能附上验收标准

• 我们该如何实现它？能够估计一个用户故事的复杂性是一个迹象，表明开发团队在实现上提供了足够的信息，并且在团队内部保持了一致的意见。

一种有效的类似Checklist的方式是，参照INVEST方法：

• I (Independent)，独立的：这个用户故事应该是独立的，并不依赖其他的用户故事或者其他的外部资源，否则用户故事还可以进行更好的拆解。

• N (Negotiable)，可商议的：这样才能够发现最优的实现方式到底是怎样的。

• V (Valuable) ：这个用户故事能够给客户带来的价值应该是明确的。

• E (Estimable) ：这个用户故事的大小应该是可以评估的。

• S (Small) 分解得尽量的小，以便能够在一个或多个Sprint的时间盒里面得以安排和实现。

• T (Testable) 每一个用户故事都应该有明确的验收标准，以便能够进行测试和验收。

例如 :

• 业务价值被清晰地表达出来。

• 确定了依赖项，并且没有外部依赖项会阻止这个需求的完成。

• 开发团队对细节有充分的理解，因此可以对是否完成该需求做出明智的决定。

• 可以配备适当的人员来完成该需求。

• 用户故事是预估的，足够小，可以在一个sprint内轻松完成。

• 验收标准是清晰和可测试的。

• 性能标准(如果有的话)是定义清晰和可测试的。

• Scrum团队知道如何在sprint评审中演示这个用户故事的实现。

DoD

• 代码开发完了

• 代码有合理的注释，已经提交到代码仓库中正确的分支中

• 代码经过了结对检视或满足了团队的代码规范、质量检测

• 提交的代码没有编译错误

• 具有足够的单元测试用例，并且用例都是通过的

• 部署到了测试环境，并且测试通过

• 通过UAT (User Acceptance Testing) 测试，并获得PO验收

• 任何必须的构建、部署、配置都已经完成

• 相关的文档、图表都已制作或更新。

• 任务中的剩余工时已更新为0，并且关闭了这些任务

Reference

问题的整理过程，参考了一些资料，一并列入文末。

[1] https://www.quora.com/What-is-the-difference-between-the-Definition-of-Done-DoD-and-the-Definition-of-Ready-DoR-in-Agile-processes

[2] https://www.slideshare.net/gramakri/fundamentals-of-agile-methodologies-part-ii

[3] https://www.linkedin.com/pulse/definition-ready-dor-vs-done-dod-brian-will/

[4]  https://www.yuque.com/wtshare/abc/eyv7b2