【敏捷开发】一文讲透敏捷管理中的DoR、DoD与AC

在传统项目管理中，产品的质量通常是通过质量管理中的管理质量、控制质量来完成。在敏捷方法中，很多人关注的是敏捷的快速交付，认为快了，质量就会有所下降，bug就会比传统瀑布模式更多了。事实是这样吗？在敏捷方法中，如何确保产品的质量？本文详细解答敏捷中的质量控制方法：DoR、DoD与AC

dor是指需求是否可以开发，dod是开发过程中是否完成，dor是dod的前置条件

一、需求侧：DoR

案例：

某企业在敏捷转型过程时，团队商定的迭代周期是2周。按计划，在周一召开的Sprint Planning会议大概需要4小时。但会议开始时，PO并未完全梳理好待办事项PB的优先级，而且由于有一些复杂的业务流程，PO输出纯靠一张嘴。没有低保真的原型图，没有流程图…导致后续在sprint执行过程中，团队不得不再次开会，确定一些细节以及AC（验收标准）。团队怨声载道，吐槽有太多的会议影响大家的开发……

这里的Sprint Planning 是指迭代规划会议。

我当时作为外部教练的角色，给团队引入了DoR的机制，开始引导团队一起来制定DoR的规则，并在每个回顾的时候不断优化，经过几个迭代后，团队的SP计划会基本上都可以按期进行，且只要召开一次即可达到高质量的交付。

由于没有准备好图之类的东西，导致开会讨论时没有重点，超时

DoR是什么？

DoR = Definition of Ready，通过DoR的Story可以进入迭代开发

DoR中的R表示Story准备就绪，是Story“合格”的验收标准，即Story应该长什么样，通过DoR的Story可以从Product Backlog进入Sprint Backlog准备开发，属于Sprint开始前的需求确认阶段。是指能够被研发团队接受的代办事项列表。

具体来讲DOR可以是否能够被研发团队接受的代办事项列表，是否已经可以作为开发候选所需要达到的最小要求。DOR是为在每次迭代开发前针对需求梳理或需求输入所设置的质量验收标准。

如何建立DoR的标准？

DoR不是PO自己梳理，而是团队成员一起商议的结果。下面给大家复盘一下我当时如何引导团队建立DoR的做法：

• 第1步：发起会议，引导为什么要DoR

组织PO、研发团队，解决项目中目前的问题，比如：当前的一些需求反复沟通、迭代计划会时间严重超时、会议需要反复进行、PO和研发需求理解偏差等现象。让大家就这些现象挖掘根本原因。根本原因在于我们对需求的理解不一致。怎么能够减少不一致，尽快就需求达成共识？

• 第2步：引导大家认知到，我们的需求需要有一个标准

从为什么出发，我们为什么需要有DoR标准，以及DoR是什么。它是为了解决我们上面提到的问题。每个人的认知不同，导致对需求的理解会不一致。怎么提高达成一致的效率？我们需要对需求有一个基本的标准，帮助大家尽快达成一致。

• 第3步：引导成员输出初始的DoR

采用头脑风暴的方式，让大家写出需求要做到什么样，我们才可以更好的开发。采用便签输出到白板上，并对内容进行分类。对于描述不清的或不够明确的，可以让写这条规则的同学澄清明确一下。然后大家进行投票，选出符合团队具体情况的标准。这就形成了初始的DoR

• 第4步：重申价值观，持续优化

重申敏捷价值观，我们一直在寻找更好的软件开发方法，所以1.0版本的DoR不是固定不变的，在需要的时候，我们随时都可以更新DoR

DoR样例

1、需求

产品需求文档（PRD）及界面原型已经准备就绪，并提前同步给团队全员

产品待完成项或用户故事得到澄清

已经在需求梳理会上识别高优先级需求，并进行合理拆分

验收标准按场景、业务规则、成功路径或失败路径等测试要点编写

2、交互

低保真线框图已完成

业务场景、业务流程逻辑清晰

UI/X已经经过评审

3、架构

所需的技术调研、概念验证等已经spike完成，针对复杂用户需求已经提前给出概要设计方案

所需的架构或框架的代码已完成

二、研发侧：DoD

在日常生活中，我们定义一件事情已经完成，那到底做到什么程度叫完成呢？比如家长问小朋友，作业做完了吗？小朋友说做完了。家长把作业拿过来一看，这怎么能叫做完呢？这么多错的，也没订正，不行，作业要重做……

那么，我们在软件开发活动中，什么叫做完成呢？我相信大家都曾遇到过这样的情况：

研发提交了一个完成的功能。你打开后，直接报错。然后就问研发：“你这不对呀，有bug”，研发可能马上会回复你一句：“不可能，我刚还运行了一下呢！”

