每個(gè)團(tuán)隊(duì)都必然會(huì)遇到工作被干擾的情況，如果不能合理應(yīng)對(duì)，那么很可能會(huì)影響到團(tuán)隊(duì)的交付能力。最近，在Agile Advice網(wǎng)站上，Mishkin Berteig發(fā)表了一篇文章，講述了當(dāng)Scrum或者其他一些采用迭代方式的敏捷團(tuán)隊(duì)遇到工作被干擾的情況時(shí)，可能可以采用的七種應(yīng)對(duì)方法。

• 嚴(yán)格遵循Scrum
• 安排特定的“干擾”時(shí)間段
• 讓變更商談過程變得透明
• 拆分團(tuán)隊(duì)
• 超短的交付周期
• 維持現(xiàn)狀，任勞任怨
• 承諾速率(Commitment Velocity)

Ken Schwaber和Jeff Sutherland在Scrum指南中明確地表示，團(tuán)隊(duì)要想獲得成功，就必須嚴(yán)格遵循Scrum。

Scrum的角色、工件、事件和規(guī)則是不可變的。雖然只實(shí)施部分的Scrum是可能的，但這樣就不是Scrum了。

因此，Mishkin認(rèn)為他的上述建議是對(duì)Scrum團(tuán)隊(duì)的一個(gè)開放式的補(bǔ)充。

Scrum方法論所秉承的基本理念是形成一套發(fā)現(xiàn)組織內(nèi)的問題和障礙的體系……改掉那些導(dǎo)致工作被干擾的行為，而不是試圖去尋找兼顧應(yīng)對(duì)干擾的一石二鳥之法。

現(xiàn)實(shí)中，很多敏捷團(tuán)隊(duì)在使用混合方式。而Mishkinr的文章正好指導(dǎo)團(tuán)隊(duì)利用一定比例的時(shí)間或者人員來應(yīng)對(duì)“不速之客”。

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

Mishkin文中所述的另一個(gè)應(yīng)對(duì)之策是使變更商談過程更加透明，此處他援引了“熒光卡片(fluorescent note card)”法。

無論何時(shí)，若有利益關(guān)系人想要打斷當(dāng)前周期內(nèi)的工作……就把他的需求寫在一張顏色鮮艷的卡片上，以便于區(qū)分團(tuán)隊(duì)當(dāng)前工作周期內(nèi)的其它任務(wù)。隨后，提需求的利益關(guān)系人就得和其他利益關(guān)系人商談……看看迭代中哪些任務(wù)可以移出去，為新任務(wù)騰地兒。

此方法和XP里應(yīng)對(duì)干擾的方法很類似，James Shore和Shane Warden在他們的敏捷開發(fā)的藝術(shù)：迭代計(jì)劃一文中就曾提及此法。

換句話說，如果你要加個(gè)兩個(gè)點(diǎn)的故事到計(jì)劃里，勢(shì)必要拿出個(gè)兩個(gè)點(diǎn)的故事來交換。并且，你只可以替換那些尚未開始做的故事。

Mishkin看來，最具綜合性的是承諾速率度量法，他將其解釋為一個(gè)團(tuán)隊(duì)燃盡圖的“最小歷史斜率(minimum historical slope)”。他闡述道，迭代團(tuán)隊(duì)都應(yīng)該降低每次迭代的期望速率，以切合他們上個(gè)迭代（而不是平均）所完成的實(shí)際點(diǎn)數(shù)。

隨著團(tuán)隊(duì)使用承諾速率度量法完成了越來越多的Sprint，最終他們的能力將與他們的承諾相吻合，即使時(shí)有“不速之客”，也能幾近閑庭信步，應(yīng)對(duì)自如。

其它可選方案還有超短的交付周期。InfoQ網(wǎng)站上有一段2008年敏捷大會(huì)的演講，詳盡涵蓋了這一內(nèi)容。還有就是任勞任怨、俯首甘為孺子牛，雖然這并不為作者所推崇。

如果你選擇了維持現(xiàn)狀，任勞任怨，那么最重要的是向大家展示你權(quán)衡利弊的心路歷程。明確告訴你團(tuán)隊(duì)中的每個(gè)人，你為何如此權(quán)衡，這么做的好處又在哪里。

如何處理被干擾的方法一直是敏捷社區(qū)數(shù)年來熱議的話題，自2008年以至更早，InfoQ上也發(fā)表了諸多相關(guān)文章。更多對(duì)策和選擇可以參見由干擾驅(qū)動(dòng)的開發(fā)、應(yīng)對(duì)緊急需求以及應(yīng)對(duì)敏捷項(xiàng)目中的干擾。

關(guān)于干擾對(duì)團(tuán)隊(duì)所造成的影響最恰當(dāng)?shù)臍w納，估計(jì)要數(shù)Mark Levison近期發(fā)表的Scrum Master系列故事了。

開發(fā)團(tuán)隊(duì)以外的人往往并不認(rèn)可團(tuán)隊(duì)為了應(yīng)對(duì)干擾所做的努力，尤其是無法理解任務(wù)切換要花的時(shí)間（如果在做一個(gè)復(fù)雜的任務(wù)，可能需要20到30分鐘才能跳出原來的思維）。

你的團(tuán)隊(duì)采用了這些方法中某個(gè)來處理干擾嗎，或者你是否發(fā)現(xiàn)其它什么技術(shù)更高效呢，例如看板？