要言不繁的DoD指南

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

 

1 DoD的定义

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

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

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

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

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

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

2 DoD的分类

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

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

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

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

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

3 DoD的作用

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

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

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

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

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

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

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

4 如何定义DoD

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

       2）不要让领导定义DoD！

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

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

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

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

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

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

 

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

5 DoD的案例

用户故事的DoD案例：

• 所有的代码都通过了单元测试，语句覆盖率达到了100%；
• 所有的代码要么做了结对编程，要么做了代码评审；
• 通过了工具的静态检查；
• 所有的代码都入库了；
• 完成了集成，并通过了自动化测试；
• 非功能性需求已经测试通过了；
• PO对照故事的验收标准认可了完成的功能；
• 对应的联机帮助已经完成；

 

迭代DoD案例：

• 所有完成的用户故事都满足了其验收标准；
• 所有完成的用户故事都满足了用户故事的DoD;
• PO对集成后的功能做了确认；
• 自动部署的脚本经过了测试；
• 所有已知的缺陷都修复了，自动回归测试没有发现缺陷；
• 通过了性能测试；

 

发布DoD案例：

• 满足了迭代DoD；
• 产品通过了全量回归测试；
• 已经通过了用户体验测试；
• 交付给用户的文档都经过了评审或测试；
• 在客户预期的环境中做了确认；
• 未能按期交付的故事得到了PO的认可；
• 产品已经自动部署到生产环境中；
• 对运维、市场人员的培训已经完成；

     每个团队可以根据自己项目组的实际情况定义自己的DoD，以上的案例仅供参考