数据结构
网络
关系数据库管理系统 (RDBMS)
操作系统
Java
Microsoft Excel
iOS
HTML
CSS
Android
Python
C语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究敏捷开发中的就绪定义 (DoR)
在所有敏捷框架中，Scrum 最受欢迎。Scrum 是一个用于敏捷项目管理和软件开发的框架。它提供了一种简单而有效的方法，以适应性和灵活的方式交付复杂的项目。Scrum 首次引入于 20 世纪 90 年代，此后已成为最广泛采用的敏捷方法之一。
Scrum 应用于广泛的行业，包括软件开发、建筑、市场营销和金融。它的流行源于其灵活性和帮助团队快速高效地交付高质量工作的能力。
DoR 和 DoD 是 Scrum 方法中使用的两个最重要的术语，用于阐述分配的任务是否已准备好以及处于哪个阶段。让我们在这篇文章中深入了解 DoR。
什么是 DoR？
就绪定义 (Definition of Ready，简称 DoR) 是完成定义 (Definition of Done，简称 DoD) 的补充。DoR 是一份全面的标准列表，在团队在下个冲刺中开始处理产品待办事项之前必须满足这些标准。它概述了产品负责人必须满足的条件，以便开发团队在冲刺计划会议期间接受该项。本质上，DoR 可以被认为是产品负责人必须达到的“DoD”，以确保该项已准备好进行实施。
需要注意的是，就绪定义 (DoR) 不是 Scrum 指南的正式组成部分。DoR 的目的是为团队提供积压精炼的指导方针，而不是充当冲刺计划的阶段门或转移责任的工具。
大多数团队从最小的 DoR 开始，并根据需要逐渐添加内容。最好从简单的框架开始，根据需要逐步构建，而不是试图立即创建一个全面的列表。
DoR 的标准
产品负责人 (PO) 和开发团队必须就故事进行过至少一次讨论。
故事必须具有明确的业务价值。
实施故事所需的努力必须进行估算。
故事必须分解成可以在单个冲刺内完成的更小任务。
故事必须至少定义一个验收标准。
坦白地说，您不太可能需要正式记录就绪定义 (DoR)。在积压精炼会议期间，团队会自然地朝着使故事“准备好进行冲刺”的方向发展。
但是，如果您正在寻找 DoR 的实用指导方针，请考虑使用 INVEST 模式。此框架建议用户故事应：
独立 (Independent) - 它不应依赖于任何其他故事才能完成。
可协商 (Negotiable) - 故事的细节仍然可以细化和协商。
有价值 (Valuable) - 它应该为客户或用户提供明确的业务价值。
可估算 (Estimable) - 应该能够估算实施故事所需的努力。
小 (Small) - 它应该足够小，可以在单个冲刺内完成。
可测试 (Testable) - 应该能够编写测试用例来验证故事的完成情况。
简要说明
独立 - 用户故事应该是独立的，不依赖于任何其他故事。如果您坚持编写实际的“用户故事”而不是传统任务，依赖项的数量自然会减少。在确实存在依赖项的极少数情况下，务必记录下来。
可协商 - 用户故事应该关注客户的需求，而不是规定开发方法。开发团队应该有灵活性来提出替代方案，以向客户交付相同的业务价值。
有价值 - 用户故事必须明确说明其业务价值。这通常可以通过“作为……角色，我希望……功能，以便……业务价值”的格式来捕捉。
可估算 - 开发团队必须能够大致估算实施用户故事所需的努力。这可能需要团队向产品负责人提出澄清问题，以更好地理解实施方法。
小 - 用户故事必须足够小，可以在单个冲刺内完成。如果估计较大，请继续将其分解成更小的故事。
可测试 - 故事必须是可验证的，并且其完成情况必须易于测试。这通常需要明确的验收标准，这些标准可以转换为测试用例。
结论
重要的是不要使 DoR 过于复杂。保持简单，无论是遵循 INVEST 模式，还是就开发团队在有效开始工作之前需要什么达成基本协议。产品负责人和开发团队都负有确保故事根据商定的 DoR 标准准备就绪的责任。
621 次浏览