为什么会出现这样的问题？是因为没定义好完成的标准。对于研发来说，可能是在他电脑上（开发环境）是可以运行的。但是在你的电脑上（实际环境）却运行不起来了。

其实这种问题，可以通过定义DoD来预防这种问题。

DoD是什么？

DoD = Definition of Done

DoD也叫完成标准，通过DoD的Story可以交付使用，包括AC、测试、bug修复、部署等，所以DoD标准的目标只有一个：是否可以交付使用。当某个需求被描述为“完成”的时候，所有人都要理解“完成”意味着什么。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。

如何建立DoD的标准？

同DoR一样，DoD也是和团队一起共创出来的，作为SM，如何引导团队建立DoD？

第1步：明确会议目标，确定会议时间盒（一般半小时左右）

参会人包含PO、研发，邀请大家一起来建立团队的DoD。

第2步：重申敏捷原则：可工作的软件是首要的进度度量（敏捷12条原则）

PO和研发需要就本原则达成共识，只有都认同敏捷原则，才能建立DoD。否则PO如果以进度为衡量指标，研发自然会追求进度而忽略了产品质量。

第3步：引导大家建立DoD标准

DoD的建立在实践过程中，通常会遇到的问题是团队不知道怎么写，不知道从哪些方面来写。这时候作为敏捷教练，就需要充分发挥出引导能力。我通常会从如下2大类来引导大家，比如：

a、按照流转状态来定义：下游为上游制定准入条件，比如需求->开发，由开发来写准入开发的DoD，开发->测试，由测试来写准入测试的DoD，测试->验收，验收->上线。都可以按照这个上下游规则来写出准入准出标准。

b、按照分层来定义：比如大家一起思考：

我们确认迭代完成的标准是什么？代码、测试、bug等，要达到什么标准？

我们确认发布完成的标准是什么？部署、运维、相关文档、培训等要达到什么标准？

我们确认每天完成的标准是什么？编码、测试、集成有没有要达到什么标准？

第4步：持续优化

DoD的建立也是逐步优化的过程，在sprint执行过程中，遇到的问题，记录下来，在回顾会上共创解决方案，并针对DoD做出修正或调整。

DoD样例

每日DoD

注意代码缩进规范，代码需要有注释，提交代码前完成自测

每天下班前必须签入（check in）当天编写的代码

当天的代码必须在当天或者第2天邀请同伴进行code review

当天持续集成、构建环境中的问题，当天解决

每日修复前一日构建和测试发现的bug

静态代码扫描出的错误已经修复，新增代码扫描出的警告已经修复

迭代完成DoD

所有代码通过静态检测，P0级bug都已修正

代码已合并团队最新代码并提交至主干

所有完成的用户故事都有对应的测试用例并得到执行

PO已验收每一个完成的用户故事

集成环境中，主流程端到端的回归测试通过，无功能回退问题

发布DoD

完成发布规划所要求的重点需求

至少通过一次全量回归测试

产品文档已全部更新

代码已部署到产品服务器上

P0、P1级缺陷全部修复，P2、P3级缺陷不超过10个

运维在验收测试环境上冒烟通过

应急回滚方案已明确且测试通过

三、用户侧：AC

在培训中，经常有同学混淆AC（Accept Criteria）和DoD的概念。它们是2个不同的概念。

AC是针对每个需求单独定义的，是一个专有的定义，每个需求的AC都不一样。

DoD是针对所有需求，任务，迭代，交付定义的，是一个通用性的定义。

比如：

需求1：干饭人中午要吃的好一些

验收标准AC：

1、一荤一素

2、米饭一碗

3、12:30-13:00吃完

需求2：早上吃好，营养丰富

验收标准AC：

1、两个包子1杯咖啡奶

2、9：00之前吃完

但对于以上2条需求，其完成标准DoD可能是：

1、所有的食材都要新鲜

2、所有的烹饪过程都要干净卫生

不知道你发现没有，AC是最终用户的角度定义的，定义了产品的外部质量。满足了AC确保我们做了正确的事情，

DoD确保我们采用了正确的方法做事，它定义了产品的内部质量，保证了产品的长久的适应性。

最终用户验收可能只关注了AC，而没有关注DoD。

但在开发时，不仅要关注AC还要关注DoD，否则可能留下技术债务，导致产品后续出现比较多的问题。

四、总结：

以上，详细介绍了DoR、DoD、AC的区别。在敏捷管理中，通过这些约束条件，进一步提升了产品的交付质量。

最后3句话总结三者的区别：

• DoR = Definition of Ready，通过DoR的Story可以进入迭代开发

• DoD = Definition of Done，通过DoD的Story可以交付使用

• AC= Accept Criteria，通过AC的Story可以获得客户验收

参考

一文讲透敏捷管理中的DoR、DoD与AC