使用敏捷軟體流程進行離岸開發

使用持續整合避免整合頭痛

我聽過幾個關於整合跨多個地點團隊工作時所遇到的問題。即使在定義介面時非常小心，整合問題仍然會不斷出現。這通常是因為很難正確指定介面的語意，因此即使您擁有所有正確的簽章，您仍然會對實作實際上將執行的假設感到困惑。

在 Thoughtworks 真正開始執行的最早 XP 實務是持續整合，我們已經非常習慣它，因此我們決心將它用於我們的離岸開發。因此，從一開始，我們就將每個人放在單一程式碼庫上，並執行 CruiseControl 來建置和執行測試。這樣，每個人都可以接近主線，無論他們在哪裡。

每個人都對這種方法的運作方式感到非常滿意。它的主要好處是困擾其他整合群組的問題根本不會發生在我們身上。持續整合和測試程序會非常快速地解決許多整合問題，因此可以在它們變得難以找到之前修復它們。

CruiseControl 的網頁允許所有網站看到國外正在發生什麼事。早上第一件事，您可以查看 CruiseControl 網頁，看看其他網站做了哪些變更。它提供一種輕鬆的方式，讓您了解世界另一端正在發生什麼事。

這確實需要良好的建置紀律，其中開發人員努力不中斷建置，並在中斷時立即修復。一般公認的做法是，如果您對主線提交變更，您不應在收到來自 CruiseControl 的電子郵件訊息，表示您的變更已成功建置之前回家。當遠端辦公室執行相同的建置時，深夜的錯誤建置會嚴重得多。

儘管全球持續整合廣受歡迎，但我們遇到了一些問題。通訊管道並不像我們希望的那麼寬廣且可靠，因此許多原始碼控制操作可能會從遠端網站變得尷尬。一般來說，我們將建置伺服器與大多數開發人員放在同一個網站中，但遠端網站可能會發現從主線取得最新更新需要很長一段令人討厭的時間。通訊線路越長，它們越容易發生從故障到線路中斷一段時間的任何問題。讓儲存庫 24 小時可存取會讓執行備份時無法存取而令人討厭。所有這些問題都會因叢集式程式碼儲存庫而減輕，但我們尚未嘗試過類似的任何東西。

我們發現某些原始碼控制系統特別容易進行漫長且痛苦的簽出，特別是如果它們沒有設定好。花時間尋找方法來加快簽出時間是值得的，而且如果您使用無法很好地處理遠端工作的系統，確實可以變更原始碼控制系統。

（有趣的是，人們假設這些通訊問題特別是像印度這樣的遠端網站的問題，但我們發現問題也經常發生在西方的基礎設施中。持續整合需要良好的連線，通常比人們習慣的連線更好。）

然而，即使擁有最佳連線性，如果系統需要鎖定在岸防火牆內的服務，也可能會出現問題。您需要為這些服務建立良好的 測試替身，才能在開發環境中有效地測試系統。

讓每個據點派遣大使到其他據點

正如我上面所說，敏捷方法強調面對面人類互動的重要性。即使無法讓所有人共處一地，讓一些人移動明顯有很大的幫助。從一開始，我們就決定確保美國團隊隨時有人在印度，以利於溝通。這樣的代表已經認識美國的人員，因此加入他的個人人脈，以幫助所有人溝通。

我們現在已將此擴展到多個層級。我們發現派一位美國開發人員和一位美國分析師到印度，在技術和需求層級上進行溝通，很有用。讓印度團隊有人到美國團隊也很有價值。機票費用很快就能在改善溝通方面得到回報。

離岸團隊中以業務為導向的代表的好處之一，是它有助於向離岸團隊提供業務背景。僅根據需求清單建置軟體會遺漏許多業務背景 - 開發人員會被告知要執行哪些工作，但不會被告知為何重要。為何通常在適當地執行哪些工作方面有很大的影響。

代表工作中的一個重要部分是傳達八卦。在任何專案中，都有許多非正式的溝通。雖然其中許多並不重要，但有些卻很重要 - 而且麻煩的是，您無法分辨哪些重要哪些不重要。因此，代表工作的一部分是傳達許多看似不重要到不足以使用更正式的溝通管道傳達的瑣事。

