Scrum: DoD vs DoR vs Acceptance Criteria

完成的定义 (DoD) 验收标准和准备好的定义 (DoR) 是 Scrum 中的重要概念，而且经常被误解。让我们澄清一下它们是什么……

DoD 通常是一份清单形式的简短文档，它定义了产品待办事项（即用户故事）何时被视为“完成”。它有各种理由和各种解释方式：

您需要对“完成”（=“此用户故事已完成”）的含义有一个共同的定义。否则，它对团队中的每个人都意味着其他的东西。
你所有的非功能性需求都存在于国防部。
要添加到每个故事的特定验收标准中的通用验收标准列表。
您在回顾中发现的许多改进最终都会出现在国防部。

大多数团队从没有或非常简单的国防部开始。然后他们根据需要在每次冲刺后添加到国防部。提示：不要因为 DoD 过多而麻痹自己！但请记住：敏捷项目中的“完成”意味着“在交付之前不需要做更多的工作”。因此，如果有人说“该功能已完成，但只需对其进行集成、测试、部署……”，就敏捷而言，它不会被视为“完成”！

检查某事是否“完成”的最佳方法是简单地将其发送！如果你能发货，那就真的完成了；如果您无法发货，只需在发货前完成缺少的工作即可“完成”。请注意：您不需要实际运送它，但您需要让人们相信您可以运送它。

典型的 DoD 可能如下例所示：

已编写自动化测试，所有测试均为绿色
代码被重构和审查
代码与主分支集成
部署到暂存环境
翻译成英语和德语

对完成的简明定义将帮助您提供质量、保持您的计划整洁并灵活应对不断变化的需求。

DoR: 准备的定义

DoR 是 DoD 的小表弟。它是一个清单，列出了在团队可以在下一个冲刺中开始实施之前，需要对产品待办事项做些什么。您可以将就绪的定义视为产品负责人必须完成的“DoD”，以便开发团队在 Sprint 计划会议上接受这个故事。

请注意，DoR 不是 Scrum 指南的一部分——这是有充分理由的。DoR 不应用作 Sprint 计划的阶段门或推卸责任的方式！它应该是团队在待办事项细化期间需要做什么的指南。如果您对 DoR 不是 Scrum 指南的一部分的原因感兴趣，请参阅为什么Scrum 指南中没有描述就绪的定义？通过@Barryovereem为更深入的了解。

大多数团队从一个空的 DoR 开始，然后根据需要添加。再说一遍：不要在这里提出很多要点来麻痹自己！最好从简单开始，然后根据需要添加到 DoR。

典型的 DoR 可能如下例所示：

PO 和 Dev Team 需要至少讨论一次这个故事
故事必须有明确的商业价值
需要估计努力
故事必须足够分解以适应一个冲刺
故事至少需要一个接受标准

老实说，您可能不需要写下来。当您在待办事项细化会话中谈论新用户故事时，您将直观地将故事推向“为冲刺做好准备”。

如果你想为你的多尔是个好原则，考虑INVEST模式：用户故事应该是我ndependent，ñ egotiable，V aluable，ē stimable，小号商场和牛逼estable。阅读@jeremyjarrell 撰写的关于如何投资您的用户故事的精彩文章。这是一个简短的描述：

独立的。用户故事应该独立于其他故事。如果您真的编写“用户故事”而不是传统的工作项或任务，那么最终会自动大大减少依赖项。有时，您可能仍然有依赖项——在这种情况下，只需记下依赖项即可。
面议。用户故事应该描述什么客户需要，而不是如何开发人员应该实现它。开发团队应该始终能够提出替代解决方案/实施方案来为客户提供业务价值。
有价值的。必须说明商业价值。这通常是用户故事格式的“……所以……”部分：“作为一个角色，我想要功能，以便我获得业务价值”。
估计。开发团队必须能够粗略估计用户故事的工作量。这通常意味着开发人员会向产品负责人提出一些澄清问题，并对如何实施提出一个粗略的想法。
小。它必须足够小才能在 sprint 中完成。如果估计比冲刺还大，继续拆分用户故事，直到你有小故事。
可测试。您需要能够测试用户故事是否已完成并实现其目的。这通常意味着您需要一套明确的验收标准，并将其转化为测试用例。