應對敏捷專案中的干擾

干擾，正如它名字所顯示的，是影響敏捷專案團隊速度、減緩其前進的剎車閘。有些干擾是必需的，其他則不是。關鍵在於：要識別出影響工作程式的干擾，並儘量減少它對專案的負面影響。

 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個全職人員那樣始終坐在一起。兩個全職的人，基本上不需要什麼協調，也沒有多少溝通上的無謂消耗。

討論組的人都認為：要去除與這些主要的干擾相關的風險，應該從兩方面下手：犧牲一個人，讓他來處理所有的次要任務；還要注意不要讓一個人同時參加多個任務。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-567465/，如需轉載，請註明出處，否則將追究法律責任。