敏捷实践经验分享，企业如何在敏捷开发中实施 DoD

一、什么是 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，可以让团队集中在那些必须完成的事情上，同时让那些无用的，仅仅使软件开发变得复杂的活动被消除掉。

二、DoD 是团队成员的主要状态参考依据

对于迭代最简单形式的汇报就只有一句话：“这个 feature 完成了”。毕竟，一个 feature 或者一个 product Backlog Item 的状态只有两种：完成或未完成 。DoD 是对“feature 完成了”这句话的最佳补充。使用 DoD 作为参考标准，团队成员可以迅速有效地让其他团队成员或 PO 了解状态。

三、DoD 不是不变的

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

四、DoD 是一个可以被审视的列表

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

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

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

最后需要注意的是，对于验收标准，并不一定是由 Product owner 决定，要根据显示情况而定，每个团队都要根据自己的情况选择合适的 DoD 原则。CORNERSTONE 提供了包括任务 /需求 /测试管理、迭代规划、缺陷追踪、报表统计、团队协作、WIKI、共享文件和日历等功能模块,20 人以下团队可免费使用,点击即可免费注册CORNERSTONE。