译者序：在很多敏捷项目中，秩序诞生的标志之一是有了成文的DoR。但是项目组和需求方的折中往往也无可奈何地始于将没有就绪的需求纳入到Sprint待办事项列表，并为Sprint实施阶段带来一系列的不可控因素。为什么市场和产品人员时常要求技术人员在Sprint里实施一些没有充分精炼过的需求？如何制定DoR，并使之解决市场和技术之间的断层问题？推动DoR的过程中出现问题要怎么办？本文作者立足于自己的经验，分享了对以上问题的看法，对正在踌躇是否制定、正在制定和推动DoR的团队有一定的借鉴意义。
原文：
您有一个精炼过的产品待办事项列表，或者说是非常接近精炼的。与此同时，您正在准备做Sprint计划。万不得已的情况下，产品待办事项列表上的某些项目依旧太模糊，开发团队无法对它们进行实施。然而Sprint待办事项体现了实现Sprint目标所必需的工作，同时它指导开发。因此，“ Sprint待办事项”中的项目必须是具体的。它们不可以是模糊的。但是，开发团队需要多“具体”才能开始他们的工作呢？
如果开发团队不能完全理解产品待办事项（PBI），开发工作和开发时间往往会激增，从而导致Sprint目标未能达成，或者是交付无法符合利益相关者的期望。
开发的挑战在于获得新的想法并使它们变为现实，这实际上是在开发这些想法。这是思想从根本上的一个改变：一个想法开始时很抽象，但是开发要求这个想法在每个细节中都很具体化。这种思想上的改变最终只有在开始开发的时刻才会真正的发生。但是，如果您希望可以进行详细的计划（并且您需要详细的短期计划以使您的流程保持清晰明确），那么这些需要开发的想法必须足够具体，才能回答设计的问题。具体到什么程度？具体到足以让团队可以充满信心，来进行详细的计划。
我曾经作为自由顾问为一家小公司做一段程序。有一次，首席执行官要求我编写一些软件，并提出了固定价格。“我们可以达成一致了吗？” 他问。“不，”我说。“该软件的定义不够精确，我无法评估完成它需要多长时间。”
换句话说，在市场的世界和设计的世界之间，存在着一个断层。他们各自创造的认知以不一样的量级演进：市场了解逐步而缓慢，而设计往往会迅速聚焦（参考《实现规范 Enabling Specifications》）。它们之间需要一个组织级的边界。否则，您会同时削弱了对市场和项目的焦点。理论上，您可以通过流程的边界来实现这种分离。然而组织人员关系跨越了整个过程，因此您仍然面临着一个问题：是关注业务和价值领域，还是关注产品和技术领域，在这两者之间，人们可能依旧会举棋不定。反过来，要解决该问题，您可以从时间上来划分人员在这两个领域之间的关注点。但这会导致人员在任务上下文之间切换，众所周知，这会导致效率的降低。Scrum将这些问题从组织级别上区分开来，分成产品负责人和开发团队。而它成功的关键点在于，在这两个领域之间有一个接触点。
当您处于计划的困境中时，有一种强烈的诱惑让您想要快速做出假设，并将棘手的问题（例如详细的估算）推迟到以后。而当一个小组一起计划时，往往会面临一些隐性的同僚压力，为了使计划过程能够顺利进行而将困难的问题推迟。要解决这个问题，团队必须达成一致，最先解决最棘手的问题。为了避免在不确定的情况下开始工作，团队对截止点需要有一个明确的共识，并共同遵守这个客观标准。
在精益的思维中，反复不定是造成浪费的原因之一。如果开发团队不足以理解某些产品待办事项的真正含义，或者不能很好的理解如何开发或评估它，那么Sprint交付成果的偏差就会增加，同时这种工作还可能会导致成本，风险和不确定性增加。
因此：
每个产品待办列表上的项目必须至少满足以下条件，开发团队才能在Sprint计划会议上将其选为Sprint待办列表的候选项：
1.团队可以针对这项工作立即采取行动。
2.预计的交付物具有价值。
3.产品负责人和开发团队对它进行过讨论。
4.开发团队对它估算过。
5.它是可测试的，并且产品负责人对此测试有具体说明。
6. Scrum团队已经把它调整到合适的大小（请参阅缩小项目Small Items）。
如果产品待办事项列表的顶部具有满足这些条件的产品待办事项，而这些产品待办事项多到足以填充一个Sprint，那么它就是“就绪”的。
良好的就绪定义可以帮助指导团队处理外部依赖性。如果某个待办项取决于团队无法控制的外部事件，将其放入Sprint待办事项列表中会大大增加在Sprint结束时不能交付潜在的定期产品增量（Regular Product Increment）的风险，而您对此无能为力！您需要自始至终的在产品待办项级别上进行依赖性分析，而不能仅仅在定期产品增量级别上粗糙的管理依赖性；团队最终都需要了解产品待办项级别的依赖性，才能在生产过程中对工作进行排序。您需要考虑将涉及外部依赖性的标准作为“就绪定义”的一部分。
定义就绪与实现规范之间存在重要的相互作用。下一个Sprint的待办候选项必须最迟在该Sprint计划期间准备就绪。Sprint计划的产出物，包括产品待办事项连同产品负责人的说明和澄清，必须能让团队无所畏惧地开始实施。
Scrum团队的目标是要满足所有就绪标准，因为它致力于精炼产品待办列表，并争取在Sprint计划之前制定实现规范。这项活动的目的是使PBI不受干扰地通过“就绪门”，每个待办项仅需遵守简短的清单即可。清单对于不成熟的团队来说，允许他们能够“停止生产线”，这很重要，但更大的好处来自于可预期的约束条件，以及提前筹备PBI，让它们在Sprint开始时已完全准备就绪，从而使得整个流程畅通无阻 。
请注意，并非产品待办事项列表中的所有PBI都需要准备就绪，但随着它们在产品待办列表中的上移，它们应该朝着就绪状态迈进。“就绪”定义了那些可以进入Sprint的PBI； 与此相对，“完成”定义了那些在Sprint期间或结束时可以交付的PBI。
如果PBI没有准备好怎么办？尽管整个团队都致力于PBIs，产品负责人有责任充分做好Sprint Planning的准备，以使得团队能够不受阻碍地为当前Sprint的开发PBI候选项。在大多数情况下，“未准备就绪”表示产品负责人必须回去做更多的分析，再将PBI带回团队。Scrum的传统是，如果在Sprint计划时没有准备就绪的产品待办列表，则开发团队有权“去海边度假”，就如同于Jeff Sutherland在《 Scrum：一半的时间内完成两倍工作的艺术》（第137页，“准备完成”）中所描述的一样。这让产品负责人没有把待办列表准备好的事实变得显而易见。如果您总是“在海滩上”，则可能是工作流出了问题。您对未就绪的产品待办列表有何贡献？团队能如何帮助产品负责人？
为了区分Scrum中的就绪概念是一种与语言中的“就绪”不同的术语，Scrum的人有时会使用短语“ 就绪的就绪（Ready-Ready）”，而不是单个单词“ 就绪”。理查德·科隆法尔特（RichardKronfält）在2008年最先发布了关于“就绪定义”的正式描述。25
非常感谢Peter Gfader的评论！
【25】. Richard Kronfält. “就绪的就绪: 为可以进入Sprint计划的用户故事定义就绪.” Blogspot.dk, 2008年10月, http://scrumftw.blogspot.nl/2008/10/ready-ready-definitionof-
ready-for.html (访问于2017年11月1日).
——译者：Emma
校对：Suzzi
参考资料：
（1）A Scrum Book：65 Definition of Ready
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/tech/dev/295391.html