Scrum 实践之 DoD

Posted 2021-04-25 且把金针度与人

你的团队是不是经常会对于每次迭代是否完成，无法达成一致意见：

有的认为我编码完成，就表示我的任务完成了；

有的认为还需要简单自测一下，确保功能能跑通；

还有的认为需要把自动化用例写完并测试通过。

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

DoD 定义

DoD 全称 Definition of Done， 是我们敏捷中常说的“完成的定义”

这里需要注意几点：

1. DoD 就是完成准则，完成就是不需要再做其他任何事情，可以直接交付了。 DoD就是100%完成，而不是99%，95%，90%的完成。
2. DoD定义了达成目标的最小活动集，不增值的、无用的活动不在此清单上。
3. DoD就是产品的质量活动的标准，代表了团队为保证交付质量，对质量投入的共识与承诺。

DoD 作用

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

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

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

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

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

在做计划时判断是否有遗漏的活动。

在验收时检查是否有遗漏的活动，比如作为 Sprint Review的检查单的一部分。

如何定义

团队成员协商一致输出，并确保所有人都可视。不要让领导定义DoD。

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

随着迭代的进展，逐步完善DoD。保证随着时间会改变。组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到 Sprint 或者 Feature 的DoD中来。

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

DoD越弱，欠债越多，后期风险越大。

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

不同活动DoD

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

迭代DoD

常见的迭代DoD条款有:

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

发布DoD

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

区别：

由于发布需要达到比迭代更高的要求，所以一般很难强制规定发布测试所需要的时间长度，也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上，因为高质量发布是第一要务，如果到了原计划测试结束的时间，仍然留有妨碍发布的缺陷的话，应当修复后才能发布。

而迭代成果一般是为了内部或者可控范围内的展示，相对发布而言，要求较低，所以适用时间箱方法，当然迭代本身就是时间箱，迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处，在这样的安排下，回归覆盖率就应当是一个变量，用于观察，而不应当是一个要求指标。

版本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. 用户故事得到用户代表试用并初步认可

每周DoD

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

AC vs DoD

最后记得，不要将 AC(Accept criteria )与 DoD 混淆了，它们都是敏捷开发中实践，不可相互取代。AC 是针对每个需求定义的。DoD是针对所有需求，任务，迭代，交付定义的。

每个用户故事都有自己的验收标准，故事的验收标准是客户可以感知的、对产品的外部质量的要求，DoD是对产品内部质量投入的要求。

满足了AC确保我们做了正确的事情，AC是站在最终用户的角度定义的，定义了产品的外部质量。

满足了DoD确保我们采用了正确的方法做事，DoD是站在利益相关者的角度定义，未必一定是最终用户的角度，它定义了产品的内部质量，保证了产品的长久的适应性。

最终用户验收时只关注了AC，而没有关注DoD。

END

更多原创推荐阅读：