在敏捷开发中，让所有成员保持目标统一、步调和节奏一致非常重要，但是在团队协作中，认知偏差却在所难免。需求在不同环节中流转，是否存在某种途径能保证所有成员的理解一致，将偏差最小化？

今天跟大家介绍敏捷开发中共识建立的两大神器：DoR 和 DoD。 ​

DoR = Definition of Ready，即对「准备就绪」的定义，是敏捷开发中把控研发质量的第一道门。DoR 关注研发起点的质量，定义了用户故事可以被研发团队接受并进入开发阶段的最小要求，是需求准入的标准。

DoR 的价值在于，它规范了开发对象的质量底线，能够有效防止开发侧的资源、时间或精力的浪费：如果一个待开发的用户故事不符合 DoR 要求，那么研发团队有权将其退回，不在最近的迭代中开发它。

引用 Brian Will 的观点：“用户故事「准备就绪」非常重要——将不完整或未优化的用户故事放入冲刺中会出现问题，因为它会遵循「Garbage In, Garbage Out」原则：如果开发人员处理的是不够详细或定义不充分的用户故事，他们就不会产生高质量的代码。”

Brian 认为一个「准备好的 Ready」待办事项应该是清晰、可行和可测试的。

DoR 关注待开发的用户故事，而 DoD 则更多地聚焦待发布的价值增量。

DoD = Definition of Done，译为完成定义，是用于把控研发质量的第二道门。它是需求准出的标准，通常呈现为一份清单形式的简短文档，定义了用户故事被视为「完成」所需要达到的最低验收条件，常由产品负责人 PO 和开发团队共同协商决定。

DoD 通过建立通用的标准，确保团队每位成员对价值增量的完成具有相同的理解，避免了团队内外潜在的认知偏差；同时，清单内容还能提升团队的信息透明度，辅助工作点数的评估和计划制定，推进故事的完成。

在敏捷开发中，「完成」意味着「无需进行更多工作，可直接交付」，因此 DoD 内容至少应涵盖设计、编码、集成、测试和记录等全套产品开发流程。 Brian Will 指出 DoD 通常会说明以下内容：

Scrum 联盟按照需求的不同层次，将 DoD 分成三种级别：用户故事DoD、冲刺DoD 和发布DoD。

用户故事DoD，也称功能/需求DoD。它声明了故事可交付的底线，即用户故事应完成哪些事情才可以被判定为开发完成，达到可交付的标准。用户故事DoD 的制定可以从以下两方面考虑：

冲刺DoD，或迭代DoD，定义了每个 Sprint 需要完成哪些事情，其输出才是可交付的。通常包含以下内容：

发布DoD 定义了增量交付的最低要求，可以参考以下内容辅助制定。

此外，在子任务层面，敏捷团队也可以通过开发任务DoD 更好地规范任务完成，比如：

参考资料

阅读更多「LigaAI」的趣味分享与敏捷实践， 请关注 LigaAI@CSDN，持续接收更多干货分享~ 进一步了解我们的产品，请访问 LigaAI -新一代智能研发协作平台