当冲刺被劫持：一个 Scrum 团队应对冲刺中途打断的故事
一个支持内部平台的产品团队，在每次回顾会上都有同一个抱怨：每个冲刺开始时干净利落，结束时却一片混乱。他们周一定下冲刺目标，到周三，某位总监就会转来一个「紧急」请求，某位干系人把一个「举手之劳」丢进某人的聊天窗口，于是做了一半的冲刺待办列表就散了架。这是一个匿名化的情景，但如果你在一个繁忙机构里带着混合办公团队做 Scrum，你大概经历过它的某个版本。
诊断真正的问题
团队起初把矛头指向打断本身。但《Scrum 指南》本就提供了应对变化的机制——问题在于团队不再使用它们。有三样东西已经悄悄崩坏：
冲刺目标是一份工单清单，而不是一个连贯一致的目标，所以新东西来时没有任何东西显得受到保护。
请求通过私信直接发给开发人员，完全绕过了产品负责人。
团队没有形成共识：冲刺待办列表属于开发人员，范围是协商出来的，不是被指派的。
换句话说，打断只是症状。根源在于团队任由产品负责人对产品待办列表的当责被侵蚀，又没有一套约定好的办法去判定什么才是真正紧急的。
团队做了哪些改变
他们没有发明新流程。他们回到《Scrum 指南》本来的样子，并以纪律去执行它。
一个清晰陈述的冲刺目标。 团队为每个冲刺打磨出一个单一目标，让工作有了连贯性。一个真正的目标，能让人一眼看出新来的请求是否在威胁它，也给了团队为此发声的语言。
一切都经由产品负责人。 新请求不再落进开发人员的聊天窗口，而是交给产品负责人——他负责对产品待办列表排序，并决定某件事是否要挤掉当前的工作。
保护冲刺，协商范围。 依据《Scrum 指南》，冲刺目标保持不变，但随着认识加深，范围可以在产品负责人与开发人员之间重新协商。只有当一项同等大小的工作被移出时，真正紧急的事项才能加入。
用每日 Scrum 来适应变化。 开发人员不再把冲刺中途的变化当成紧急事件，而是利用每日 Scrum，在现实发生变化时朝着冲刺目标重新规划。
宁可取消，不可腐蚀。 团队约定：如果真出现一桩让冲刺目标作废的紧急情况，产品负责人可以取消该冲刺——这是一个罕见而审慎的举动，而不是每周悄悄塞活的习惯。
结果与教训
几个冲刺之内，模式就变了。真正紧急的工作依然会发生，但现在它要经过单一的决策点，并以现有范围作为交换，于是团队不再以「样样做到一半」收尾。那位过去爱转发「紧急」请求的总监，也学会了期待一场关于取舍的快速而坦诚的对话，而不是无声的照单全收。
更深层的教训是：冲刺中途的打断很少是 Scrum 的问题——它们是决策权的问题。Scrum 给了你应对变化而不陷入混乱所需的事件与当责。大多数自觉被劫持的团队，只是单纯不再使用它们，尤其是那个能给所有人一个值得守护之物的冲刺目标。
如果你的冲刺总是被打乱，而你希望有人帮你重建那种让敏捷真正交付成果的纪律，XNM 的项目群与项目交付咨询服务 可以帮助你的团队守住专注，又不至于变得僵化。