realestate.com.au(簡 稱REA)是澳洲最大的房地產垂直搜尋和廣告平臺，它與ThoughtWorks西安一年半以前開始合作，迄今為止，已成長為規模上包括6個團隊， 近50人，技術上涵蓋Ruby/RoR, Java/Groovy， Android/iOS, 業務上囊括所有領域的大型團隊與研發中心。
儘管REA同樣是敏捷成熟度非常高的組織，ThoughtWorks與REA 的合作也歷經一年多的摸索和調整才漸漸走上正軌。回頭去看這一年中經歷的困難和挑戰， 很大一部分是分散式環境帶來的，而團隊規模則扮演了困難放大器的角色。
究竟哪些敏捷實踐在分散式環境中比較脆弱，容易走樣？如何解決？讓我們用極限程式設計的洋蔥圈模型來探討這個問題。從內到外， 洋蔥圈模型把敏捷實踐劃分成了個人、團隊、組織3個層面。而據我的觀察，分散式環境常常對組織和團隊層面的敏捷實踐產生直接或間接的影響：
無間斷影片連線起來的完整團隊
完整團隊意味著在組織團隊時儘量將所需的各種角色配置到團隊中，起到減少交流壁壘、減小反饋週期、增加決策及時性與合理性的效果。我們團隊的現狀是介面設計 師、開發工程師、測試工程師和一部分業務分析師分佈在西安，而產品負責人、客戶代表等則分佈在澳洲。分散式的開發環境造成了中、澳雙方都無法建立完整團 隊，大部分的工作都需要雙方配合完成。隨之而來的問題是：
就我的觀察來看這是急事與要事博弈的結果。理論上要事應當優先，但事情的緊急性更容易感知，產生的短期壓力也更大，所以體現在多數個體和組織上的行為方式往 往是急事優先。千里之外的中國團隊主要透過郵件交流，郵件給人的感覺往往沒有當面交流來的急迫和壓力大，所以中國團隊的問題沒有被優先處理就不奇怪了。
能否創造一個易於談論要事的環境？ 能否讓中國團隊的請求產生同等的急迫感和壓力？ 透過不斷的嘗試我們發現利用 Skype建立無間斷影片(Always On Video)對改善交流問題有非常好的效果。下圖是我們用電視、Mac Mini和Skype建設的無間斷影片裝置:
中國和澳洲團隊分別購置了大螢幕電視，攝像頭，麥克風，註冊了機器人帳號，將Skype設定為自動接聽、自動開啟攝像頭，專門用於在上班時的不間斷聯絡。
不間斷影片讓雙方可以隨時發現相關責任人是否在座位上，並隨時就問題展開討論，迅速得到確認，大大減小了確認問題花費的時間 。 除此之外不間斷影片同時也成了團隊建設的工具，雙方見面機會多了，時常都會開開玩笑， 讓團隊成員之間更加熟悉和了解。
不間斷影片的引入大大減小了距離產生的不便，讓團隊在分散式的環境下依然可以高效的交流，快速的反饋。
化整為零的成果展示
每個迭代後，團隊都會給澳方的產品經理、客戶代表進行成果展示，演示在當前迭代中團隊都完成了哪些功能，客戶代表和產品經理會對特性進行驗收以及對產品本身 和團隊的運作狀況進行反饋。成果展示會議通常會持續1、2個小時，由於參與人數多，在時差的影響下會議時間非常難以協調，造成關鍵人物無法到場或者會議無 法按期召開，從而使開發團隊積壓了很多沒來得及驗收的功能，既影響開發進度又影響士氣。
既然2個小時的成果展示會議難以預定，化整為零會怎麼樣？ 如果同時協調中澳雙方的時間比較困難，引入在澳洲的代理人如何？
團 隊在回顧會議後把這些想法提了出來，在後面的迭代中，團隊在每個功能完成後立即向澳洲的負責人進行成果展示、收集意見，這樣每次驗收只需要10多分鐘，在 無間斷影片的幫助下，團隊可以隨時發現負責人是否在場，利用各種碎片時間召開會議。下圖是團隊利用Skype的共享桌面功能與客戶進行影片演示的現場截圖。
在迭代結束後，澳洲的負責人對各個特性已經心中有數，他再代表團隊與所有相關人召開更大規模的成果展示會議，因為同樣身在澳洲，組織會議就更方便、靈活。
透過化整為零以及引中間人，團隊有效的減少了無法驗收的功能，加快了反饋的週期。
持續釋出與自動化
釋出是一個需要多方共同參與、協作的過程，在我們這個分散式的環境中，產品環境的管理、維護以及產品的部署是由澳洲的運營團隊完成的。但部署過程往往不是一 帆風順的，一旦出現技術問題則需要中國團隊來排查和解決，有時甚至需要三方甚至四方會診。 環境的不可控、遠端定位問題的困難、高昂的交流成本， 三小時的時差都增加了頻繁釋出的痛苦，讓雙方妥協為每兩週“痛苦”一次。
從根源分析，我們的痛苦來自於：
我們能否把在釋出中需要交流的內容內建、固化在自動化腳本里？從而降低交流成本，提高效率和正確性。我們能否讓釋出的過程無痛，從而能更頻繁的釋出？
經過摸索，團隊使用了Capistrano、Chef透過Amazon的節點搭建出整套的部署環境，同時利用Go構建了持續釋出的流水線：
在這個過程中，產品環境的不一致性被一一修復，運營團隊把產品環境的維護策略固化在Chef指令碼中，讓開發團隊可以很方面的使用。開發團隊利用運營團隊給出的指令碼在Amazon上搭建出了模擬產品環境的測試環境，在儘量真實的環境中進行測試，來減少未來上線的風險。
我們目前的釋出過程是：
1、單元測試、靜態檢查、覆蓋率、打包
2、執行單節點上的功能測試.
3、透過Chef在Amazon節點上創造出最小叢集環境，在其上執行整合測試。
4、將透過測試的產品包釋出到庫中，供後續的探索性測試以及更大規模的整合測試使用。
5、自動部署在產品備份環境中等待A/B切換。
同時我們做到了在任何時刻測試人員都可以用一條命令取下最新的釋出包、構建出整合環境，展開探索測試。
現在從提交到釋出就緒耗時約1小時， 而整個釋出時間則不超過15分鐘，做到了每日釋出。
低耦合與高耦合
在合作初期， ThoughtWorks和REA都傾向於在中國開發比較獨立的系統 ，減小分散式環境的負面影響。 獨立系統與現有系統的低耦合性，意味著相關責任人少、交流成本低、整合難度低、目標清晰、責任明確，同時獨立系統即便出錯，影響的波及面也比較小、風險易 於控制。
隨著合作的加深，獨立系統的弊端開始顯現。獨立性使得雙方的合作難於在更大的範圍引發關注，缺乏了工作平臺，就難於使眾多的職能領導，如產品架構師、測試架 構師、運營團隊等和開發團隊形成強烈的責任感和團隊意識，組織間多點對多點的關係因此很難建立，而整合點少、整合難度低意味著對於現有遺留系統的理解不 足，難於承擔更復雜重要的工作 ，團隊很難擴張。
在後續的專案中，雙方注意到了上述問題，意識到與現有系統耦合度高的新系統對於加深雙方的合作是有積極作用的，從而有意識的進行了投入。雙方團隊一起設定業務領域 的上下文、制定釋出計劃、確定技術路線，利用上文中提到的種種實踐緊密的工作在同一個程式碼庫之上。
這樣的工作方式不可避免的增加了出現問題後影響的波及面 ，在我們團隊的構建指令碼中有個任務叫prePush，它會執行所有的單元測試和部分關鍵的功能測試。在工作一段時間後，中國團隊認為對程式碼已經相當熟悉 了，就放鬆了要求，結果是構建失敗後一下影響了澳洲3個團隊無法提交程式碼。
這件事情發生後我們才發現程式碼庫遠比想象的複雜，我們對遺留系統的理解確實不到位，分散式環境會大大增加修復構建的難度和壓力。這迫使團隊在執行整合實踐時更具紀律性，嚴格執行失敗構建不過夜。為了讓問題早發現，早處理，團隊還開發了基於Jenkins的外掛來讓構建結果更醒目：
對於結果特別重視的團隊還用上了指示燈：
對錯誤的及時響應，一方面縮短了故障時間，規避了開發高耦合系統的弊端，另一方面很好的建立了雙方互信的關係。
隱喻
分散式環境也會增加建立隱喻(Metaphor) 的難度。所謂隱喻是指在專案中的每一個人都使用相同的表達方式來解釋同一個概念，表達方式可以是語言或者圖表，概念可以是專案目標，架構或者業務概念。譬 如“成為中國的谷歌”就可以是一個專案目標的隱喻，它往往透過犧牲概念的精確性來增加概念的流通性。
對 隱喻的學習常常是在使用中進行的，透過反饋、矯正和調整與他人保持一致。譬如在星巴克點咖啡， 中杯代表著最小的杯子，我們往往透過與咖啡師交談或者點錯了杯的經驗會促使我們在下次使用正確的隱喻，然而分散式環境較高的交流成本以及不同的文化、語言 背景往往會形成多套不同的隱喻，讓交流變的很困難。在團隊剛建立時，我們的團隊成員有的用滑動圖（Sliding Image），有的用大圖指代首頁上的一張圖片，結果澳洲團隊常常困惑於中國團隊在談論什麼問題，後來我們發現它的術語叫做主圖(Hero Image)。
類似的問題不僅僅存在於使用者介面的元件和元素中，而且在技術詞彙更為通用的專案架構，部署模型，持續構建流水線中，也會出現隱喻不一致的情況。 這些不一致的隱喻不僅會增加團隊溝通的開銷、它也會體現在程式碼和設計中，以錯誤的命名，不合理的抽象等形式降低設計的表現力。
透過摸索，我們發現術語表和視覺化是是一個比較經濟有效的解決思路：
除此之外，REA經常邀請中國團隊在澳洲工作4～6周，在浸入式環境中快速掌握系統隱喻，中國團隊也不斷邀請REA的團隊來到中國，更高效的達成共識。最近 我們開始嘗試“101影片”：由澳洲的資深工程師給每個複雜系統錄製一段5分鐘的影片，進一步減低交流的成本、統一詞彙、提升學習的效果。
為了讓雙方能更好的合作，讓團隊對業務領域有更多的瞭解，雙方還設計了很多其它活動，比如把REA的內部活動Townhall（向所有員工公佈上一段時間公 司經營狀況，未來發展方向的活動）搬到西安，我們稱之為mini-Townhall，幫助中國團隊及時更新業務上下文；有的團隊會每週留出半天進行駭客 日，團隊在澳洲的負責人會把有趣的創新成果納入到迭代計劃中，最終成為產品的一部分，做到產品發展思路集體共有，透過上述種種活動儘量減少資訊孤島、減少 分散式環境對於團隊產生的影響。
修復XP
回顧與REA一年的合作，我們經歷了這樣幾個階段：
●試水：透過高度獨立性的系統建立信心以及明確初步的合作關係和合作方式。
●擴張：透過緊密的合作與一些開創性的實踐從6人發展到45人。
●沉澱：從邊緣技術與系統向核心技術與系統轉移。
在這個過程中，REA和ThoughtWorks一起面對和解決了很多困難，摸索出一些手法讓敏捷實踐在應用場景更具生命力和適應性，譬如無間斷影片、化整 為零的成果展示、同一程式碼庫等。未來REA 與ThoughtWorks還將致力於延續信任關係，積極的一起發現問題，探索解決方案。
總結下來，我們所作就是XP的另一核心實踐：修復XP。沒有哪種方法是保證成功的，從簡單的方式開始探索、及時真實的給出反饋、保持交流的開放、尊重差異、有勇氣去面對困難，推動變化，這是我們學到的最重要的一課。
感謝在寫作過程中我的同事索勤、劉堯、崔力強所給予的幫助，同時也對幫我審稿的諸多同事一併謝過。
realestate.com.au(簡 稱REA)是澳洲最大的房地產垂直搜尋和廣告平臺，它與ThoughtWorks西安一年半以前開始合作，迄今為止，已成長為規模上包括6個團隊， 近50人，技術上涵蓋Ruby/RoR, Java/Groovy， Android/iOS, 業務上囊括所有領域的大型團隊與研發中心。
儘管REA同樣是敏捷成熟度非常高的組織，ThoughtWorks與REA 的合作也歷經一年多的摸索和調整才漸漸走上正軌。回頭去看這一年中經歷的困難和挑戰， 很大一部分是分散式環境帶來的，而團隊規模則扮演了困難放大器的角色。
究竟哪些敏捷實踐在分散式環境中比較脆弱，容易走樣？如何解決？讓我們用極限程式設計的洋蔥圈模型來探討這個問題。從內到外， 洋蔥圈模型把敏捷實踐劃分成了個人、團隊、組織3個層面。而據我的觀察，分散式環境常常對組織和團隊層面的敏捷實踐產生直接或間接的影響：
無間斷影片連線起來的完整團隊
完整團隊意味著在組織團隊時儘量將所需的各種角色配置到團隊中，起到減少交流壁壘、減小反饋週期、增加決策及時性與合理性的效果。我們團隊的現狀是介面設計 師、開發工程師、測試工程師和一部分業務分析師分佈在西安，而產品負責人、客戶代表等則分佈在澳洲。分散式的開發環境造成了中、澳雙方都無法建立完整團 隊，大部分的工作都需要雙方配合完成。隨之而來的問題是：
Email常常無人響應問題需要來回多次才能得到確認，而時差和假日則常常把這段時間拉長為數日。牽扯到多方參與的活動在時差的影響下非常難於計劃和實施，比如驗收測試、優先順序調整、功能驗收等。就我的觀察來看這是急事與要事博弈的結果。理論上要事應當優先，但事情的緊急性更容易感知，產生的短期壓力也更大，所以體現在多數個體和組織上的行為方式往 往是急事優先。千里之外的中國團隊主要透過郵件交流，郵件給人的感覺往往沒有當面交流來的急迫和壓力大，所以中國團隊的問題沒有被優先處理就不奇怪了。
能否創造一個易於談論要事的環境？ 能否讓中國團隊的請求產生同等的急迫感和壓力？ 透過不斷的嘗試我們發現利用 Skype建立無間斷影片(Always On Video)對改善交流問題有非常好的效果。下圖是我們用電視、Mac Mini和Skype建設的無間斷影片裝置:
中國和澳洲團隊分別購置了大螢幕電視，攝像頭，麥克風，註冊了機器人帳號，將Skype設定為自動接聽、自動開啟攝像頭，專門用於在上班時的不間斷聯絡。
不間斷影片讓雙方可以隨時發現相關責任人是否在座位上，並隨時就問題展開討論，迅速得到確認，大大減小了確認問題花費的時間 。 除此之外不間斷影片同時也成了團隊建設的工具，雙方見面機會多了，時常都會開開玩笑， 讓團隊成員之間更加熟悉和了解。
不間斷影片的引入大大減小了距離產生的不便，讓團隊在分散式的環境下依然可以高效的交流，快速的反饋。
化整為零的成果展示
每個迭代後，團隊都會給澳方的產品經理、客戶代表進行成果展示，演示在當前迭代中團隊都完成了哪些功能，客戶代表和產品經理會對特性進行驗收以及對產品本身 和團隊的運作狀況進行反饋。成果展示會議通常會持續1、2個小時，由於參與人數多，在時差的影響下會議時間非常難以協調，造成關鍵人物無法到場或者會議無 法按期召開，從而使開發團隊積壓了很多沒來得及驗收的功能，既影響開發進度又影響士氣。
既然2個小時的成果展示會議難以預定，化整為零會怎麼樣？ 如果同時協調中澳雙方的時間比較困難，引入在澳洲的代理人如何？
團 隊在回顧會議後把這些想法提了出來，在後面的迭代中，團隊在每個功能完成後立即向澳洲的負責人進行成果展示、收集意見，這樣每次驗收只需要10多分鐘，在 無間斷影片的幫助下，團隊可以隨時發現負責人是否在場，利用各種碎片時間召開會議。下圖是團隊利用Skype的共享桌面功能與客戶進行影片演示的現場截圖。
在迭代結束後，澳洲的負責人對各個特性已經心中有數，他再代表團隊與所有相關人召開更大規模的成果展示會議，因為同樣身在澳洲，組織會議就更方便、靈活。
透過化整為零以及引中間人，團隊有效的減少了無法驗收的功能，加快了反饋的週期。
持續釋出與自動化
釋出是一個需要多方共同參與、協作的過程，在我們這個分散式的環境中，產品環境的管理、維護以及產品的部署是由澳洲的運營團隊完成的。但部署過程往往不是一 帆風順的，一旦出現技術問題則需要中國團隊來排查和解決，有時甚至需要三方甚至四方會診。 環境的不可控、遠端定位問題的困難、高昂的交流成本， 三小時的時差都增加了頻繁釋出的痛苦，讓雙方妥協為每兩週“痛苦”一次。
從根源分析，我們的痛苦來自於：
知識傳遞的困難：產品環境與測試、備份環境相比，複雜度更高也更敏感。學習這些知識是需要專門投入的長期過程，運營團隊不放心把產品環境交給開發團隊進行測試與部署。不瞭解產品環境又引起開發團隊出現各種紕漏，比如遺漏更新部署指令碼。手工過程讓運營團隊成為瓶頸：最終的產品部署是半自動化半手工的過程，每次釋出都都需要協調運營團隊參與， 手工過程的費時費力讓運營團隊無法保證高頻率的投入。手工過程增加了交流成本：因為手工過程容易出錯，一旦出現問題就需要雙方在一起排查，時差和分散式的環境都增加了交流的成本。我們能否把在釋出中需要交流的內容內建、固化在自動化腳本里？從而降低交流成本，提高效率和正確性。我們能否讓釋出的過程無痛，從而能更頻繁的釋出？
經過摸索，團隊使用了Capistrano、Chef透過Amazon的節點搭建出整套的部署環境，同時利用Go構建了持續釋出的流水線：
在這個過程中，產品環境的不一致性被一一修復，運營團隊把產品環境的維護策略固化在Chef指令碼中，讓開發團隊可以很方面的使用。開發團隊利用運營團隊給出的指令碼在Amazon上搭建出了模擬產品環境的測試環境，在儘量真實的環境中進行測試，來減少未來上線的風險。
我們目前的釋出過程是：
1、單元測試、靜態檢查、覆蓋率、打包
2、執行單節點上的功能測試.
3、透過Chef在Amazon節點上創造出最小叢集環境，在其上執行整合測試。
4、將透過測試的產品包釋出到庫中，供後續的探索性測試以及更大規模的整合測試使用。
5、自動部署在產品備份環境中等待A/B切換。
同時我們做到了在任何時刻測試人員都可以用一條命令取下最新的釋出包、構建出整合環境，展開探索測試。
現在從提交到釋出就緒耗時約1小時， 而整個釋出時間則不超過15分鐘，做到了每日釋出。
低耦合與高耦合
在合作初期， ThoughtWorks和REA都傾向於在中國開發比較獨立的系統 ，減小分散式環境的負面影響。 獨立系統與現有系統的低耦合性，意味著相關責任人少、交流成本低、整合難度低、目標清晰、責任明確，同時獨立系統即便出錯，影響的波及面也比較小、風險易 於控制。
隨著合作的加深，獨立系統的弊端開始顯現。獨立性使得雙方的合作難於在更大的範圍引發關注，缺乏了工作平臺，就難於使眾多的職能領導，如產品架構師、測試架 構師、運營團隊等和開發團隊形成強烈的責任感和團隊意識，組織間多點對多點的關係因此很難建立，而整合點少、整合難度低意味著對於現有遺留系統的理解不 足，難於承擔更復雜重要的工作 ，團隊很難擴張。
在後續的專案中，雙方注意到了上述問題，意識到與現有系統耦合度高的新系統對於加深雙方的合作是有積極作用的，從而有意識的進行了投入。雙方團隊一起設定業務領域 的上下文、制定釋出計劃、確定技術路線，利用上文中提到的種種實踐緊密的工作在同一個程式碼庫之上。
這樣的工作方式不可避免的增加了出現問題後影響的波及面 ，在我們團隊的構建指令碼中有個任務叫prePush，它會執行所有的單元測試和部分關鍵的功能測試。在工作一段時間後，中國團隊認為對程式碼已經相當熟悉 了，就放鬆了要求，結果是構建失敗後一下影響了澳洲3個團隊無法提交程式碼。
這件事情發生後我們才發現程式碼庫遠比想象的複雜，我們對遺留系統的理解確實不到位，分散式環境會大大增加修復構建的難度和壓力。這迫使團隊在執行整合實踐時更具紀律性，嚴格執行失敗構建不過夜。為了讓問題早發現，早處理，團隊還開發了基於Jenkins的外掛來讓構建結果更醒目：
對於結果特別重視的團隊還用上了指示燈：
對錯誤的及時響應，一方面縮短了故障時間，規避了開發高耦合系統的弊端，另一方面很好的建立了雙方互信的關係。
隱喻
分散式環境也會增加建立隱喻(Metaphor) 的難度。所謂隱喻是指在專案中的每一個人都使用相同的表達方式來解釋同一個概念，表達方式可以是語言或者圖表，概念可以是專案目標，架構或者業務概念。譬 如“成為中國的谷歌”就可以是一個專案目標的隱喻，它往往透過犧牲概念的精確性來增加概念的流通性。
對 隱喻的學習常常是在使用中進行的，透過反饋、矯正和調整與他人保持一致。譬如在星巴克點咖啡， 中杯代表著最小的杯子，我們往往透過與咖啡師交談或者點錯了杯的經驗會促使我們在下次使用正確的隱喻，然而分散式環境較高的交流成本以及不同的文化、語言 背景往往會形成多套不同的隱喻，讓交流變的很困難。在團隊剛建立時，我們的團隊成員有的用滑動圖（Sliding Image），有的用大圖指代首頁上的一張圖片，結果澳洲團隊常常困惑於中國團隊在談論什麼問題，後來我們發現它的術語叫做主圖(Hero Image)。
類似的問題不僅僅存在於使用者介面的元件和元素中，而且在技術詞彙更為通用的專案架構，部署模型，持續構建流水線中，也會出現隱喻不一致的情況。 這些不一致的隱喻不僅會增加團隊溝通的開銷、它也會體現在程式碼和設計中，以錯誤的命名，不合理的抽象等形式降低設計的表現力。
透過摸索，我們發現術語表和視覺化是是一個比較經濟有效的解決思路：
除此之外，REA經常邀請中國團隊在澳洲工作4～6周，在浸入式環境中快速掌握系統隱喻，中國團隊也不斷邀請REA的團隊來到中國，更高效的達成共識。最近 我們開始嘗試“101影片”：由澳洲的資深工程師給每個複雜系統錄製一段5分鐘的影片，進一步減低交流的成本、統一詞彙、提升學習的效果。
為了讓雙方能更好的合作，讓團隊對業務領域有更多的瞭解，雙方還設計了很多其它活動，比如把REA的內部活動Townhall（向所有員工公佈上一段時間公 司經營狀況，未來發展方向的活動）搬到西安，我們稱之為mini-Townhall，幫助中國團隊及時更新業務上下文；有的團隊會每週留出半天進行駭客 日，團隊在澳洲的負責人會把有趣的創新成果納入到迭代計劃中，最終成為產品的一部分，做到產品發展思路集體共有，透過上述種種活動儘量減少資訊孤島、減少 分散式環境對於團隊產生的影響。
修復XP
回顧與REA一年的合作，我們經歷了這樣幾個階段：
●試水：透過高度獨立性的系統建立信心以及明確初步的合作關係和合作方式。
●擴張：透過緊密的合作與一些開創性的實踐從6人發展到45人。
●沉澱：從邊緣技術與系統向核心技術與系統轉移。
在這個過程中，REA和ThoughtWorks一起面對和解決了很多困難，摸索出一些手法讓敏捷實踐在應用場景更具生命力和適應性，譬如無間斷影片、化整 為零的成果展示、同一程式碼庫等。未來REA 與ThoughtWorks還將致力於延續信任關係，積極的一起發現問題，探索解決方案。
總結下來，我們所作就是XP的另一核心實踐：修復XP。沒有哪種方法是保證成功的，從簡單的方式開始探索、及時真實的給出反饋、保持交流的開放、尊重差異、有勇氣去面對困難，推動變化，這是我們學到的最重要的一課。
感謝在寫作過程中我的同事索勤、劉堯、崔力強所給予的幫助，同時也對幫我審稿的諸多同事一併謝過。