当冲刺被打断时：Scrum 团队的实用工作法
每个 Scrum 团队迟早都会遇到同样的时刻：冲刺进行到一半，工作进展顺利，紧急情况却突然出现——生产环境的缺陷、监管机构的提问，或是供应商刚刚通知交货将延迟三周。在许多团队度过的 2021 年那种紧张、半远程的环境里，这类打断来得更频繁、也更沉重。本能的反应要么是放下一切，要么是把冲刺奉为神圣而置之不理。两者都不对。Scrum 提供了更好的应对方式，值得在下一次紧急情况来临前先加以练习。
先从《Scrum 指南》真正所说的内容出发。冲刺目标赋予冲刺以连贯性；开发者拥有冲刺待办列表，并可在不断学习的过程中与产品负责人重新协商范围。只有产品负责人才能取消冲刺，而这种情况很少见。因此，打断并不是框架的危机——它正是框架预期你去有意处理的那类变化。
在动冲刺之前先分诊
大多数打断都没有最初看起来那么紧急。在任何人打开冲刺待办列表之前，先让这项请求经过三个快速问题。
它真的具有时间紧迫性吗？ 如果等到几天后的下一次冲刺规划，会造成真正的损害吗？如果不会，它就像其他请求一样进入产品待办列表，按顺序等待。
它是否威胁到冲刺目标？ 与你的目标无关的紧急事项，比起会动摇你所承诺成果的事项要容易推迟得多。请以目标为标尺来判断，而不是以最大的嗓门为准。
谁才是合适的决策者？ 范围的取舍是开发者与产品负责人之间的对话。Scrum Master 让这场对话保持诚实，并保护团队不被外部人士擅自代为承诺。
在不自欺的前提下吸收工作
如果该事项必须进来，就把它当作一次交换，而绝非免费的追加。容量是有限的；假装并非如此，只会把失败推到冲刺末尾。请让这次替换明确且可见。
把紧急事项拉入冲刺待办列表，同时拉出等量的已规划工作，由产品负责人商定推迟哪些内容。
首先保护冲刺目标。如果必须放弃某些工作，放弃与目标关联最弱的部分，而不是恰好尚未完成的部分。
立即更新看板，让变化在下一次每日 Scrum 上可见，没有人私下背负看不见的额外工作。
如果打断之大已使目标无法达成，就明白地说出来。重新协商过的目标，胜过悄悄落空的目标。
对于经常被打断的团队，留出务实的缓冲很有帮助。一些开发者会在每个冲刺中预留一部分容量，用于计划外但确实正当的紧急工作，并根据历史而非期望来估算其大小。这并非 Scrum 的规则，但能避免小小的打断每隔几天就逼出一次重新协商。如果你的缓冲不断溢出，这本身就是数据：真正的问题也许在上游——不稳定的系统、含糊的需求、脆弱的供应链——而这属于你的冲刺回顾。
从规律中学习，而不只是从单次事件
一次打断只是噪声。一类反复出现的打断则是信号。把这种规律带到回顾会上，追问为什么同样的火灾一再燃起。修复往往是结构性的：更好的监控、更清晰的归属，以及一个经过充分梳理、以至于那些“紧急”请求其实本可预见的产品待办列表。把打断当作改进原料的团队，会逐渐遇到更少的打断，而剩下的那些也不再像紧急情况。
目标不是一个从不被打断的团队——这样的团队并不存在。目标是一个能在冲刺中途挨上一拳、有意识地决定该怎么办、并且大声说出取舍真相的团队。
如果你的项目总是因为半途而来的意外而失去专注，XNM 的项目群与项目交付咨询 可以帮助你建立既能吸收变化、又不丢失计划的交付惯例。