DoD（The definition of done:DoD）完成的定义、完成的标准或完成的准则是敏捷开发方法中的一个重要概念，一个重要实践。本文对DoD如何理解、如何定义DoD及其作用给了简明扼要的论述，供各位实践者参考。
01
DoD的定义
可以从不同的维度理解DoD的定义：
1）DoD就是完成准则，完成就是不需要再做其他任何事情，可以直接交付了。DoD就是100%完成，而不是99%，95%，90%的完成。
2）DoD定义了达成目标的最小活动集，不增值的、无用的活动不在此清单上。
3）DoD就是产品的质量活动的标准，代表了团队为保证交付质量，对质量投入的共识与承诺。DoD与用户故事的验收标准不同。每个用户故事都有自己的验收标准，故事的验收标准是客户可以感知的、对产品的外部质量的要求，DoD是对产品内部质量投入的要求。
图1: DoD与用户故事的验收标准的关系
此概念也可以应用到非敏捷的开发模式中，比如针对每个岗位定义每个任务的DoD。
02
DoD的分类
不同类型的DoD关注的宏观层次不同。
1）故事DoD：每个故事完成了哪些事情才算这个故事彻底开发完成，达到可交付的标准了？
2）迭代DoD：每个迭代的所有故事做到什么程度才算完成，完成哪些事情了，本次迭代的输出才是可交付的？
3）发布DoD：每次交付完成了哪些事情，才是可以交付的？
每日DoD或每周DoD，每个团队可以根据自己的实际情况来裁剪，可有可无。
03
DoD的作用
1） 明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致；
2） 承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性；
3） 避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代；
4） 作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划；
5） 聚焦目标，减少不必要的活动，定义完成任务的最小活动集合；
6） 在做计划时判断是否有遗漏的活动；
7） 在验收时检查是否有遗漏的活动，比如作为sprint review的检查单的一部分；
04
如何定义DoD
1）团队成员协商一致，并确保所有人都可视！
2）不要让领导定义DoD！
3）在需求梳理会议或迭代策划会议上定义DoD!
4）不同的活动有不同的完成定义，要区别对待。
5）随着迭代的进展，逐步完善DoD。
6）在迭代回顾会议上是讨论对DoD的优化修改。
7）DoD越弱，欠债越多，后期风险越大。如图2所示。
8）质量投入的活动要包含在DoD定义中，如各种测试、评审、重构活动等。
图2：不完善的DoD会导致交付时的返工
05
DoD的案例
用户故事的DoD案例：
① 所有的代码都通过了单元测试，语句覆盖率达到了100%；
② 所有的代码要么做了结对编程，要么做了代码评审；
③ 通过了工具的静态检查；
④ 所有的代码都入库了；
⑤ 完成了集成，并通过了自动化测试；
⑥ 非功能性需求已经测试通过了；
⑦ PO对照故事的验收标准，认可完成的功能；
⑧ 对应的联机帮助已经完成；
迭代DoD案例：
① 所有完成的用户故事都满足了其验收标准；
② 所有完成的用户故事都满足了用户故事的DoD;
③ PO对集成后的功能做了确认；
④ 自动部署的脚本经过了测试；
⑤ 所有已知的缺陷都修复了，自动回归测试没有发现缺陷；
⑥ 通过了性能测试；
发布DoD案例：
① 满足了迭代DoD；
② 产品通过了全量回归测试；
③ 已经通过了用户体验测试；
④ 交付给用户的文档都经过了评审或测试；
⑤ 在客户预期的环境中做了确认；
⑥ 未能按期交付的故事得到了PO的认可；
⑦ 产品已经自动部署到生产环境中；
⑧ 对运维、市场人员的培训已经完成；
每个团队可以根据自己项目组的实际情况定义自己的DoD，以上的案例仅供参考
