团队至少会有协调计划和控制时间的能力。他们能够说：“我们将在接下来的迭代中完成这些事情”，并对这一情况有一定的合理预期。

我们看到很多Scrum文献中描述了一类团队——这类团队进行迭代计划并且避免计划改变。

但是如果这些变化无法被排除在迭代计划之外，团队成员应该如何应对？

在这篇文章中，我们将针对两种不同类型的团队谈谈这个话题：

偶尔有中断、但不多的团队

高度中断驱动的团队

计划要有安全缓冲边界

许多敏捷团队受益于在每个迭代中加入适量的安全区。总的来说，团队不能假定，他们可以将所有的变化排除在迭代之外。例如，当他们计划完成如下事情时，团队可能想离开迭代范围：

修复关键操作问题，比如服务器断电。

修复高危Bug。

做一级或二级技术支持。

有很多其它类似的例子。想想你自身所处的环境。试着为一个迭代中有价值的中断设定一个较高的临界值。当团队有大量不会被打扰的专用时间时，团队会做到最好。

为了适应这样的工作，一个团队需要做的就是在迭代计划中留下一些缓冲时间。让我们看看缓冲时间是如何运作的。

每个迭代需包含的三类时间

我认为每个迭代需要包含三类时间：企业管理消耗的时间，可计划的时间和计划外的时间。如图1所示：

图1

企业管理消耗指的是一些事情所占用的时间，如全公司会议、邮件回复关于过去的项目、参加人力资源敏感性培训等等。这些活动可能是必要的，但是在许多企业中，它们消耗了大量的时间。

我将Scrum会议（计划会议、每日站会等）也放入企业管理消耗类别中。

可规划的时间是迭代中的第二类，属于集体的时间。

但是团队不想将迭代的剩余时间都被可计划时间占满。团队需确认，要离开迭代的计划外时间的范围。

计划外的时间通常针对三件事情:

紧急事件。

那些比团队原本认为的大得多的任务。

那些在迭代计划会议中没有想起来的任务。

适当的百分比

我经常被问到，对于这三类，团队应该使用怎样的百分比？我不能回答这个问题，但是我可以告诉你应该如何解决这个问题：

在每个迭代后，思考一下，团队分配的计划外时间和团队需要的计划外时间的匹配度。然后在下一个迭代中，将计划外时间进行略微的上调或下调。对于这个，团队永远无法做到完美。

相对而言，这是一个平均数游戏。团队需要在平均水平上节省计划外的工作所需的时间。因为在一些迭代中会出现较多的计划外工作，一些迭代会出现较少的计划外工作。

当较少的计划外工作出现时，团队需要提前完成他们的工作。他们要为更多计划外工作的出现做准备。

当一个团队被高度中断驱动时，该怎么做呢？

前面的建议在大多数敏捷团队——那些只受适量干扰的团队很有用。但是，一些团队是高度中断驱动的。

再一次，我拒绝给图1中的每一个区域一个确定的百分比，但是，我在正在描述的情况中，“计划外时间”的面试比实际显示的大得多。

我实际上想说的是，这些案例中，计划外的时间会变为这三个区域的主导地位。这些团队是高度中断驱动的。

这些团队在他们的迭代中仍然需要包含计划外时间。但是如果你处于一个高度中断驱动的团队中，通常你还需要考虑一些其它的事情。

首先，你可以调整迭代的长度。一种选择是进行一个长期的迭代。提高迭代的长度有助于更好地预测中断率，因为从一个迭代到另一个迭代，中断率的差异不会很大。

来看看这个是如何起效的，想象你选择了一个为期一年的迭代。（不要这样做！）想象这样长期的迭代很容易，团队短期迭代面对的波动将会被洗掉。当然，今年（这次迭代）可能比去年（上个迭代）有更多的中断，但这是一个很长的时期，团队有时间从任何过度波动中恢复。

另一种选择是进行短期的、一周的迭代，适应这种不确定性。在给定的时间内，团队将无法向老板保证“我们将完成这些”，但是，我发现，这是一个非常值得的折中方法。

其次，一个高度中断驱动的团队应该让迭代计划成为一个非常轻量级的活动。

迭代计划中，团队应该努力快速抓住一些事情，团队成员认为这些事情可以在未来的一周内完成。此时，迭代计划会对于很多团队应该是一个非常小的努力，15分钟或30分钟。

为了说明这一点，想象策划一个派对，并且想象一个极端，策划一个婚礼。这是一个相当重要的派对计划。想象另一个极端，计划邀请一些朋友在今晚观看电视上的大型游戏。为了这个计划，我需要去检查冰箱里面的啤酒、预定一些匹萨。这是派对计划的不同层面。

一个高度中断驱动的团队的迭代计划应该更像后者——快速、简单并且能够成功应对计划外的任务出现。