【敏捷FAQ 第12期】不再被插单牵着走！敏捷现场的“计划守护方法”FAQ？

 感谢您阅读本文。我是敏捷小组的藤井智弘。
 继上次讨论遗留事项之后，这次要谈的是另一个背叛计划的常客：插单。这里将讨论我在第2期预告过“会在第12期左右集中讲解”的记录方法、值班制和统一受理入口。

 故障处理、来自其他部门的咨询、经由上司转来的“帮忙查一下这个”……不在 Sprint 计划中的工作，每个 Sprint 都必然会到来。计划总是被侵蚀，Sprint Goal 最终沦为纸上谈兵。
 有没有一种方法，既不把插单“当作不存在”，又能将其纳入 Scrum 的运作之中？

 有。首先，先来处理这个问题常伴随的三个疑问。

• 插单每次都以不同的面貌出现，根本无法预测吧？
• 如果把插单纳入计划，计划工作量就会相应减少。这不就是“输”了吗？
• 团队没有拒绝的权限。到头来，来的事情只能接下吧？

 逐一回答。

• 插单虽然无法逐项预测，但其总量往往会落在一定范围内。只要记录下来，就能发现其中的模式。
• 因插单而减少计划工作量，并不是输了，而只是让计划变成了符合实际情况的计划。
• 团队没有拒绝的权限——这一点确实如此。现实中，团队被赋予的权限少得令人觉得“自组织化”这个词都显得空洞。正因如此，才要让机制承担起拒绝的角色。

 要点有三个。第一，进行度量。第二，基于实际数据，从一开始就在计划中纳入插单预留量。第三，设计接收插单的方式。让所有人随时都能接单的体制，是破坏全员专注力的最糟糕设计。

 我想很多人在培训中都曾被教导：“Sprint 的计划是需要遵守的”“Sprint 中的变更会危及 Sprint Goal”（或者说，“自己是这样理解的”）。那时，你是否产生过这样的疑问？

• 即使发生生产环境故障，也要说“现在是 Sprint 中，请等到下周”吗？
• 如果把所有插单都堆进 Backlog，留到下个 Sprint 再处理，需求方不会接受吧？
• 教科书所说的“能够遵守的 Sprint”，难道不是没有插单的现场才适用的吗？

 这三个问题，也是我在客户现场最常听到的反驳。先说结论：应当守住的不是“计划”，而是“制定计划的方法”。故障要接受，但要在预留量之内接受。不是将所有事情都留给下个 Sprint，而是按紧急程度分类。而且，教科书中的 Sprint 并不是以没有插单为前提，而是以插单已经被纳入计划为前提。让我们从插单的反模式开始，依次梳理得出这一答案的路径。

 为插单烦恼的团队，通常会存在几种反模式。只要符合其中一种，本文应该就能帮到你。

第一种：意料之外型——这是最常见的一种。在制定 Sprint 计划时，以插单为零为前提来估算容量。即使过去 10 个 Sprint 中从未有过插单为零的情况，依然如此。这次是生产环境故障，上次是其他部门的数据提取请求，再上次是销售部门的紧急调查。团队被每项插单不同的面貌所迷惑，忽视了其总量其实落在稳定范围内这一事实，于是“每次都为意料之外的事情所苦”的矛盾状态成了常态。

第二种：直接命中型——插单请求直接送到恰好容易搭话的人，或者恰好上次处理过此类问题的人手中。特定某个人的计划反复崩溃，该成员始终无法完成计划中的工作。而且，由于所有人都处于“不知道何时会被插单打断”的状态，整个团队的“专注时间”都会被剥夺。

第三种：全部紧急型——请求带着“马上处理”的面貌而来，也就被原样作为“马上处理”的事项来处理。记录后会发现，被说成“马上处理”的请求中，相当大一部分其实并不需要在当前 Sprint 处理。由于没有判断紧急程度的关卡，需求方声音的大小就成了优先级。

第四种：自掏腰包型——即使接受插单，也不减少计划工作量，而是通过加班和节假日工作来填平差额。表面上的计划被遵守了，Velocity 看起来也很稳定。虽然能维持数个月，但最终会以疲惫和人员流失收场。从管理层看来，这种团队似乎是“即使有插单也能运转的团队”，因此也是最难让人意识到需要采取对策的一种类型。

 这四种模式，是同一个前提的不同表现形式。这个前提就是：**“插单是例外。”**既然是例外，就不纳入计划（意料之外）；来了就由接到的人直接处理（直接命中）；既然是例外，就按紧急事项对待（全部紧急）；处理所花费的工作量则在计划之外自行消化（自掏腰包）。从这个前提出发，这些做法全都是顺理成章的应对。

 接下来，回答前面的三个疑问。

 首先，**即使发生生产环境故障，也要说等到下周吗？**不是。故障要接受。但要将用于接受故障的工作量，预先作为一个预留量纳入计划。插单预留量是容量问题；如果处理生产环境故障需要走紧急变更流程，就不要省略流程，而是照常执行，并从预先确保的插单预留量中扣除相应处理工时。有了预留量，故障处理就不再是“破坏计划的事件”，而成为“在预留量内接收的计划内工作”。

 接下来，**如果全部留到下个 Sprint，需求方不会接受吧？**并不是把全部都往后推，而是按紧急程度分类。真正需要立即处理的事情在预留量内接收，其他事项则放入 Backlog，成为下个 Sprint 的候选项。有了这种分类，与需求方的对话就会从“接不接、拒不拒绝”，变成“什么时候做”。绝大多数情况下，对方无法接受的是被拒绝，而不是被告知具体排期。

 还有，**教科书中的 Sprint 难道不是没有插单的现场才适用的吗？**不是。教科书所说的“遵守计划”，并不是以没有插单为前提，而是以制定了考虑插单的计划为前提。应当守住的，不是计划中列出的事项清单，而是基于实际情况来制定计划这一方法。如果实测插单占三成，就从一开始将这三成预留在计划之外。这才是“能够守住的计划”。

 **为什么会把“插单是例外”来处理？**因为从单项来看，插单每次都以不同的面貌突然出现。单项上虽是突发，总量上却会落在一定范围内——这正是插单的典型特征。但单项的面貌太过鲜明，人们就难以注意到总量。
 还有一个原因是，插单是团队外部的组织结构——支持体系不完善、与其他部门的职责分工不清晰、升级路径尚未建立——流入团队内部的一种现象。团队会觉得“这本来就不是我们的工作”，而这种感觉又进一步合理化了“例外”这一处理方式。这不是某个人失职的问题，而是结构问题。

 那么，插单本来应该如何处理？只要直接套用经验主义的步骤即可。