我們通常每隔幾個月（在某些情況下每隔幾週）輪換代表，因為如果代表在國外待太久，他們就會失去與家鄉的聯繫。這讓代表更容易，因為他們不想離開太久。它也讓更多人能透過擔任代表來認識遠端團隊。在選擇代表時，非常重要的是要注意個人的需求和偏好。有些人不想離家數千英里待好幾個月，所以他們不應該擔任代表。

我們也發現專案經理花一些時間擔任代表很重要。專案經理的工作大部分是協助解決衝突，並在問題變得嚴重之前將其解決。在電話線兩側工作經驗對他們有效地執行這項工作真的很重要。

大使是建立信任和跨線融合的重要部分。因此，在專案的早期階段就派遣大使至關重要。如果一個專案在沒有大使的情況下執行一段時間，就會產生誤解和不良感受，而這些問題需要大量的努力才能解決。大使可以降低這種風險，但需要在問題開始出現之前就派駐。

使用實地拜訪建立信任

大使是半永久性人員，會在「其他」地點待上幾個月。這很重要，但還不夠。還需要有進一步的聯繫，涉及更廣泛的人員。這些訪問有助於建立和維護遠程溝通有效運作所需的關係。

您可以想到兩種聯繫訪問：播種訪問發生在專案的早期，旨在建立關係，而維護訪問有助於維持關係。

播種訪問應規劃在專案的早期，並且時間應相當長 - 最少兩週。播種訪問應為工作行程非常重要，因為重點在於讓人員習慣彼此合作，因此應圍繞一些共同任務進行安排。

• 派遣一些在岸客戶和專案經理到離岸地點，以建立初始發布計畫。
• 讓離岸分析師上岸，參與早期的需求收集會議。
• 讓一些在岸開發人員拜訪離岸團隊，讓離岸團隊第一次與現有程式碼庫合作。
• 讓離岸團隊拜訪在岸地點 - 尤其是在客戶端時。

無論原因為何，請記住訪問的主要目的是建立工作關係，而不是執行任務。這些事情常見的錯誤是將太多任務塞進訪問中，以至於沒有時間進行重要的溝通。因此，請保持輕鬆的工作步調，並且不要害怕安排一些非正式行程，讓主人可以向訪客展示周圍環境並進行一些非正式聯繫。與主人共進晚餐和觀光通常是訪客可以進行的最有用的活動。

盡快進行播種訪問非常重要。在沒有良好的人際關係下，您可能會因溝通不良和缺乏信任而遇到問題。這些問題將需要大量的精力來修復，並且很容易對專案造成永久性的損害。因此，提早播種以避免這些問題。

如果您從一開始就在多個地點有開發人員，播種訪問的一個特殊變體非常重要。在這種情況下，讓開發人員，或至少是資深開發人員，共同建立前幾個迭代非常重要。在這些迭代中將做出關鍵的架構決策，在此期間保持接近非常重要。否則，您可能會遇到不同的團隊做出不同的決策，或一個團隊做出另一個團隊不了解的決策。

完成播種後，應使用較不頻繁的維護拜訪來保持聯繫。這些拜訪可以較短，但應頻繁進行，每隔幾個月拜訪一次為最少次數。同樣地，這些拜訪應專注於必要的任務，其中一項可執行的良好任務為回顧。若您察覺團隊間有溝通問題，或是有重大問題發生，請不要害怕進行較長且較頻繁的拜訪。我們注意到，若系統設計有重大變更，進行較長的聯繫拜訪會特別有用。

禮物，尤其是能幫助傳播文化的禮物，總是值得帶的。我們特別喜歡人們帶一些零食或糖果作為禮物，這些零食或糖果是遠端地區的特產。

不要低估文化變遷

將敏捷方法導入組織中最困難的部分之一，就是它所造成的文化變革。事實上，我們發現這是組織在採用敏捷方法時遇到問題的主要原因。許多公司採用命令與控制模式運作，假設資深人員做出決策，而較低層級的人員執行決策。若要讓敏捷方法發揮作用，執行者需要有更多自主權和決策權。

我們發現這在西方公司是一個大問題，但這個問題在亞洲被放大了，因為亞洲文化強化了對上級的尊重。（我從一家大型印度承包公司看到的訓練課程將管理定義為「控制科學」）。在這種環境中，人們常常被勸阻提出問題、討論問題、警告不可行的期限，或提出替代方案以回應上級的指示。

