译者导读:
文章说明了重大风险常常源于产品待办列表与Sprint待办事项列表之间的依赖,并可能导致Sprint失败致使团队违背对Sprint的承诺。为尽早的暴露潜在的可能造成风险的依赖,应该最先处理最难的工作事项与最可能产生依赖的工作事项。一次性对齐依赖项,并运用5S技术(整理、整顿、清扫、清洁、素养)来深度审查Sprint待办事项列表中的依赖来解决依赖对于成功交付的风险的程度。

...¶54产品待办列表已符合¶65就绪的定义,并且已经开始了¶75主题级交付小周期。团队正采用¶25蜂拥式协作:单件连续流”的模式,一次专注于一个¶55产品代办事项,逐步交付对应的¶73 Sprint待办列表事项。然而,一些工作项之间存在一些依赖。
如果在¶46 Sprint进行到一半时仍存在关键依赖,且团队还在不断发现新的依赖,那么这次Sprint就有失败的风险。
重大风险源于产品待办项及与之对应的Sprint待办项之间的依赖——二者彼此独立却又相互关联。新涌现的需求或不可预见的事件可能迫使团队改变工作项的先后顺序。例如,团队可能必须等待外部供应商或合作伙伴的交付物,或等待早已答应好却推迟的实验室资源;又或者,当团队发现某条关键路径上的产品待办事项其实还依赖其他Sprint内的工作时,只能把它挪到Sprint更靠后的时间。当团队因故推迟某项工作时,仍须确保“整体持续向前”(见第467页¶104“总有人要让事情继续向前”)。

想要确保团队在Sprint待办事项(Sprint Backlog)的顺序上保留调整空间,但若工作项频繁变动(churn),会带来不确定性,增加了无法交付利益相关者预期价值的风险。希望在Sprint计划(Sprint Planning)阶段就把任务排好,避免重复进行环境搭建、权限申请等准备性任务,但Sprint开始很难预见所有依赖。随着Sprint推进,预先考虑到的依赖逐渐清晰,新的依赖又不断浮现;¶29每日站会(Daily Scrum)时,团队会基于新知对Sprint待办项重新排序。然而,如果把解决依赖拖到“最后责任时刻”,就会造成返工(rework)、阻碍(blocking)与中断(balking)的低效率表现:你往往直到错过那一刻,才知道“最后责任时刻”早已过去。
——摘编自第八届国际精益建造组织年会论文集 [Bal00]
因此,在Sprint过半之前,必须确保所有已知的依赖处于可控状态。
你希望迫使涌现的事项尽可能早地暴露,你应优先攻克最难的事项以及处理最可能产生依赖的工作项。这表明了一种“先难后易”的风险管理策略:将彼此依赖的是Sprint待办事项整体提升到Sprint工作计划的顶部;同时保持它们仍归属于同一 产品待办列表(PBI)。(蜂拥式(Swarming)的单件连续流)

在正式进入“主题级交付小周期”(Production Episode)之前,¶7 Scrum团队会先对产品待办列表项(PBI)做一次粗排序,以形成一份已精炼的¶64 产品待办列表。然而,绝大部分的依赖分析和再排序工作,由¶14开发团队在前半个Sprint的每日Scrum中完成 —— 由此产出一份¶76由开发者主导的工作计划。
偶尔该策略也会失效——依赖会失控。立即启动¶32 紧急程序:中止当前Sprint;重新规划;以最新认知启动全新Sprint。另一备选:回退并坚守原¶71 Sprint目标。
一次性对齐依赖关系,可显著提高生产阶段(Production Episode)达成交付目标的几率。
运用5S技术(整理、整顿、清扫、清洁、素养:即Sort, Set in order, Shine, Standardize, Sustain;详见《丰田汽车领域指南:实施丰田4Ps的实用指南[LM05]》第64页)来深度评审¶72 Sprint待办事项列表,是深入挖掘潜在依赖关系的一种有效方法。由于5S可能非常耗时,团队应仅在隐性依赖可能引发高风险时使用它。
杰夫·萨瑟兰(Jeff Sutherland)引用了一个来自OpenView的案例研究:在该案例中,团队需要在Sprint中期消除依赖关系;若无法实现,他们便将对应的产品待办事项移出。这种做法通过异常终止Sprint的方式使问题显性化,不是用“小刀慢削”的方式悄悄侵蚀团队的Sprint目标承诺。
同样的模式也适用于产品待办列表(Product Backlog)的范围。开发团队与¶11 产品负责人(Product Owner)应共同协作,分别考量开发与部署层面的依赖关系,以共同打造一个精炼的产品待办列表(Refined Product Backlog)。对长期技术依赖关系的洞察,往往有助于形成排序更高效的产品待办列表。
请参考紧急处理程序。
译者:吴梦瑶 校对:Peter
点击回顾第一册 Scrum模式语言合集

Tips:以上带符号黑体是模式语言。