敏捷團隊應對打擾的七種方法

每個團隊都必然會遇到工作被干擾的情況，如果不能合理應對，那麼很可能會影響到團隊的交付能力。最近，在agile advice**上，mishkin berteig發表了一篇文章，講述了當scrum或者其他一些採用迭代方式的敏捷團隊遇到工作被干擾的情況時，可能可以採用的七種應對方法。

\

嚴格遵循scrum\

安排特定的「干擾」時間段\

讓變更商談過程變得透明\

拆分團隊\

超短的交付週期\

維持現狀，任勞任怨\

承諾速率(commitment velocity)\

ken schwaber和jeff sutherland在scrum指南中明確地表示，團隊要想獲得成功，就必須嚴格遵循scrum。

scrum的角色、工件、事件和規則是不可變的。雖然只實施部分的scrum是可能的，但這樣就不是scrum了。

因此，mishkin認為他的上述建議是對scrum團隊的乙個開放式的補充。

scrum方**所秉承的基本理念是形成一套發現組織內的問題和障礙的體系……改掉那些導致工作被干擾的行為，而不是試圖去尋找兼顧應對干擾的一石二鳥之法。

現實中，很多敏捷團隊在使用混合方式。而mishkinr的文章正好指導團隊利用一定比例的時間或者人員來應對「不速之客」。

……有兩種分配時間的方式：每天特定時間全軍上陣，或者輪流指派一到兩個人專門全天候應對被打擾的情況……原則上說，擠出來的這點寶貴時間一定要用在刀刃上，最好拔除那些誘發干擾的根源。

mishkin文中所述的另乙個應對之策是使變更商談過程更加透明，此處他援引了「螢光卡片(fluorescent note card)」法。

……無論何時，若有利益關係人想要打斷當前週期內的工作……就把他的需求寫在一張顏色鮮豔的卡片上，以便於區分團隊當前工作週期內的其它任務。隨後，提需求的利益關係人就得和其他利益關係人商談……看看迭代中哪些任務可以移出去，為新任務騰地兒。

此方法和xp裡應對干擾的方法很類似，james shore和shane warden在他們的敏捷開發的藝術：迭代計畫一文中就曾提及此法。

換句話說，如果你要加個兩個點的故事到計畫裡，勢必要拿出個兩個點的故事來交換。並且，你只可以替換那些尚未開始做的故事。

mishkin看來，最具綜合性的是承諾速率度量法，他將其解釋為乙個團隊燃盡圖的「最小歷史斜率(minimum historical slope)」。他闡述道，迭代團隊都應該降低每次迭代的期望速率，以切合他們上個迭代（而不是平均）所完成的實際點數。

……隨著團隊使用承諾速率度量法完成了越來越多的sprint，最終他們的能力將與他們的承諾相吻合，即使時有「不速之客」，也能幾近閑庭信步，應對自如。

其它可選方案還有超短的交付週期。infoq**上有一段2023年敏捷大會的演講，詳盡涵蓋了這一內容。還有就是任勞任怨、俯首甘為孺子牛，雖然這並不為作者所推崇。

……如果你選擇了維持現狀，任勞任怨，那麼最重要的是向大家展示你權衡利弊的心路歷程。明確告訴你團隊中的每個人，你為何如此權衡，這麼做的好處又在**。

關於干擾對團隊所造成的影響最恰當的歸納，估計要數mark levison近期發表的scrum master系列故事了。

開發團隊以外的人往往並不認可團隊為了應對干擾所做的努力，尤其是無法理解任務切換要花的時間（如果在做乙個複雜的任務，可能需要20到30分鐘才能跳出原來的思維）。

你的團隊採用了這些方法中某個來處理干擾嗎，或者你是否發現其它什麼技術更高效呢，例如看板？

\ 檢視英文原文：seven options for handling interruptions on agile teams