使用就绪定义

许多团队都使用完工定义来检查用户故事是否完成以及产品是否做好了交付准备。但团队从他们的产品经理那里获得的用户故事怎么样呢？团队可以使用“就绪定义（Definition of Ready）”检查用户故事的质量。

Alan Bustamante写了一篇博文，题为《定义就绪，提高敏捷团队计划效率的必备实践》。他阐释了在将用户故事加入计划游戏之前，如何用就绪定义检查它们的质量：

完工定义（DoD）和团队工作协议的价值长期以来已经为大量的敏捷团队所理解，而以我的经验来看，在敏捷团队可以使用的工具当中，就绪定义（DoR）是用的最少的工具之一，但它更强大。DoR可以用于多种工件和活动（产品待办事项列表、冲刺评审等等），对于新团队，我更愿意从用于待办事项准备状态的DoR入手，把这一概念引入计划准备，后者是工作流中的一个重要部分。

一个结构合理的DoR能够为团队带来哪些好处？Alan列出了如下几点：

• 衡量待办事项的“准备”状态
• 确保待办事项已经经过“足够”仔细的考虑
• 帮助团队确定产品经理或者另一个团队成员何时工作负担过重
• 保证团队成员对彼此负责
• 减少团队在故事“就绪”前对估计做出承诺的压力
• 减少开发过程中的“需求波动”

对于忙于“半完成”故事的团队，Shrikant Vashishtha在博文《使用“就绪定义”提升冲刺生产能力》中解释了就绪定义如何用于解决这些团队的问题。他写到：

简而言之，任何来自冲刺待办事项的用户故事必须已经就绪，而任何移出冲刺的用户故事必须已经完成。

产品经理与团队合作，首先定义用户故事，然后做计划：

随着用户故事变得清晰，团队没有任何尚未解答的问题或还需处理的障碍，就认为故事已经就绪。之后，团队就可以用故事点估计用户故事了。同样地，这一过程会在针对其它故事的整个会议期间一直持续。对于某些故事，产品经理注意到有尚未解答的问题，就将这些故事搁置待进一步分析。

Shrikant写到，就绪定义可以带来的好处有：

努力实现“故事就绪”可以极大地帮助产品经理，使其工作更紧张有序。同时，它可以为团队提供更多帮助，因为团队成员无需再因为冲刺中的障碍得不到清除而无限制地等待下去了。

敏捷希望业务人员和开发人员每天一起工作，并尽可能多地使用面对面地交流。就绪定义应该对此提供支持，而且不能对产品经理和团队施加太多的规则，Stefan Roock在博文《就绪定义：一把双刃剑》中对此进行了阐释：

（……）就绪定义可能会被用于创建一个管控过度的流程，这会妨碍产品经理与开发人员的协作：每逢产品经理和开发团队之间沟通有问题时，就用新策略扩展就绪定义。在经过多次“改进”之后，就绪定义就需要由产品经理正确地列举出每个需求，并由另一位产品经理和软件架构师一起进行完整和一致性预检查，从而避免任何不确定性或者遗漏细节。这不是Scrum，也不是敏捷。

组织应该防止就绪定义变得无法承受而成为沟通和协作的障碍：

对于就绪定义，我建议：越小越好。团队处理不完整信息的能力越来越强。因此，就绪定义应该随着时间的推移缩小，而不是增大（而通常情况下，完工定义是随着团队能力增大的）。

Stefan Wunder提供了获得Ready-Ready待办事项的5项建议：

• 与团队和产品经理一起定义你自己的就绪定义。一个“ready-ready”用户故事的理想状态是团队可以在没有中断的情况下实现它。
• 只有开发团队才可以将用户故事称为“ready-ready”。因此，开发团队检查每个用户故事，看它是否满足DoR标准。
• 在待办事项列表中，使用标签、着色、交通灯、前缀或者任何你喜欢的方式突出“ready-ready”用户故事。不管你如何标记它们，只要你在看待办事项列表的时侯，一眼能瞥见就行了。
• 使问题（阻止用户故事进到“ready-ready”状态的事）对于每个人都公开透明（……），这样，每个人都知道是什么阻止用户故事进到“ready-ready”状态，所以需要先行处理。
• 确保产品经理和开发团队理解“ready-ready”待办事项列表的好处。到DoR深入每个人的内心后，它就能随时在你需要时提供帮助。好好利用DoR!

查看英文原文：Using a Definition of Ready