作者 Vikas Hazrati譯者 鄭柯 發佈於 2008年6月6日 上午4時8分
干擾，正如它名字所顯示的，是影響敏捷項目團隊速度、減緩其前進的剎車閘。有些干擾是必需的，其他則不是。關鍵在於：要識別出影響工作進程的干擾，並儘量減少它對項目的負面影響。
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
注：以上內容來自網絡，本人不承擔任何連帶責任
文章轉自：http://www.infoq.com/cn/news/2008/06/handling-interruptions