一、什么是DoD？

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

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

为了避免这个问题，在敏捷软件开发中，常用**Definition of Done“完成的定义”**来表示工作是否已完成，不同的活动有不同的完成定义。首先要知道，所有的DoD都不是一成不变的，在随着时间的推移、经验的积累、成员的变更、项目的变更，我们的DoD也会有很大的不同，所以，我们也需要定期地检查和改进。

二、 DoD的分类

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

一、迭代DoD

最典型的是迭代DoD，这也是最初DoD应用的地方。常见的一些规则有：

1.  所有代码通过静态检测，严重问题都已修改，静态分析的规则参见…

2.  所有新增代码得到人工评审

3.  所有完成的用户故事都有对应的测试用例

4.  测试用例都已执行

5.  所有完成的用户故事得到Product Owner的验证

二、发布DoD

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

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

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

3. 修复所有等级为1、2的缺陷，3、4级缺陷不超过20个

三、版本DoD

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

1.  产品文档已全部更新

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

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

4.  原始需求提交人对功能已经验收通过

5.  对运维、市场、客服的新功能培训已完成

四、每日DoD

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

1.  下班前必须检入当天编写的代码，check in的backlog要填写清晰

2.  当天的代码必须在当天或者第2天邀请同伴进行代码评审

3.  检入的功能代码必须要有对应的单元测试（严格采用TDD）

4.  每天晚上触发静态代码检查、自动化回归测试

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

五、用户故事DoD

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

1.  用户故事最终的描述符合INVEST

2.  用户故事得到测试用例的对应覆盖

3.  用户故事得到对应的自动化测试用例

4.  用户故事得到PO试用并初步认可

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

1.  上上周发现的缺陷是否解决

2.  上周新增功能的自动化测试是否加入到每周测试集。

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

三、DoD的实用价值

一、DoD是对软件有价值的活动的清单

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