西方團隊需要提防這種傾向，並在察覺東方團隊被動同意時提出反對。請注意，禮貌的接受通常表示有一個重要的問題沒有被討論。此外，西方團隊需要提防聽起來具有權威性，因為這會強化這種情況。

這方面的壞消息是，讓團隊變得更積極主動是一場艱難的奮戰，而且勢必會花費很多時間。您永遠不能假設問題會被提出，即使問題已經被發現。讓人們習慣分散控制的管理風格，會花費比您想像中更長的時間。

但也有好消息。一旦人們意識到他們有做出決策的自由和責任，他們似乎會非常享受。我們有幾位印度團隊成員告訴我，他們在其他公司的朋友無法相信他們被賦予了多少自主權。這種自主權是一個很大的激勵因素，讓人們既能提高生產力，又能承擔更大的責任。離岸團隊成員獲得了信任和理解，可以做出決策，而不是等待在岸團隊，這導致了很多延誤。對我來說，我們將會發現的最有趣的事情之一，就是這種文化影響在亞洲和西方產生的長期影響。

播種拜訪在此扮演重要角色。如果人們有良好的個人關係，他們更有可能提出問題。

即使談論這些文化問題也可能造成問題。一些 (西方) 產業分析師在看到本文草稿時表示，此部分有失尊嚴且具攻擊性。我們在班加羅爾的一位開發人員表示，我太過溫和。另一位則表示這是一個問題，但質疑它是否比許多西方公司更糟。但似乎有一些共識，即亞洲存在加強指揮和控制的文化力量，而且這正在改變。

（這對 Thoughtworks 來說是一個特別尖銳的問題。我們有明顯的反權威態度，即使在美國也很引人注目。我們從一開始就決定在印度保留相同的文化。我很高興地說，我們似乎確實成功了。）

使用 wiki 儲存共用資訊

我們嘗試了各種方式來保存共同資訊，到目前為止我們最喜歡的是 wiki。Wiki 很容易使用，可以使用任何瀏覽器，而且設定簡單，因此很實用。

任何常見資訊都可以放在那裡，故事卡、設計指南、建置說明、進度筆記 - 任何需要寫下來供團隊參考的東西。我們發現使用許多 wiki 所具備的變更通知功能非常有用，這樣頁面變更會透過電子郵件或 RSS 饋送觸發通知。

Wiki 本質上是沒有結構的，這種缺乏結構是好處的一部分。隨著專案的發展，團隊通常可以在 wiki 上發展自己的結構。這表示需要有人擔任園丁，以確保它不會長滿雜草。

使用測試腳本協助了解需求

距離越遠，您就需要在溝通需求時進行更多儀式。我們已經能夠做到這一點，同時仍然堅持我們在單一地點開發中使用的許多技術。

我越來越發現，較成熟的 XP 團隊使用驗收測試作為溝通需求的方式。此類團隊在迭代開始前就寫好測試腳本，以幫助釐清需求，並為開發團隊提供具體的目標。一種行之有效的方式是，讓一位美國客戶撰寫簡短的敘述 (幾頁) 來充實一項功能 (XP 術語中的故事)。然後，一位印度分析師/測試人員為這個故事建立測試腳本。這可以針對自動或手動測試來執行，儘管我們非常偏好自動測試。在開發腳本時，美國和印度分析師透過電子郵件和即時訊息以及定期 (每週 2-3 次) 的電話會議協調，以檢閱測試腳本。

我們發現這對印度分析師和美國客戶了解需求很有幫助。寫出測試會迫使印度分析師真正了解需要什麼，並在問題出現時向美國客戶提問。開發人員發現向印度分析師提問比鑽研測試腳本更容易，因此擁有印度分析師/測試人員仍然很重要。搜尋引擎很好用，但人類通常更容易合作。

我們發現此技術最大的問題是讓客戶人員參與其中。因此，在大部分專案中，我們無法做到這一點，但當我們做到時，我們發現這種方法很有價值。

使用定期建置取得功能回饋

