定义：
DoD 全称 Definition of Done， 是我们敏捷中常说的“完成的定义”。
在我们Scrum中，需要预先定义DoD，我们项目中DoD条款有:
1，所有完成的用户故事得到PO的验证
2，所有新增代码得到人工评审
3，所有完成的用户故事都有对应的测试用例
分类：
不同类型的DoD关注的宏观层次不同。
1，故事DoD：每个故事完成了哪些事情才算这个故事彻底开发完成，达到可交付的标准了？
2，迭代DoD：每个迭代的所有故事做到什么程度才算完成，完成哪些事情了，本次迭代的输出才是可交付的？
3，发布DoD：每次交付完成了哪些事情，才是可以交付的？
我们的项目每两周有一个DoD，包含以上3项。
作用：
1，明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致；
2，承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性；
3， 避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代；
4，作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划；
5，聚焦目标，减少不必要的活动，定义完成任务的最小活动集合；
6，在做计划时判断是否有遗漏的活动；
7，在验收时检查是否有遗漏的活动，比如作为sprint review的检查单的一部分
案例：
以下是我们项目中完成一个用户故事需要做到的标准。
1，开发人员所有的代码都通过了单元测试，语句覆盖率达到了100%；
2，完成了集成，并通过了自动化测试；
3，非功能性需求已经测试通过了；
4，PO对照故事的验收标准认可了完成的功能；
发布：
我们项目中每一次发布需要做到下面的要求。
1，满足了迭代DoD；
2，产品通过了全量回归测试；
3，已经通过了用户体验测试；
4，交付给用户的文档都经过了评审或测试；
5，在客户预期的环境中做了确认；
6，未能按期交付的故事得到了PO的认可；
7，产品已经自动部署到生产环境中；
检查单：
下面是我们项目的中的DoD检查单。
