要言不繁的DoD指南——敏捷开发

        DoD（The definition of done:DoD）完成的定义、完成的标准或完成的准则是敏捷开发方法中的一个重要概念，一个重要实践。本文对DoD如何理解、如何定义DoD及其作用给了简明扼要的论述，供各位实践者参考。

可以从不同的维度理解DoD的定义：

1）DoD就是完成准则，完成就是不需要再做其他任何事情，可以直接交付了。DoD就是100%完成，而不是99%，95%，90%的完成。

2）DoD定义了达成目标的最小活动集，不增值的、无用的活动不在此清单上。

3）DoD就是产品的质量活动的标准，代表了团队为保证交付质量，对质量投入的共识与承诺。DoD与用户故事的验收标准不同。每个用户故事都有自己的验收标准，故事的验收标准是客户可以感知的、对产品的外部质量的要求，DoD是对产品内部质量投入的要求。

图1: DoD与用户故事的验收标准的关系

此概念也可以应用到非敏捷的开发模式中，比如针对每个岗位定义每个任务的DoD。

不同类型的DoD关注的宏观层次不同。

1）故事DoD：每个故事完成了哪些事情才算这个故事开发完成，达到可交付的标准了？

2）迭代DoD：每个迭代的所有故事做到什么程度才算完成，完成哪些事情了，本次迭代的输出才是可交付的？

3）发布DoD：每次交付完成了哪些事情，才是可以交付的？

每日DoD或每周DoD，每个团队可以根据自己的实际情况来裁剪，可有可无。

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

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

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

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

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

6） 在做计划时判断是否有遗漏的活动；

7） 在验收时检查是否有遗漏的活动，比如作为sprint review的检查单的一部分；

1）团队成员协商一致，并确保所有人都可视！

2）不要让领导定义DoD！

3）在需求梳理会议或迭代策划会议上定义DoD!

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

5）随着迭代的进展，逐步完善DoD。

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

7）DoD越弱，欠债越多，后期风险越大。如图2所示。

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

 图2：不完善的DoD会导致交付时的返工