分散式 Scrum
David Starr 是 Scrum.org 的首席軟體大師，他致力於提升軟體開發業界的專業素質， 他也設立了線上技術社群 ElegantCode.com。
2012 年 7 月
分散式團隊經常苦無一致、及時且有效的溝通。 了解 Scrum 如何提供不同類型的容器，以供分散式團隊改善和成功。
Scrum 架構對分散式開發團隊隻字未提。 Scrum 不需要 Scrum 團隊的所有成員或甚至開發團隊成員在同一個辦公室、建築物、城市或時區工作。 Scrum 團隊會主動公開產能提升的阻礙，當溝通成為阻礙時，Scrum 使該項明顯可見。
當團隊成員不是親身合作時，團隊內部溝通必然更複雜，該團隊所建立的軟體也是如此。 在 1968 年，Melvin Conway 寫道：
從事設計系統的組織所設計的是組織本身溝通結構的翻版。
Conway 定律經證實不只是格言，而是在軟體開發團隊內可度量的動態。 一項研究藉由測量團隊分佈對系統架構可能的影響，示範了 Conway 定律作用。 當團隊成員是分散式時，軟體開發人員傾向於建立多個抽象層程式碼，將彼此隔離[1]。
概觀
在程式碼中看到團隊
Stella 是 Scrum 團隊的開發人員，該團隊對每個衝刺 (Sprint) 的趨勢預測，提供一致的工作。 她的團隊以建立高品質的軟體著稱，即使其他人讀取他們的程式碼時有點難以理解。
她在家工作，所在時區不同於其他團隊成員。 他們使用電子郵件、高成本的需求管理系統，而且偶爾透過視訊會議在每個衝刺 (Sprint) 中討論工作。 他們將每日 Scrum 滙報排程以配合每個人的排程，依規定使用 Scrum。 她透過電話參加計劃會議和每日 Scrum 滙報，看不到其他隊友說話時的臉部表情。 她也聽不到每個每日 Scrum 滙報前後其他人進行的對話。
Stella 立意良善，在程式碼中建立抽象層，因此她的工作更容易隔離和測試進度。 她的新抽象層將實作與已宣告且其他團隊成員可見的介面分隔。 此種插入式系統導致清楚脫勾的系統架構，她宣稱。「介面做為實作界限真是不錯的物件導向設計，」她提醒自己。 這個新外掛程式模型允許她在自己的程式碼區段中工作，並不會妨礙其他團隊成員在其他區域的工作。
如 Conway 定律所預測，程式碼現在反映她與其團隊的溝通方式：鬆散結合。 她的設計取代可能的團隊對話，而且系統變得不必要地複雜。 這種不必要的複雜性是她與其他開發團隊成員之間關係的鏡子。 這些決定最後會花公司更多錢，因為有更多行的程式碼，未來開發人員要了解更多的間接取值層級，而且需要更多的測試以證明抽象功能運作正常。
Stella 沒有做錯事。 實際上，她成功利用良好的物件導向設計做法，在系統中隔離問題區域。 可惜的是，所隔離的問題是她自己的溝通問題，而解決方案允許更少的溝通， 因為當她解決問題時，變更的系統是軟體。 處理這個問題更有效的方式可能是簡化開發團隊的溝通方式。
當團隊成員不共席交談，他們傾向於用更強烈和更正式的交談取代之。 主旨排入佇列並等候稍後討論，而不是對小型策略性決策進行快速有效率的討論。 通常，稍後討論永不實現。 更少的面對面溝通，意味著將溝通推入其他作業裡面，例如規格、工作票證或甚至程式碼。 ISomeInterface 存在的目的，是為了掩蓋建立這些介面之團隊的功能失調。
團隊分佈意外的複雜度
在 Scrum 團隊之外所做的決定最有可能增加複雜度。 軟體開發團隊在其撰寫或工作上很少是簡單的，而 Scrum 為 Scrum 團隊提供一個可以操縱以減少複雜度的界限。 即使如此，相較於擺在開發團隊眼前的組織文化特性和程序，實際撰寫程式碼和交付軟體的複雜度有時相形見絀。
因此，Scrum 團隊包含不同時區的成員，這項組成很少是由工作者自己所決定。 建立分散式 Scrum 團隊的決策可能基於領導者想要集結高技能專家的團隊，或者 (更可能) 嘗試透過聘用外地約聘員工，花費更少錢開發軟體，以降低生產成本。 雖然這些模型可能會減少軟體開發的初始成本，它們通常未能考慮到持續性的維護成本，以及為配合開發團隊勉強溝通所增加的複雜度。
不論建立分散式團隊的原因或方式，這是不爭的現實，而且沒有消失的跡象。 即使在分散式團隊的情況下，Scrum 仍然是管理交付軟體產品規劃和執行的優良架構。 團隊成員只是必須更努力一些，改善現有的溝通管道，並防範如同上述範例說明的局部最佳化。
分散式現實
分散式團隊可以提供雇主找到優秀人才的機會，不論居住地多遠，或者某些員工得以選擇居住地，而不以公司總部駐地為中心。 雖然反駁分散式團隊很容易，委外、內部徵才、鄰近徵才 (Near-Sourcing) 和鄉村徵才對許多組織仍然有相當大的經濟需求。
《Scrum 指南》發表於 Scrum.org，制定 Scrum 理論，是應用 Scrum 架構的規則集。 雖然《Scrum 指南》對分散式團隊的問題沒有著墨，也未提供特別對應的指引，Scrum 倒是會突顯團隊成員必須透過電子裝置當做溝通橋樑才能交談的溝通落後和浪費時間問題。
溝通，信任為重
人們彼此交談大部分都是透過身體語言所溝通。 在設計討論時透過觀察人所收集的資訊，可能與在白板上抄寫的資訊一樣重要。 因此，縮小分散式工作者之間溝通落差的焦點多半涉及克服身體語言障礙。
Steve McConnell 寫道「信任的半衰期大約為 6 週」。[2] 這個論述表明，開發人員每天工作且共同作業，會發展互信關係。 如同任何關係，信任的程度不同，但是當隊友經常見面且合作時，信任的可能性最高。
當隊友停止每天見面且不在近距離工作約六週後，信任關係程度大約是從前的 ½。 隨著更多時間消逝，剩餘的信任程度會迅速地減少。
這不表示相關人員沒有正面的相互尊重，而是失去信任和團隊有效性。 沒有信任，共同作業會減少，而且隊友間的界限會增加。 這些界限通常會反映在程式碼上。
攝影機、電話會議、Instant Messenger、視訊聊天、畫面共用和其他共同作業工具有助於縮小隊友間的溝通落差，而且這類工具必須像空氣一樣普遍存在，才能提高分散式團隊的生產力。 經常的視訊溝通對重建信任基礎大有幫助。
無論使用任何工具，分散式團隊可以利用高畫質視訊溝通的機會，提高其有效性。 簡言之，現場聲音優於 Instant Messenger，後者優於電子郵件，依此類推。 將互動間隔時間減少會更佳。
分離程度
團隊成員透過許多方式彼此分隔，而且團隊分佈有些常見的週期性模式。 如同在其他環境中的模式 (例如軟體設計)，團隊分佈模式可能會刻意或意外發生。 意外模式是對現有壓力的無意識因應，而刻意模式則是為了控制複雜度有意識的實作。
這裡說明的分散式 Scrum 模式可能是規定或意外的。 這些模式可能是在 Scrum 團隊之外所做的決定啟發，或者可能由於 Scrum 團隊對特定問題的自治組織所導致。 不論存在原因，下列分佈模式在真實環境中普遍常見。
「遠端開發團隊」一起共事，但是與公司的其餘部門實體分隔。
在「遠端團隊成員」模式中，單一團隊成員與其他團隊成員在不同位置工作。
在「分散式團隊」，個別團隊成員在自己的位置上朝共同的工作目標邁進。
遠端開發團隊
某些開發團隊在地理位置上與其總公司分隔，甚至更糟的是，與其產品負責人分隔。 當某家公司併購另一家公司時，或當兩家公司合併時，這是常見的現象。 如果開發團隊必須是遠端，Scrum 是管理該團隊工作以及與總公司溝通的理想方式。 如今許多團隊使用這個公式致勝。
雖然狀況不同，遠端開發團隊經常感覺被剝奪權利、低估，而且與主要組織斷絕關係。 遠端團隊成員可能感覺受到總公司忽略及異化，而總公司可能 (通常無意) 認為該遠端團隊比位於公司總部的內部團隊較不重要。
這些遠端開發團隊不斷找原因、藉口和機會，而不將其工作與其他團隊的工作整合。 這個衝刺 (Sprint) 的整合為何不重要、非必要或不可能，輕易就能辯解。 開發團隊怨氣增生，因此將整合程式碼與總公司的要求視為「不合理」、「與我們的現實脫節」、「非必要」或「對我們的需要無感」。
無論以上印象皆是或皆非並不重要。 遠端開發團隊在了解自身價值時，需要感覺被總公司聽見和了解。 在遠端服務時，人們很容易忘記小我是大我的一部分。
Scrum 隊長與開發團隊在不同位置工作，注定失敗。 Scrum 隊長無法從遠端有效地執行指導、協助有效 Scrum 事件，以及管理 Scrum 本身等任務。 開發團隊和 Scrum 隊長之間的距離妨礙溝通，並將太多風險導入 Scrum 團隊。 信任需要熟悉，而且高度互信是 Scrum 成功的基礎。
Scrum 隊長與其開發團隊在相同的位置工作。
為了讓開發團隊對其產品負責人提供良好的服務，也需要無障礙且清楚的溝通。 產品負責人在每個衝刺 (Sprint) 中必須可供開發團隊諮詢，以回答問題和提供有關工作進度的意見。 雖然在遠端情況下頻繁互動是可能的，但是必須建立可靠方法來維護這個溝通方式。
缺席的產品負責人是 Scrum 團隊遇到的最大破壞力之一。 受冷落的開發團隊被迫對功能和優先權做決定。 這個群組通常最不能夠決定功能好壞，因為他們通常比產品負責人較少被告知客戶的需要。
產品負責人在整個衝刺 (Sprint) 中關心開發團隊並提供意見。
可惜的是，缺席或不常在辦公室的產品負責人是 Scrum 團隊常見的功能失調症狀，即使在共處一室的環境中。 為了讓 Scrum 實現潛能，Scrum 團隊必須當做有凝聚力、信任感且協同的單位運作，而且這需要盡責的產品負責人付出關心。
遠端團隊成員
某些開發人員與其他隊友分隔，後者本身共處一室，在共用位置中一起工作。 典型的範例是在家工作的開發人員，在家庭辦公室中盡責地與團隊一起工作。 雖然這項安排的原因不同，它變得逐漸普遍。
Alistair Cockburn 創造「滲透式溝通」(Osmotic Communication)[3] 新詞，以識別在小組室內的內在溝通類型。
滲透式溝通表示，資訊流入團隊成員的背景聽覺，因此他們會拾取相關資訊，就像透過滲透作用。這通常是透過共處一室來完成。然後，當有人提出問題時，在這個房間裡的其他人可以洗耳恭聽或跳過不聽，加入這項討論或繼續執行其工作。
滲透式溝通不限於軟體開發團隊。 大型報社或媒體編輯部的訪客通常會發現此動態在作用中。 甚至是全球各地警察局的刑事組室在調查罪行時，也會使用小組室以提高共識。
失去滲透式溝通就是在團隊內失去環境意識。 當軟體開發人員在進行變更時不知道隊友對軟體的變更，團隊中會失去凝聚力和共同脈絡。 不中斷、專心和遠端的團隊成員聽不到小組室空氣中瀰漫的金石良言。 她因此被排除在即席設計討論以及特定一天自然流暢地發生的其他決定之外。
更快速交付軟體且版本之間更短時間間隔的這個趨勢，要求開發團隊更高的環境意識。 對於不存在於小組室的遠端團隊成員，根本失去環境意識。
為了解決這個問題，擬真視訊會議系統 (Telepresence) 解決方案變得更普遍。 使用低成本的膝上型電腦、攝影機和喇叭，可以建立簡單的擬真視訊會議系統解決方案。 在小組室裡架設這個系統，只要遠端開發人員一整天保持溝通管道開啟，即可維持暢通的溝通管道。
視訊和電話會議有助於減少身體語言障礙。
遠端開發人員掙扎成為團隊一份子的跡象：
使用打字溝通方式如電子郵件訊息或 Instant Messenger，討論複雜問題。
在程式碼中定義固定介面做為合約，而不是與其他開發人員定期討論。
在版本控制中想要私用或個人的程式碼分支。
當縮小遠端開發人員和其他團隊成員之間的溝通落差時，定期造訪非常有用。 視訊通話比打電話好。 打電話比打字好，而依賴電子郵件則是注定發生災難。
分散式團隊
在真正的分散式 Scrum 團隊中，每個人合作，朝共同的衝刺 (Sprint) 目標邁進，而且每個團隊成員在不同位置工作。 原型範例是來自世界各地參與者的開放原始碼專案。 雖然溝通問題顯著，這個模型經證實有效。 這類團隊的溝通必然有挑戰，但是隨著技術繼續減少身體語言障礙卻變得更為普遍。
當團隊成員在不同位置時，對於進行關於設計和程式碼的有效交談，畫面共用軟體是非常重要的。 關於程式碼，除非交談雙方看到相同的事物，否則討論包含太多假設。 所幸，畫面共用軟體隨手可得且高效。 未共處一室的團隊成員應該一天數次與隊友共用畫面。
畫面共用是非常有效的配對和共同作業工具。
找藉口一起檢查程式碼、待處理項目 (Backlog) 或其他成品，是讓分散式團隊保持高度環境意識的好方法。 另一個有效的技術是為衝刺 (Sprint) 中任何交付項目加入簡單的驗證規則。 兩部分的規則如下：
每一個項目必須在整合環境中驗證後才視為完成。執行驗證的人員不能是完成工作者。
採用這個簡單規則的開發團隊會對整個團隊所完成的工作有更大的共識。
**作者的附註：**我曾經與一個開發團隊共事，其成員在同一個建築物，但在不同的辦公室工作。提供私人辦公室給所有員工是該公司引以自豪之物。開發團隊最後決定建立虛擬小組室，每個團隊成員可以使用攝影機、麥克風和喇叭，現身在其中。虛擬小組室一直保持開啟，而且團隊成員會在處理共用的產品時進入這個小組室。在短時間之後，團隊變得讚賞這個虛擬小組室。他們開始使用畫面共用軟體，檢視彼此的畫面，而不走下樓，因為這樣更快速。團隊開始整天使用虛擬小組室，即使辦公室只是一牆之隔。最後，其中一個團隊成員嘗試幾天不進辦公室，而在家工作。在衝刺 (Sprint) 追溯性會議期間，開發團隊一致同意，有了虛擬小組室，成員在隔壁辦公室或在家工作變得無關緊要。虛擬小組室證實自己比個別的辦公室更有價值。
工具和做法
敏捷式軟體開發團隊使用低科技和高畫質視訊工具來管理工作，總是被小題大作。 當地理分佈或多個開發團隊的複雜度加入混局時，類比索引卡和馬克筆當然不比軟體解決方案縮放自如。 這導致市面上充斥著特別為 Scrum 或敏捷式軟體開發團隊所設計的工作管理工具，許多工具廠商基本上承諾「我們的工具可讓您敏捷」。
工具與做法混為一談
當然，工具無法讓團隊達成「敏捷」。 真正的敏捷性來自軟體製造及提供者的文化、態度和行為。 因此，敏捷式軟體開發宣言[4] 表示「個人與互動重於流程與工具」。
敏捷式軟體開發社群的通俗名言是「人重於流程，流程重於工具」。
實用主義者的通俗名言是「工具設定規則」。
這兩個格言說明人們與其溝通、共同作業和工作管理軟體之間的關係。 工作追蹤工具應該用來減少溝通和理解的複雜度，但是也可能會發生恰恰相反的結果。 例如，人們落入非必要回報缺失的窠臼，而非加以修正，並非不常見。
**作者的附註：**如需有關如何在工具、流程和做法之間尋求平衡的絕佳資源，請參考 Kent Beck 的白皮書提供敏捷性的工具。Beck 在 2008 年撰寫此文，如今一樣有獨到的見解。
當工作或功能追蹤系統中的資料未更新時，Scrum 隊長和開發團隊成員喜歡抱怨「工具已經過時」。 這漠視您憑直覺就可以知道的答案：
目標是讓團隊保持最新狀態，而不是工具。有時候工具可以幫助達成此目標。
Scrum 特別設計來提高 Scrum 團隊的環境意識。 Scrum 對需求、會議記錄、工作分工、估計單位或時間追蹤的格式沒有著墨。 團隊可能認為這些事物很有用，可以在 Scrum 工作脈絡中使用。 但是，團隊應該在 Scrum 之外，而不是因為它，而使用這些額外的做法。
使用工具支援做法
但願 Scrum 團隊所使用的任何工具選擇，是為了支援在工具之前已選取的做法。 也就是，健全的 Scrum 團隊有意改善。 這麼做意味著，因為團隊希望在某個區域有所改善，所以選擇嘗試新做法或技術。 在嘗試這些基本面之後，可以使用工具支援新的做法。 簡言之：
首先選擇優秀人才。做為自治組織的團隊，他們會選取自己的做法，最後會選擇工具來支援所選的做法。重視人更勝於流程，重視流程更勝於工具。
(如需可用來支援您做法的 Microsoft Visual Studio 2012 工具的詳細資訊，請參閱 Visual Studio Online 歡迎入口網站的共同作業 (更深入的探究) [重新導向]、共同作業 [重新導向]和學習一節。)
團隊成員合作方式對他們建立的軟體有不可否認且明顯的影響。 當溝通很容易和有效時，產生的軟體設計會予以反映。 相反地，當團隊掙扎進行內部溝通或與其服務對象溝通時，團隊產生的軟體會反映團隊所遇到的阻礙。
Scrum 的定期檢查和調適週期對分散式環境中的團隊大有幫助。 Scrum 規定的事件會強制進行溝通，但不一定影響溝通採取的形式。
共現的小組室仍然是團隊協同建立複雜軟體，最低科技、最高畫質且最有效的方式。 但是，遠端團隊已在此生根。 無論基於個人情況、經濟效益或缺少遠見，越來越多 Scrum 團隊面臨團隊成員分散各地的工作情況。
顧及團隊溝通，超越實體界限，會造就更高品質、更少混淆、更快速的產量和更幸福的個人等紅利。 當團隊的工具和做法得到仔細考量時，分散也可行， 甚至還相當好。
參照
Herbsleb, 1999.《架構、協調和距離：Conway 定律和超越》(Architectures, coordination, and distance: Conway's law and beyond)。 IEEE Software, 7
McConnell, S. (2009). ＜出差限制和離岸開發＞(Travel Restrictions and Offshore Development)。
Cockburn, A. (2008). ＜滲透式溝通＞(Osmotic Communication).
眾人。 ＜敏捷軟體開發宣言＞(Agile Manifesto)。