作者:严梨炯 | 效能改进
一、背景
DoD(全称:Definition of Done)是特性团队内部,针对某个即将进入下一个迭代 backlog 的工作条目(一般指 story),约定其在该迭代结束时须完成到什么程度(比如:完成测试并等待演示,见图1)。尤其是当 story 颗粒度较大(须跨多个迭代)时,用该方式达成该团队共识,显得尤为重要。
众所周知,即便在敏捷模式中,研发过程依然由若干道工序所组成,故 DoD 的设计,完全可以基于工序来划定。笔者在敏捷转型的实践过程中,完成了特性团队从无到有创建 DoD 活动,并推动其逐渐右移,以帮助团队养成「聚焦目标」的习惯。
二、问题现状
既然定义了 DoD,那么该 story 的未尽事宜工作就被称为 undone(故,story 生命周期 = DoD + undone)。参考图1,在该例子中,DoD 是到完成测试,那么 undone 就包含「演示、发布」工作。理想情况是,如果 DoD 是完成发布,那么就不存在 undone 工作了。
笔者对接的特性团队正处于敏捷转型阶段,整个迭代过程是粗放式的,其成员习惯于在迭代计划会上,从迭代 backlog 中一次性认领全部 story。与此同时,PO 看到 story 都被认领,也就放心地离开了。
照理说,迭代 backlog 中的 story 条目数,是根据团队的容量来规划的,目标是当迭代结束时,大部分 story 都能交付给用户使用。然后,真实的情况是,与只关注「有人认领」一样,团队同样也只关注 story「已经启动」,于是团队开始同时启动,并穿梭在多个 story 的架构设计和编码工作之间(见图2)。
这导致了一个怪现象:在迭代(3周)的第一周,几乎没有 story 进入测试,但到了第三周,看板上却堆满了测试任务,而此时开发人员已从上述 story 的研发工作中离开,不再关注。
最后,只有少量 story 能如期交付,其中一部分还是上个迭代流入后,占用本迭代的时间和资源才得以完成的。所以本迭代可用于规划的团队容量因 undone 工作积压而缩减,可认领的 story 变少了,于是团队的适应性变差了。团队持续在做遗留任务,失去了对目标的冲刺感,PO 对团队信心不足,迭代活动变得形同虚设了。
读者可能会说,何不将计就计,把各道工序都错开一个迭代(或一周)?见图3。这种做法借鉴了精益流动的思路。但问题是,story 并不像工厂车间生产零件,其每道工序没有标准化的处理时长,研发各环节的波动性对团队迭代计划的冲击会很大(关于该话题,笔者将单独撰文分享)。
三、实践1:引入 DoD,重获目标感
在这样的团队氛围下,任何的改进都可能是无效的。笔者认为,当务之急是重拾团队信心。于是,我们引入团队的唯一举措是,在迭代计划会上,为每个 story 设定 DoD。
虽然在后续的认领环节,团队依然会一次性清空迭代 backlog,但团队成员会更明确自己名下 story 在本迭代的目标(此时不对 DoD 提出任何额外要求),而且我们会在迭代结束时,为大部分 story 达成 DoD 而庆祝,以此逐渐找回迭代工作的节奏感。
迭代完成率 = 达成 DoD 的 story 个数 ÷ 迭代规划的 story 个数 × 100%
四、实践2:DoD 右移,提升吞吐
然而,按「DoD 达成」作为迭代的产出,在业务上终归是没有实际意义的,毕竟迭代结束时,story 依然是半成品,在业务上不产生价值。即:团队的产出数据,与业务价值上的反馈是脱节的。
让我们回归到敏捷研发的目标:大部分 story 应在迭代结束时能交付给用户,进而清空 backlog,确保在下个迭代充分响应新的业务变化。这意味着要在尽量短的周期内完成 story 的所有工序。于是,我们下一步就必须对团队的 DoD 提出更高要求了。
按前文所述,DoD = 完成发布时(此刻已不存在 undone 工作),才算是交付到用户手上。所以,在迭代规划上,我们开始引导团队将 DoD 右移,以减少 undone 工作流入下个迭代,提升迭代规划时团队的可用容量,保持敏捷性。
迭代交付率 = 迭代内发布的 story 个数 ÷ 迭代规划的 story 个数 × 100%(与「迭代完成率」的区别是不遗留 undone 工作)
五、效果点评
通过倡导 DoD 右移,使得团队在迭代计划会上,倾向于以上线为目标来填充迭代 backlog,进入迭代的 story 数量更克制了。
团队围绕着有限的 story 工作,目标清晰,团队一致追求 story 在迭代内上线,遇到障碍会主动协商解决,职责的边界感也更弱了。于是,在迭代结束时遗留的 undone 工作变少了,迭代交付率得以改善。
需要流转的 story 变少,可以为下个迭代留出充足的空间,团队有能力承接更多的新需求,满足了上游业务提升吞吐率的诉求。
六、实操建议
团队刚做敏捷转型的时候,可能会出于各种原因,导致 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 离用户越近,团队的成熟度和敏捷性就越高。
延伸阅读
- 如何用「标准差」度量研发波动
- 一则物理看板的演进实践
- 「研发共建」提升中台效能初探
- 效能指标「研发浓度」在项目度量中的应用
- 有赞效能数据赋能实战
- 项目制实践如何助力组织进化
- 有赞如何打造高绩效的千人技术团队?
- 敏捷与 OKR:系统思考与组织设计的艺术
- 大规模产品待办列表处理策略—需求分级
- 大规模产品技术团队需求管理实践
如果读者对效能改进也有兴趣,欢迎加入有赞效能改进团队,请将简历投递至:yanlijiong@youzan.com,我们共同探讨和实践。