SCRUM 实践之 DOD

你的团队是不是经常会对于每次迭代是否完成，无法达成一致意见：有的认为我编码完成，就表示我的任务完成了；有的认为还需要简单自测一下，确保功能能跑通；还有的认为需要把自动化用例写完并测试通过。

为了解决这个常见问题，团队需要对完成的定义、完成的标准或完成的准则做统一的要求，这就有了 DoD 的诞生。这也逐渐变成了敏捷开发方法中的一个重要实践。

scrum-guide-dod1.png

DoD 定义

DoD 全称 Definition of Done， 是我们敏捷中常说的“完成的定义”
这里需要注意几点：
1 DoD 就是完成准则，完成就是不需要再做其他任何事情，可以直接交付了。DoD就是100%完成，而不是99%，95%，90%的完成。
2 DoD定义了达成目标的最小活动集，不增值的、无用的活动不在此清单上。
3 DoD就是产品的质量活动的标准，代表了团队为保证交付质量，对质量投入的共识与承诺。

DoD 作用

明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致。
承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性。
避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代。
作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划。
聚焦目标，减少不必要的活动，定义完成任务的最小活动集合 。
在做计划时判断是否有遗漏的活动。
在验收时检查是否有遗漏的活动，比如作为 Sprint Review的检查单的一部分。

Dod1-836x461.jpg

如何定义

团队成员协商一致输出，并确保所有人都可视。不要让领导定义DoD。
不同的活动有不同的完成定义，要区别对待。
随着迭代的进展，逐步完善DoD。保证随着时间会改变。组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到 Sprint 或者 Feature 的DoD中来。
在迭代回顾会议上是讨论对DoD的优化修改。
DoD越弱，欠债越多，后期风险越大。
质量投入的活动要包含在DoD定义中，如各种测试、评审、重构活动等。

不同活动DoD

在敏捷软件开发中，存在多级的不同的完成定义。一上来不需要全部覆盖，可以共同约定适合团队的 DoD,然后在过程中过不断完善和修改。

30e9f0e0-9f42-4429-911f-9c86150d49f0.jpg

迭代DoD
常见的迭代DoD条款有:
1 所有完成的用户故事得到PO的验证。
2 所有代码得到静态分析，纠正最高级别的不符合项。
3 所有新增代码得到人工评审。
4 所有完成的用户故事都有对应的测试用例。
5 测试用例都已执行。

发布DoD

1 完成发布规划所要求的重点内容。
2 通过发布的全量测试，回归测试范围是全范围，回归比率不低于50%。
3 修复所有等级为1、2、3的缺陷，4级及4级以下缺陷不超过200个。1、2级缺陷必须修复，3级缺陷经过缺陷发布审批后可以发布。
4 至少通过一次全量回归测试。

区别：
由于发布需要达到比迭代更高的要求，所以一般很难强制规定发布测试所需要的时间长度，也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第1要务，如果到了原计划测试结束的时间，仍然留有妨碍发布的缺陷的话，应当修复后才能发布。
而迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处，在这样的安排下，回归覆盖率就应当是一个变量，用于观察，而不应当是一个要求指标。

版本DoD

版本DoD就是针对每个版本上线前后的一些规则，比如：
1 产品文档已全部更新
2 代码已部署到产品服务器上
3 运维在验收测试环境上冒烟通过
4 原始需求提交人对功能已经验收通过
5 对运维、市场、客服的新功能培训已完成

每日DoD

1 搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
2 下班前必须检入当天书写的代码，check in的backlog要填写清晰。
3 当天的代码必须在当天或者第2天邀请同伴进行代码评审。
4 搭建持续集成环境，当天上下午必须至少各检入代码一次（这与第1条可能冲突）。
5 采用TDD，凡是检入的功能代码必须要有对应的单元测试（严格采用TDD）。
6 每天晚上触发静态代码检查、自动化回归测试。
7 当天持续集成、构建环境中的问题，请当天解决。

用户故事DoD

1 用户故事最终的描述符合INVEST
2 用户故事得到测试用例的对应覆盖
3 用户故事得到对应的自动化测试用例
4 用户故事得到用户代表试用并初步认可

[image:5434D691-9A15-4D2D-9AB8-11431D82E8D0-82946-0002A9EE64E13EB9/640.png]
每周DoD

1 上上周发现的缺陷是否解决。
2 上周新增功能的自动化测试是否加入到每周测试集。

AC vs DoD

definition-of-ready.gif

最后记得，不要将 AC(Accept criteria )与 DoD 混淆了，它们都是敏捷开发中实践，不可相互取代。AC 是针对每个需求定义的。DoD是针对所有需求，任务，迭代，交付定义的。
满足了AC确保我们做了正确的事情，AC是站在最终用户的角度定义的，定义了产品的外部质量。
满足了DoD确保我们采用了正确的方法做事，DoD是站在利益相关者的角度定义，未必一定是最终用户的角度，它定义了产品的内部质量，保证了产品的长久的适应性。
最终用户验收时只关注了AC，而没有关注DoD。

微信公众号：Cindynan77