首先我们需要了解什么是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：