當人們考慮敏捷方法中的需求收集時，他們常常看不到回饋迴路的 важность。需求流程通常被視為分析師提供需求，開發人員則會去實作。在稍後的某個時間點，有人會檢查開發人員是否實作他們被要求的內容。在敏捷專案中，客戶與開發人員之間的密切關係讓客戶可以更頻繁地監控進度，這讓他們可以更快速地發現誤解。此外，部分開發的系統也可以教育客戶，因為所要求的和所需要的之間通常有差異，而且通常在有可用的軟體之前，這是不明顯的。

定期進行整合建置讓美國客戶可以拉取昨天的工作並試用。雖然這不像共同定位那麼立即，但仍然讓客戶可以快速修正任何誤解；以及讓他們可以精進自己對需求的了解。

要讓這項工作順利進行，找出環境問題至關重要，以便在海洋兩側適當地複製環境。沒有什麼比岸上人員拉取建置、發現問題，而離岸人員因為環境組態問題而無法複製問題更糟的事了。確保環境問題在早期就已解決，並確保有人可以解決出現的任何環境問題。

確保人員定期查看已建置的內容，即使它只是部分功能。有人越快查看工作成果，他們就能越快發現任何溝通不良。通常人們喜歡等到某件事完成後才向其他人展示。然而，在這些情況下，這並不值得等待。

Scrum 長期倡導開發團隊在每次迭代結束時向客戶進行展示。我們現在已經廣泛採用這種做法，我們稱之為展示。對於遠程團隊，我們喜歡進行遠程展示，由離岸開發人員借助遠程桌面軟體展示軟體中的新功能。讓遠程團隊執行此操作是利用每個機會在離岸和在岸之間以及開發人員和客戶之間建立聯繫的另一個範例。

使用定期簡短狀態會議

敏捷方法提倡為整個團隊舉行定期的簡短狀態會議（Scrum 中的 Scrum，XP 中的站立會議）。將此方法應用於遠程小組非常重要，以便他們可以與其他團隊協調。時區通常是這裡最大的問題，特別是在美國和印度之間，任何時間對某人來說都很尷尬。在我們早期的專案中，我們發現每週兩次的站立會議似乎運作良好，並提供了足夠的協調。

在我們最近的專案中，我們更多地使用了 wiki，這減少了跨岸站立會議的需求。現在，我們在岸上團隊內部進行站立會議，但不在不同的岸上之間進行。然而，我們確實會進行每日跨岸會議，但這些會議不涉及整個團隊，只涉及那些專注於跨岸協作的人員。然而，對於小團隊，我們確實會進行跨岸站立會議。

我們發現，以當地新聞閒聊開始電話會議是一個好習慣。當地色彩的最新奇特片段（政治、體育、天氣）有助於雙方了解電線另一端更廣泛的生活背景。（我認為這對除了我們這些書呆子之外的任何人來說可能都是顯而易見的，當人們高度任務導向時，很容易忽略我們生活的更廣泛背景。）

由於時區問題，雙方在選擇通話時間時都必須做出讓步。我們的客戶之一只會在他們的營業日進行通話，這迫使印度人必須在非常尷尬的時間上班。將所有負擔都推給一方來適應無助於順利協作。

這種缺乏知識或考量的問題也延伸到其他領域。一個專案在印度節日排燈節期間安排了一次重大發布，這相當於要求美國團隊在感恩節期間工作。幸運的是，我們說服他們更改日期。即使在不太嚴重的情況下，也要記住假期很少是共同的，因此你經常會遇到一方處於假期模式而另一方處於正常工作週的情況。

使用短週期迭代

一般來說，敏捷方法使用比許多其他迭代方法更短的迭代。在 Thoughtworks，幾乎所有專案都使用為期一或兩週的迭代。一些更有經驗的印度開發人員曾在使用兩到三個月迭代的地方工作，他們報告說較短的迭代要好得多。

幾年前，我們的分散式專案傾向於偏好兩週的迭代，因為他們發現使用較短的迭代很困難，但這已經改變了。現在我們已經學會如何在分散式專案中舒適地進行一週的迭代。

使用專為遠端據點量身打造的迭代規劃會議

在我們的大多數專案中，我們發現每次迭代開始時舉行的規劃會議，讓整個團隊參與其中，真的有助於讓每個人在下一部分工作中協調一致。我注意到我們的大多數專案都提出了自己的迭代規劃會議 (IPM) 變體，以適應當地情況。（這種自我適應是敏捷流程的重要組成部分。）