• 首先，逐项记录插单，查看总量、来源以及其占容量的比例（观察）。
• 接着，质疑“只是这次碰巧比较多”，确认总量是否真的稳定在一定范围内、来源是否存在偏向、真正紧急的事项占多少比例（检视）。
• 在此基础上，按照实际比例决定计划预留量，设计接收方式，并根据来源投入资源以减少插单本身（适应）。

 按这个顺序排列后，就能清楚看到意料之外型跳过了哪里。因为没有观察，所以每次都以“这次是特殊情况”结束，检视和适应也无从开始。停止“每次作为例外处理”，转而采用“作为常量纳入计划，并设计接收方式”。这种视角的转换，将决定后续措施是否有效。

 值班制和受理路径的具体形式，可以因现场而异。需要注意的是，不要停留在“我们已经预留了容量”这一步。那只是意料之外型的一种变体：没有人去确认预留量是否与实际情况相符。尝试之后，请根据计划工作是否能够按时完成、插单总量本身是否开始减少来判断效果。

先记录 1～2 个 Sprint
 先度量，再处理。每当插单到来时，用一行记录内容、所需时间、来源，以及是否真的需要立即处理。工具无所谓，便签或电子表格都可以。积累两个 Sprint 的数据后，就能得到“我们团队的插单平均占容量的 ○%”“插单来源排名靠前的是 △△ 部门和生产监控”这样的实际情况。这些数字将成为之后所有协商和设计的基础。

按实际比例确保“插单预留量”
 如果实际数据是 30%，就将 Sprint 的三成容量预留给插单。这里有一点需要注意。如果你是按 Velocity 进行计划，插单的部分已经包含在实际 Velocity 之中。正如第9期和第10期所讲，Velocity 是包含会议和插单在内的观测值。如果再从中扣除三成，就会重复扣减。预留容量，意味着将这种看不见的扣减，以可见的形式呈现出来。如果现场以时间或人日来安排工作量，就按七成容量进行安排。如果现场以 Velocity 来安排，则应将插单与计划工作分开记录。这样一来，当插单比例发生变化时，就能知道 Velocity 的增减中有多少是由插单造成的。
 如果插单预留量没有用完，那就是赚到，可以提前着手处理下一个候选事项。反过来，如果超出了预留量，则应记录超出的事实并与 PO 共享，请其判断对 Sprint Goal 的影响。从“计划被插单破坏了”，转变为“插单超出预留量，因此进行了调整”。即使是同一件事，后者也是受控的运作方式。

通过值班制将影响局部化
 每个 Sprint 确定负责处理插单的值班人员（1～2 人），将所有请求的初步受理集中到值班人员。值班人员几乎不承担计划工作；没有插单的时间，则用于小型改进任务或下个 Sprint 的准备。其他成员与插单隔离，能够专注推进计划工作。值班人员轮换，以防止工作集中到特定人员以及形成个人依赖。与其让“所有人都受到一点干扰”，不如“由一个人承担，其他人得到保护”，这样团队整体的完成量会更高。

统一受理入口，并加入紧急程度判断
 请将请求的受理路径统一为一个入口（发送给值班人员或专用频道），并在其中加入“是否真的需要立即处理，还是作为下个 Sprint 的 Backlog 即可”的判断。这一判断和协商是 PO 的工作。让开发者逐个去“拒绝”，负担实在太大。关键在于让机制承担拒绝的角色。而且，这个入口只有在请求方配合的情况下才能发挥作用。团队应统一受理入口并承诺快速的首次响应；请求方则应遵守该路径，并附上一句“需要在何时之前完成、为什么需要”。只有一方单独做到，入口很快就会被绕过。

如果插单超过半数，就重新考虑框架
 如果实测结果显示，插单长期超过 50%，那么该团队的主要工作更适合采用“流动式”的推进方式。如第2期所述，不要执着于 Sprint 这个固定的盒子，应认真考虑结合使用或迁移到看板。Scrum 是手段，守住一个不符合实际情况的框架本身没有任何价值。

 插单是团队外部的组织结构流入团队内部的一种现象。根本原因在团队外部，仅靠团队内部的改进无法将其彻底消除。正因如此，无论哪个时代、哪个团队，都会有同样的烦恼。

 但这并不意味着我们无能为力。度量可以成为协商的武器，预留量能够保护计划，值班制能够保护专注力。而“插单中有 ○ 成来自 △△ 部门的标准化咨询”这样的数据，可以成为完善 FAQ、实施各种自动化和自助服务化等投资的依据，从而减少插单本身。即便问题来自外部，从内部可采取的措施也比想象中更多。插单是否被记录、预留量是否与实际数据进行比较、是否将按来源制定对策列入讨论议程。具备这三点，是衡量一个团队是否将插单作为常量对待的标准。

下期：“PO 太忙，无法来到团队中”