首先我们需要了解什么是DOD，

DOD的定义

DoD 全称 Definition of Done， 是我们敏捷中常说的“完成的定义”

DOD的作用

其实我们需要了解DOD的作用是什么呢？

明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致。

承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性。

避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代。

作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划。

聚焦目标，减少不必要的活动，定义完成任务的最小活动集合 。

在做计划时判断是否有遗漏的活动。

在验收时检查是否有遗漏的活动，比如作为 Sprint Review的检查单的一部分。

DOD的定义

团队成员协商一致输出，并确保所有人都可视。不要让领导定义DoD。

不同的活动有不同的完成定义，要区别对待。

随着迭代的进展，逐步完善DoD。保证随着时间会改变。组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到 Sprint 或者 Feature 的DoD中来。

在迭代回顾会议上是讨论对DoD的优化修改。

DoD越弱，欠债越多，后期风险越大。

质量投入的活动要包含在DoD定义中，如各种测试、评审、重构活动等。

不同活动DoD

在敏捷软件开发中，存在多级的不同的完成定义。一上来不需要全部覆盖，可以共同约定适合团队的 DoD,然后在过程中过不断完善和修改。

迭代DoD

所有完成的用户故事得到PO的验证。

所有代码得到静态分析，纠正最高级别的不符合项。

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

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

测试用例都已执行。

发布DoD

完成发布规划所要求的重点内容。

通过发布的全量测试，回归测试范围是全范围，回归比率不低于50%。

修复所有等级为1、2、3的缺陷，4级及4级以下缺陷不超过200个。1、2级缺陷必须修复，3级缺陷经过缺陷发布审批后可以发布。

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

区别：

由于发布需要达到比迭代更高的要求，所以一般很难强制规定发布测试所需要的时间长度，也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第一要务，如果到了原计划测试结束的时间，仍然留有妨碍发布的缺陷的话，应当修复后才能发布。

而迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处，在这样的安排下，回归覆盖率就应当是一个变量，用于观察，而不应当是一个要求指标。

版本DoD

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

产品文档已全部更新

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

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

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

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

每日DoD

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

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

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

搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）。

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

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

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

用户故事DoD

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

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

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

用户故事得到用户代表试用并初步认可

每周DoD

上上周发现的缺陷是否解决。

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

下面是我们Code DOD的sample：