应对敏捷项目中的干扰

干扰，正如它名字所显示的，是影响敏捷项目团队速度、减缓其前进的刹车闸。有些干扰是必需的，其他则不是。关键在于：要识别出影响工作进程的干扰，并尽量减少它对项目的负面影响。

Extreme Programming 讨论组上有一个有趣的讨论，Alistair Cockburn 在其中分享了他认为影响“团队涌流”的一些主要干扰：

（1） 过多会议（程序员必须放下工作去参加一个接一个的会议，以及）
（2） 过多同时进行的项目（程序员必须放下项目 A 的工作，切换到项目 B）。 这些干扰会消耗很多的时间和精力。不过一般总可以找到调整项目、会议和每天工作安排的方式，减少干扰，程序员也可以多花时间，进行不间断的编程。

Alistair 接着说道：团队中，有时必须有一个人完全负责接电话、参加会议、找人、做与客户的接口等工作。而此人的工作也因此而无法达到团队对他的期望。但是 Alistair 说，对这个人工作产出的期望，应该受限于他能够花在项目上的时间。

在他的众多项目管理模式中，Alistair 将此命名为“牺牲一个人”。Alistair 在这个模式里提出，一个项目可能无法像当初规划的运转那么快，这是因为有很重要的干扰占用了整个团队的时间。虽然干扰可能是很重要的次要任务，而且无法放弃；但是，它确实分散了团队在最主要的任务上的注意力。

Alistair 认为解决问题的方式是，分配一个人来专门应对干扰。虽然这个人可能觉得自己是牺牲品，但是团队剩余的成员可以通过处理最主要的任务来取得工作进展。

Gojko Adzic 也提供了类似的意见，他讲述了自己的故事：当时他在一个项目中承担架构师的工作，但却花费了很多时间来充当软件方面的润滑剂。相关的任务包括：解答新人的问题、协调不同的讨论、与客户沟通、参加各种会议。Gojko 补充道，如果他试着花更多时间在编程方面的任务上，很多其他团队成员就必须充当润滑剂，这拖慢了整个团队的速度。因此他决定接过来所有的次要工作，让其他人集中精力处理主要任务。Gojko 提到：

虽然我仍力图编写代码、了解项目的整体进度，但是团队在做计划时，已经不怎么再指望我的参与了——我的时间不会被计算在内。四个月之后回头再看看，考虑到项目的进度以及团队的工作效率，我认为这样解决问题很有效。

对于 Alistair 提出的第二个主要干扰，邮件组的成员们都同意：让人同时参与多个项目没法取得好的效果。对于这样带来的心态问题，Gojko 这样总结。

问题在于，如果你的成员是四、五个只能部分参与项目的人，项目干系人会认为你拥有一个完整的团队；而实际上，他们最多相当于一个全职投入的人，如果不是更少的话。

为了进一步表明支持人们专心投入单个项目，Gojko 说到：团队成员同时在多个项目中工作，沟通和协调工作会占用相当多的时间和精力。他举了下面这个很有趣的例子，来证明他的观点：

10 个投入程度为 20% 的人，他们的产出理论上相当于两个全职人员；但是协调这 10 个人却要比协调两个人花费更多的精力。而且与协调 10 个全职人员的精力花费相当，甚至有可能更多。我想这是因为下面的原因：由于其他工作的要求，这 10 个部分投入的人会经常无法参加站立会议和进度会议，而且不能像 10 个全职人员那样始终坐在一起。两个全职的人，基本上不需要什么协调，也没有多少沟通上的无谓消耗。

讨论组的人都认为：要去除与这些主要的干扰相关的风险，应该从两方面下手：牺牲一个人，让他来处理所有的次要任务；还要注意不要让一个人同时参加多个任务。

查看英文原文： Handling Interruptions on an Agile Project