引言
什么是DoR
为什么需要DoR？
在哪里使用DoR
何时使用DoR
投资模型
结论
参考文献
引言
当然，您已经听到了不止一次，您甚至可能甚至与团队一起使用了Scrum工件-Done的定义，以下简称-DoD。 也许在没有意识到的情况下使用它。 关于国防部的许多俄语文章已经发表。 他们在会议和培训中谈论他。 了解为什么需要此工件并查找示例并不困难。 国防部定义了每个团队成员了解任务已完成的标准。 最深层的目标是在每个团队成员之间同步“完成”的概念。 超过这些标准，团队通常会进行回顾。 有一个类似的工件，出于某种原因，在俄语资源中没有提及Scrum，在提到该工件的地方，也没有给出解释，它是什么，为什么需要它，以及如何使用它。
在您的团队中，很可能出现了像您这样的短语：“我们未能实现目标，因为我们不正确地评估了任务”，或“我们的采购订单没有适当的描述就带着任务回来了”。 在我的团队中，这种“信号”不止一次出现，而且很长一段时间以来，我一直在寻找解决此问题的方法。
我在专门针对敏捷的个人资料聊天中偶然发现了Ready的定义（以下简称DoR）。 试图查找信息，我在RuNet中没有找到关于此主题的任何提及。 因此，我去阅读和翻译了英语文章。 现在，我将与您分享结果，希望这有助于使您的团队更酷，更高效。
什么是DoR
那么什么是DoR？ Google翻译人员会告诉您，这是“准备情况的定义”。 如果DoD包含完成任务的标准，则DoR-要准备工作的任务准备标准。 也就是说，如果一项任务符合DoR的标准，则团队可以将其用于工作计划。 看起来很简单，您可能已经开始考虑如何最终与团队一起为您的PO制定完整的需求清单，以便开始编写大量文档，其余团队成员可以从容地坐在他们的计算机上并默默编写代码。 这仅仅是开始，DoR并不是乍看起来的样子。
为什么需要DoR？
首先，我们回答以下问题：为什么需要此工件？ 他会为团队带来什么好处？ DoR将帮助团队：
- 避免对没有明确完成标准定义的功能进行操作。 团队将了解何时认为用户故事已完成，以及需要执行哪些操作。
- 不要浪费大量时间徒劳地进行冗长的讨论，周密的任务。 预先处理的任务将节省整个团队的时间。 计算一个人讨论“坏”任务所需的时间。 现在乘以团队人数。 现在，这些任务的数量很多。
- 将时间和精力集中在尽可能“安全”的事情上。 最强大的激励因素之一是扔进垃圾箱的功能。
- 让每个参与者参与任务的讨论。 首先，它激励团队。 其次，它有助于揭示团队中的每个成员都是专家。 第三，开发人员将对问题提出自己的看法。 在讨论过程中，可能会出现其他与原始想法完全不同的解决方案。
让我们看一下由于缺少DoR而间接或直接导致的问题列表：
- 团队成员之间经常会出现对问题的理解上的差异。 冲刺结束时，差异加剧，这很自然地导致了开发过程中发生更改时的事件。 但是鉴于没有记录这些时刻，只有直接遇到这一时刻的人才知道这些时刻。
- 功能需求的更改速度比团队设法理解它们的速度快。 由于任务进入冲刺的过程具有很高的不确定性，因此在零件准备就绪并奠定“基础”时，会出现新的信息，需要重新开始。 任务执行得越糟糕，冲刺中出现这种情况的可能性就越大。 最后，这将导致fakap。
- 评估从功能获得的结果时常会遇到问题，团队不知道如何收集指标，甚至更糟的是忘记了它们。 Scrum主要是关于给客户，用户或购买者带来的好处。 如果团队不评估任务的收益，则不会获得反馈和调整产品开发过程的能力。 这可能会导致完全失败。
- 此外，缺少DoR会对测试产生重大影响，它将代替测试对用户故事的质量检查期望，而将测试开发人员的期望。 代码可以完美地工作，自动测试可以像发条一样工作，但是该功能不适用于生产环境。
最终，这导致了无法使用，无用的，无法解决主要问题的产品的发布。 这是每个人都想花在重要事情上的时间的浪费。 在其中一篇文章中，我碰到一个好话：“垃圾进来了，垃圾出来了。”
在哪里使用DoR
DoR用于“产品积压细化”（以下称为PBR）或更常见的工件名称：修饰。 在此活动期间，“用户故事”变为“准备就绪-准备就绪”。 这意味着事件的结果（在产品积压订单中）为“美国就绪”。 需要DoR来描述可以就计划进行讨论的美国所在州。 这叫做Takin in-被美国接受。
为了进一步讲解，我正在关注Scrum and Agile宣言的创始人之一Jeff Sutherland在他的视频中如何谈论DoR和DoD 。 Sutherland介绍了“完成”和“就绪”的概念。 当团队成员说任务准备就绪或完成时，可以理解为该任务符合团队在DoD和DoR中定义的标准。 这是一个重要方面，团队的每个成员都必须理解这一点，并且不要忘记。 否则，当Petya在Daily上告诉任务已经完成，然后事实证明需要在其中添加测试，并且重构代码很好，并且代码审查尚未通过时，就会出现有趣的情况。
因此，在美国达到“准备就绪”状态之前，它不存在，并且在计划中没有进行讨论。 待办事项的顶部应该只有美国，并且处于“就绪”状态。 实现此目标的最佳方法是与团队一起锻炼美国。 这将使我们能够从不同角度审视问题，让每个团队成员都参与到过程中，然后对发布的功能承担集体责任。 如果开发人员意识到这是“他们”共同工作的成果，他们将对结果和质量负责。
何时使用DoR
当团队在PBR期间了解到任务不符合DoR且携带太多不确定性时，请列出问题清单，选择一名研究人员，然后将任务推迟到下一个PBR。 在我的团队中，它被称为“研究”，但是后来我们从XP转到Spike，因为我们认为它可以带来更多结果，并且使研究结果更加清晰。 确保按时间限制学习，并在最后指定要获得的结果。 在Spike期间，研究人员可以吸引外界的任何帮助，例如，其他团队的成员，方法学家，采购经理，建筑师...一般来说，任何认为合适的人。 结果-问题答案，新数据，原型。 如果有很多此类“用户故事”，则可以在每个sprint中花1-2个Spike进行下一次迭代，从而确保Ready任务持续不断。
如上所述，DoR是一组条件。 团队可以尝试自己制定这些标准。 处理迭代中跟踪的“信号”。 回顾这些观点，找到根本原因。 如果您不想为此花费下一次回顾，请使用现成的解决方案。
许多文章描述了INVEST模型，该模型类似于SMART，但更适合于用户故事。 除了文章之外，敏捷文献中也建议使用此模型。 例如，Roman Pichler在《 Scrum中的产品管理》一书中或Mike Cohn –《用户故事》中。 灵活的软件开发。”
投资模型
- 独立独立性-尽量避免建立相互依赖的美国，这种依赖会在确定优先次序和计划时造成问题。 客户可以选择优先级较高的美国，这取决于优先级较低的任务。 附属美国必须合并，以不同方式分割或加息。
- 可商谈性-美国不是正式的合同义务或要求。 美国不是技术任务。 在冲刺期间，可以并且应该讨论和修改它们。 带有历史记录的卡，无论其形式如何，都是对功能的简要说明，应在工作期间阐明其详细信息。 当任务完成时，在卡片上留下笔记以引起讨论。 在这里找到中间立场是很重要的，因为过多的笔记，团队会认为这是详尽的信息，而且根本不会进行讨论。 我的团队很快就发现了这一点。 讨论的细节成为测试，可以写在纸的背面，也可以写在电子卡的注释中。 验收测试对每个人都简单明了。
- 对用户或客户有价值的价值-“每个故事都应对用户具有一定的价值”-这是不正确的陈述。 最经常忘记买家。 关注焦点，具体取决于您的公司：B2C，B2B，B2G。 最主要的是避免只对开发人员有价值的故事。 应该重新编写这样的故事，以使收益变得显而易见，并且客户可以设置优先级。 无需将架构任务扔到垃圾箱中，无需向客户说明这种任务将带来什么好处，并重新制定它。
- 估算价值-开发人员应该能够估算美国的规模，即实施所需的大概时间。 劳动强度可能无法测量的三个主要原因：
- 团队缺乏学科知识
- 团队缺乏技术经验
- 故事太大了
在第一种和第二种情况下，秒杀将为您提供帮助。 第三，美国需要分解成较小的国家。 - 紧凑性小-很大程度上取决于美国的规模，太大和太小的美国很难评估。 史诗很难处理，因为它们由多个美国组成。 史诗可以分为两种类型：
- 复合。 这里的一切都很简单-我们分解了。 考虑其余几点，团队可能会建议的第一件事是：按建筑层的类型划分美国：按美国划分为数据库，后端，前端等。
- 复杂。 美国之所以庞大，是因为它们的本质，它们要么没有分解，要么非常困难。 在这种情况下，我们使用峰值。
- 可测试的可测试性-确认美国已经成功开发，这是一次成功的测试。 如果无法对美国进行测试，则团队将不知道创建何时完成，或者自己提出标准。 而且，团队中的每个成员都会有所不同。
结论
总结：使用DoR，您将不会摆脱将渗入sprint的差距。 这也并不意味着在sprint期间，PO和开发人员之间不需要持续接触。 以验收测试的形式不断记录讨论的结果，因此团队中的任何一个都不会失去对任务状态的理解。 与团队分析和讨论当前的问题，也许它们与缺少DoR有关。
DoR是一种人工工具，可以使团队更好地思考美国，从而最终降低风险，并使每个团队成员不断讨论任务。 在“用户故事”一书中，您会找到许多有关INVEST和用户故事的详细信息。 我建议让团队的每个成员都阅读本书，或者至少自己阅读并与他们分享信息。
在评论中写下您的团队使用了哪些DoD和DoR。
参考文献
1）Roman Pichler“ Scrum中的产品管理”
2）Mike Cohn“自定义故事。 灵活的软件开发”
3） agilealliance.org
4） linkedin.com
5） boost.co.nz
6） scruminc.com