敏捷实践经验分享，企业如何在敏捷开发中实施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
。