遠端團隊增加了自己的一組約束，特別是在您有尷尬時區問題時。然而，儘管尷尬的會議時間令人痛苦，我們仍然發現 IPM 非常有用。

在 IPM 之前，美國客戶會為每個預定的功能（故事）傳送敘述，我們希望在 IPM 之前將其轉換為測試腳本。在此期間，任何問題都透過電子郵件處理。在 IPM 之前，開發團隊會將功能分解為更精細的任務。這些任務分解與美國團隊分享以取得回饋。

所有這些前期工作縮短了電話會議，現在電話會議專注於任務分解中出現的任何問題。我們發現電話通常持續約半小時到幾個小時。保持實際電話會議簡短很重要，因為這類遠端會議特別艱難。

移動程式碼庫時，錯誤修正是一個好的開始

我們的兩個專案涉及採用一個大型（數十萬行程式碼）程式碼庫，並將程式碼庫的實質性開發移轉到班加羅爾實驗室。在這兩個專案中，印度團隊在開始新增新功能之前，先進行了幾次錯誤修正的迭代。

從錯誤修正開始，讓印度團隊在對程式碼庫進行大量工作之前，先熟悉程式碼庫，因為錯誤修正涉及更多程式碼閱讀，而不是變更。雖然這很有效，但有些人擔心經驗豐富的人可能會認為只進行錯誤修正是一種恥辱。雖然有些人可能認為這是一個問題，但我相信處理錯誤修正或非常局部化的功能變更，是熟悉大型新程式碼庫的最佳方式之一。

錯誤修正的溝通性質也可以讓它成為與離岸團隊合作更輕鬆的活動。在岸團隊可以花一整天描繪錯誤的詳細資訊，這些資訊可以傳達給離岸團隊，並在在岸團隊的夜晚進行處理。然後，在岸團隊可以在隔天檢閱修正。我必須強調，由於溝通困難，這並不比讓現場團隊修正錯誤更有效率，但這可能是與離岸團隊合作的較不複雜的方式。

依功能而非活動區分團隊

大部分關於在岸/離岸邊界的傳統思考是基於人們的活動。因此，分析和設計是在岸進行，施工是在岸進行，驗收測試是在岸進行。這顯然很適合瀑布模型。

我們發現與此相反，當我們讓離岸團隊處理盡可能多的活動時，事情會有所改善。因此，我們希望看到他們盡可能多地進行分析和設計，但前提是需求來自在岸。當我們將工作分配給在岸和離岸開發團隊時，我們會根據功能而不是活動來進行分配。我們將系統分解成廣泛的模組，並讓離岸團隊處理其中一些模組。然而，與大多數這樣做的團隊不同，我們不會花很大的力氣來設計和凍結這些模組之間的介面：持續整合和弱程式碼所有權允許模組介面在開發過程中不斷演進。

其中一個重要部分是擴大離岸團隊的分析師部分。開發人員所在的地區越了解業務，開發團隊就能更有效率地開發。開發人員不必等到隔天才能得到問題的答案，而是可以馬上得到答案 - 這消除了進展的阻礙。所有這一切意味著你必須專注於提升離岸分析師的業務知識。這需要時間，但當地知識是在岸業務知識的重要對應物。

這的推論是不應橫向分割團隊（讓一個團隊負責簡報，另一個團隊負責資料庫）。一般來說，我偏好功能性員工組織 - 而遠程團隊會加劇因層級而分割團隊的問題。

這裡要記住的最重要的事情是康威定律的主導力量 - 系統的結構將反映建立它的團隊的結構。這意味著按模組分割分散式團隊非常重要，這些模組應盡可能鬆散耦合。

預期需要更多文件。

敏捷方法淡化文件，因為觀察到大部分文件工作都是浪費的。然而，由於面對面的溝通減少，因此文件在離岸開發中變得更加重要。這項工作在某種程度上是浪費的，因為如果整個團隊都在同一地點，就不需要它。但由於離岸模式，你需要執行它們 - 所以它們是離岸做事的一部分代價。這是人們撰寫它們的時間代價、因為人們從文件中理解很多事情更困難而增加的時間，以及人們使用它們時感到沮喪的代價。

