特性团队中的 DoD 右移实践

原创有赞技术有赞coder

作者：严梨炯 | 效能改进

背景

DoD（全称：Definition of Done）是特性团队内部，针对某个即将进入下一个迭代 backlog 的工作条目（一般指 story），约定其在该迭代结束时须完成到什么程度（比如：完成测试并等待演示，见图1）。尤其是当 story 颗粒度较大（须跨多个迭代）时，用该方式达成该团队共识，显得尤为重要。

众所周知，即便在敏捷模式中，研发过程依然由若干道工序所组成，故 DoD 的设计，完全可以基于工序来划定。笔者在敏捷转型的实践过程中，完成了特性团队从无到有创建 DoD 活动，并推动其逐渐右移，以帮助团队养成「聚焦目标」的习惯。

图1. story 在某个迭代的 DoD

问题现状

既然定义了 DoD，那么该 story 的未尽事宜工作就被称为 undone（故，story 生命周期 = DoD + undone）。参考图1，在该例子中，DoD 是到完成测试，那么 undone 就包含「演示、发布」工作。理想情况是，如果 DoD 是完成发布，那么就不存在 undone 工作了。

笔者对接的特性团队正处于敏捷转型阶段，整个迭代过程是粗放式的，其成员习惯于在迭代计划会上，从迭代 backlog 中一次性认领全部 story。与此同时，PO 看到 story 都被认领，也就放心地离开了。

照理说，迭代 backlog 中的 story 条目数，是根据团队的容量来规划的，目标是当迭代结束时，大部分 story 都能交付给用户使用。然后，真实的情况是，与只关注「有人认领」一样，团队同样也只关注 story「已经启动」，于是团队开始同时启动，并穿梭在多个 story 的架构设计和编码工作之间（见图2）。

图2. 有大量 story 同时被启动的看板

这导致了一个怪现象：在迭代（3周）的第一周，几乎没有 story 进入测试，但到了第三周，看板上却堆满了测试任务，而此时开发人员已从上述 story 的研发工作中离开，不再关注。

最后，只有少量 story 能如期交付，其中一部分还是上个迭代流入后，占用本迭代的时间和资源才得以完成的。所以本迭代可用于规划的团队容量因 undone 工作积压而缩减，可认领的 story 变少了，于是团队的适应性变差了。团队持续在做遗留任务，失去了对目标的冲刺感，PO 对团队信心不足，迭代活动变得形同虚设了。

读者可能会说，何不将计就计，把各道工序都错开一个迭代（或一周）？见图3。这种做法借鉴了精益流动的思路。但问题是，story 并不像工厂车间生产零件，其每道工序没有标准化的处理时长，研发各环节的波动性对团队迭代计划的冲击会很大（关于该话题，笔者将单独撰文分享）。

图3. 迭代按工序错开的效果图（注：该方法不可取）

引入 DoD，重获目标感

在这样的团队氛围下，任何的改进都可能是无效的。笔者认为，当务之急是重拾团队信心。于是，我们引入团队的唯一举措是，在迭代计划会上，为每个 story 设定 DoD。

图4. 带有 DoD 信息的 story 卡片

虽然在后续的认领环节，团队依然会一次性清空迭代 backlog，但团队成员会更明确自己名下 story 在本迭代的目标（此时不对 DoD 提出任何额外要求），而且我们会在迭代结束时，为大部分 story 达成 DoD 而庆祝，以此逐渐找回迭代工作的节奏感。

迭代完成率 = 达成 DoD 的 story 个数 ÷ 迭代规划的 story 个数 × 100%

图5. 试点团队的「迭代完成率」统计

DoD 右移，提升吞吐

然而，按「DoD 达成」作为迭代的产出，在业务上终归是没有实际意义的，毕竟迭代结束时，story 依然是半成品，在业务上不产生价值。即：团队的产出数据，与业务价值上的反馈是脱节的。

让我们回归到敏捷研发的目标：大部分 story 应在迭代结束时能交付给用户，进而清空 backlog，确保在下个迭代充分响应新的业务变化。这意味着要在尽量短的周期内完成 story 的所有工序。于是，我们下一步就必须对团队的 DoD 提出更高要求了。

按前文所述，DoD = 完成发布时（此刻已不存在 undone 工作），才算是交付到用户手上。所以，在迭代规划上，我们开始引导团队将 DoD 右移，以减少 undone 工作流入下个迭代，提升迭代规划时团队的可用容量，保持敏捷性。

迭代交付率 = 迭代内发布的 story 个数 ÷ 迭代规划的 story 个数 × 100%

（注：与「迭代完成率」的区别是不遗留 undone 工作）

图6. 试点团队的「迭代交付率」统计

效果点评

通过倡导 DoD 右移，使得团队在迭代计划会上，倾向于以上线为目标来填充迭代 backlog，进入迭代的 story 数量更克制了。

团队围绕着有限的 story 工作，目标清晰，团队一致追求 story 在迭代内上线，遇到障碍会主动协商解决，职责的边界感也更弱了。于是，在迭代结束时遗留的 undone 工作变少了，迭代交付率得以改善。

需要流转的 story 变少，可以为下个迭代留出充足的空间，团队有能力承接更多的新需求，满足了上游业务提升吞吐率的诉求。

图7. 通过 DoD 右移来提升研发吞吐的系统思考

实操建议

团队刚做敏捷转型的时候，可能会出于各种原因，导致 DoD 混乱的情况。但随着团队越来越成熟，可以定期评估是否存在 DoD 右移的契机。可能的过程是：

阶段0：没有 DoD 或没有统一的 DoD。
阶段1：统一 DoD，DoD = 完成测试。
阶段2：DoD = 完成演示。
阶段3：DoD = 完成发布。

其中，有 2 个点是值得我们关注的：

要有一个统一的 DoD 作为团队的目标。降低因迭代中存在不同 story 定义各自 DoD 而产生的团队认知负荷。
DoD 至少是完成测试。因为在实操中，时常发生测试积压的现象，DoD 把测试阶段包含进来，可以让团队关注这个风险。

团队在每个迭代都期望完成 DoD 的目标，在这个过程中会碰到各种情况，以下例举了 3 个场景以及对应的实践建议：

Case1：需求颗粒度太大，一个迭代做不完（这种情况比较常见）。建议：通过用户故事地图的方式，把 epic 级别的需求拆成 story，将 story 作为交付的最小单元。

Case2：业务上要求多个 story 集中发布，才能为客户提供场景闭环。建议：可以把 DoD 定为完成演示（即：待发布状态），当所有相关的 story 都达成 DoD 时，就可以进行统一交付。

Case3：拆分 story 后，回归的工作量陡增，测试成本上升。建议：前期可以先把 DoD 定为功能测试完成，发布前对 epic 进行统一的回归测试（或者，可以通过提升测试自动化水平，来降低回归成本，也有助于 DoD 右移）。

总的来说，明确 DoD 及右移，有助于特性团队的敏捷转型，DoD 离用户越近，团队的成熟度和敏捷性就越高。