在之前文章中我们提到了，每个Sprint都要验收才能算结束，而验收标准遵循DoD原则。那么究竟什么是DoD原则呢？我们将在本文为您详细讲解。

一、什么是DoD？

当你有两个或更多的人参与同一个事情的时候，我们的“团队”就产生了，这时我们最重要的事情，就是要设定和统一团队的期望值；在本文中，这就是“完成标准”。

一个迭代做完后，团队要进行验收，来决定本个迭代是否完成。

但每个团队对于是否完成无法达成统一，有的认为编码完成，就表示任务完成了；有的认为还需要简单自测一下，确保功能可以正常使用；还有的认为需要把自动化用例写完并测试通过才算完成。

为了避免这个问题，在敏捷软件开发中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义。

首先要知道：所有的DoD都不是一成不变的，在随着时间的推移、经验的积累、成员的变更、项目的变更，我们的DoD也会有很大的不同，所以我们也需要定期地检查和改进。

二、DoD的分类

有了上面的思想准备，我们再来看下面的DoD定义，就会觉得并没有那么难了。

1. 迭代DoD

最典型的是迭代DoD，这也是最初DoD应用的地方。

常见的一些规则有：

1. 所有代码通过静态检测，严重问题都已修改，静态分析的规则参见……
2. 所有新增代码得到人工评审；
3. 所有完成的用户故事都有对应的测试用例；
4. 测试用例都已执行；
5. 所有完成的用户故事得到Product Owner的验证。

2. 发布DoD

对于发布，一般就有更加严格的要求，发布DoD的典型条款有：

1. 完成发布规划所要求的重点需求；
2. 至少通过一次全量回归测试；
3. 修复所有等级为1、2的缺陷；3、4级缺陷不超过20个。

3. 版本DoD

版本DoD就是针对每个版本上线前后的一些规则，比如：

1. 产品文档已全部更新；
2. 代码已部署到产品服务器上；
3. 运维在验收测试环境上冒烟通过；
4. 原始需求提交人对功能已经验收通过；
5. 对运维、市场、客服的新功能培训已完成。

4. 每日DoD

其他典型的DoD有每日DoD，典型条款有：搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。

1. 下班前必须检入当天编写的代码，check in的backlog要填写清晰；
2. 当天的代码必须在当天或者第2天邀请同伴进行代码评审；
3. 检入的功能代码必须要有对应的单元测试（严格采用TDD）；
4. 每天晚上触发静态代码检查、自动化回归测试；
5. 当天持续集成、构建环境中的问题，请当天解决。

5. 用户故事DoD

还有针对用户故事（或者用例）的DoD，比如：

1. 用户故事最终的描述符合INVEST
2. 用户故事得到测试用例的对应覆盖
3. 用户故事得到对应的自动化测试用例
4. 用户故事得到PO试用并初步认可

当测试集比较大的时候，无法在1天之内完成测试，可以开展每周全量回归自动化测试，这样就有每周DoD，典型条款有：

1. 上上周发现的缺陷是否解决；
2. 上周新增功能的自动化测试是否加入到每周测试集。

Tips：DoD 必须是团队在项目启动时共同讨论出来的，团队愿意共同遵守的原则，一旦确定，团队就应共同遵守。

三、DoD的实用价值

1. DoD是对软件有价值的活动的清单

DoD是一个简单的清单，包含了一系列的活动。

例如：编码、加注释、单元测试、集成测试、发行声明、设计文档等等，所有这些活动都能够给产品带来实际的价值。使用DoD，可以让团队集中在那些必须完成的事情上，同时让那些无用的，仅仅使软件开发变得复杂的活动被消除掉。

3. DoD是团队成员的主要状态参考依据

对于迭代最简单形式的汇报就只有一句话：“这个feature完成了”。

毕竟，一个feature或者一个product Backlog Item的状态只有两种：完成或未完成 。

DoD是对“feature完成了”这句话的最佳补充。使用DoD作为参考标准，团队成员可以迅速有效地让其他团队成员或PO了解状态。

3. DoD不是不变的

DoD随着时间会改变。

组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到sprint或者feature的DoD中来。

4. DoD是一个可以被审视的列表

feature/用户故事在sprint plan meeting和sprint中都可以被拆分成task。

DoD可以用来衡量是不是所有的主要工作都被计划在内的（剩余的时间），而且，在一个feature或者sprint结束的时候，DoD可以用来考查是不是所有的必须的增值活动都已经完成了。

必须引起注意的是：DoD本身也是存在缺陷的。并不是所有的增值活动都可以应用到每一个feature上面，而DoD本身是一个大而全的检查事项的审核制度。团队需要基于一个feature来审视每项增值活动是否适用于这个feature。

比如说：追求用户体验对于web服务这样的feature来说可以加分，但是对于其他的一些feature来说就是不必要的了。

最后需要注意的是：对于验收标准，并不一定是由Product owner决定，要根据显示情况而定，每个团队都要根据自己的情况选择合适的DoD原则。

#专栏作家#

袁林，人人都是产品经理专栏作家。分享SaaS运营和企业管理／协作／办公的相关知识

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议