除了文件之外，您還需要更多積極的協作工具：wiki、問題追蹤工具等。整體而言，似乎經常最好偏好於施加較少結構的工具，這樣團隊可以更適合地將它們融入他們想要的工作方式（wiki 可以運作得如此良好的原因之一）。

我總是建議團隊將文件檢查到版本控制系統中，以便人們可以輕鬆取得最新資料。當您從事遠端工作時，這特別重要。

無論是文件或任何其他內容，請記住，其他人的範本對您不起作用，而且您一開始不會想出正確的方案。請務必就文件的形式以及它們運作得如何進行大量溝通。預期隨著您了解最適合團隊的內容，文件的結構會有所演變。

在敏捷專案中，有兩個成功的文件編寫關鍵。第一個是找到「剛剛好」的文件編寫點。這很難確定，而且會因專案而異。幸運的是，敏捷開發的迭代性質讓您可以進行實驗，直到做對為止。成功的敏捷文件編寫的第二個關鍵是不執著於它，或對保持它的更新抱有不切實際的希望。文件必須建立來服務特定目的，而且在它服務完那個目的之後，你們所有人可能都有比更新文件更重要的事情要做。這可能看似違反直覺，但通常最好在下一次明顯需要時製作新的文件。每次您需要為專案的一部分製作文件時重新開始的一個好處是，這是保持文件編寫效率的一大誘因！

-- [Simons]

提早讓多種通訊模式運作

不同的溝通工具適用於不同種類的問題。至少請確保您有 wiki、即時通訊和良好的電話連線。

即時通訊適用於快速問答，但 IM 的一個特定優點是它會告訴您人們何時在他們的辦公桌前。您確實必須養成保持 IM 狀態最新的習慣，但那些資訊總是有用。我們在重疊時段看到溝通激增，特別是在那些重疊時段很短時，這特別有價值。

現在許多公司封鎖即時通訊，認為它是一種干擾。這總是傷害我們，因為它阻止 ThoughtWorkers 向其他專案的人員提出問題。它特別傷害離岸專案，因為它移除了非正式的一對一接觸。

如果超過幾則快速訊息，那麼最好切換到電話。請務必讓拿起電話變得容易。人們不應該因為害怕電話費而卻步，一通電話通常可以省下誤解的錢。

我們發現影片簡報很有價值。關於專案背景的簡短演講可以錄製並傳送給遠端團隊。這些簡報通常比文件更容易準備，也更容易坐著聽完（如果它們不太長），而且最重要的是它們也有助於建立個人聯繫，因為從影片中比從文件中更容易了解某人的全貌。它們不適合用於說明細節，但對於說明全貌來說效果較好。

電子郵件通常會帶來好壞參半的結果。特別是我們發現，最好避免使用個人電子郵件，而改用廣播新聞群組或郵件清單。資訊很容易沒有傳送到需要的人手上，或找不到資訊。透過在新聞群組中張貼訊息和要求，每個人都可以看到訊息，而且很容易搜尋。人們很容易略過他們不感興趣的串聯。

使用即時工具也可以進行多重廣播，而不是一對一的通訊。幾個團隊報告說使用 Campfire 有良好的效果。（IRC 可以用於類似的方式，儘管我尚未聽說有人提到它。）

也許最棘手的問題是要如何傳達大局觀念 - 專案的願景。大多數的溝通和關於溝通的討論都集中在日常細節上。正確掌握這些細節很重要，但專注於日常細節可能會導致沒有人關注整體願景，而這是有風險的。

這可能會造成傷害，因為許多人會根據他們對大願景的認知，習慣性地做出小決定。這些小決定會累積，因此如果沒有傳達大局觀念，問題可能會悄悄地發生。

這個問題對於傳達專案的商業背景特別重要。遠端溝通通常過於專注於戰術細節 - 本週需要建置什麼。但許多技術決策需要更廣泛的策略脈絡 - 因此，對於遠端團隊來說，了解專案和業務想要採取的方向的全貌非常重要。

這種溝通通常在現場專案中有所欠缺，特別是在業務和技術之間存在許多組織障礙時。遠端開發團隊會加劇這個問題 - 就像分散式開發會加劇大多數溝通困難一樣。