邊境安檢系統：LeSS與離岸開發

背景

背景與客戶

SITA創建的產品可幫助全球各地政府確保邊境安全。我們正在創建的產品是用于自動化邊境的解決方案，以在不影響安全性的前提下優化前往各個國家旅行者的流程。該產品是這樣構建的，獲取前往相應國家的所有旅行者數據，根據可用的監視列表對每個旅行者進行篩選，并針對被政府機構（例如，警察、移民等等）用系統標記的旅行者采取并記錄必要的行動。

開始

2010年SITA贏得了一項為期18個月的大合同，以創建和實施邊境安全系統。該系統包括高度安全的數據中心和部署在該國所有口岸的軟件解決方案。

Frank West（產品交付總監）聘請我為內部顧問，來幫助他們采用敏捷的工作方式。

雙方之間的合同是構建整個系統（產品和數據中心），并在18個月后以一次性的方式進行部署。但是軟件開發總監對這種方法感到不安，因為過去他多次在一次性交付中吃過虧。這次的情況尤其如此，因為該系統非常復雜并且由許多未知數組成。因此，他想（再次）探索敏捷的工作方式，并雇用我來幫助他以迭代、增量和自適應的方式交付該系統。

我加入時，SITA的組織結構非常等級化，劃分成獨立的職能部門。看起來像這樣：

業務團隊存在類似的結構，主要由項目經理、銷售顧問和業務解決方案架構師（主題專家SME）組成。

向Scrum過渡（但不是less）

我們從為期三天的研討會開始，了解敏捷宣言、敏捷原則及Scrum。從正確的教育入手至關重要。我們想確保建立一個長期的學習型組織，因此我們將重點放在激發與提供適當的教育方面，以實現更多的協作、迭代和增量式的工作方式。我提供了Scrum概述的培訓，然后我們討論了如何組建開發團隊。在與開發團隊和管理層進行了大量討論之后，我們提出了如下的團隊結構：

對我們而言，從一開始就建立適當的結構非常重要，以確保我們創建真正的團隊，同時牢記“文化遵循結構”，這是“拉曼的組織行為法則”的第五條的一部分，因此我們首先創建了兩個跨職能的Scrum團隊。這些團隊由SME、BA、開發人員、測試人員和架構師組成。盡管我們的確是由一組專家組成的團隊，但每個團隊成員只有一個頭銜即“開發人員”。對團隊的承諾和期望是他們將不再擔任專家，整個團隊將朝著Sprint目標努力，并選擇實現Sprint目標所需的下一個任務。

我們的主題專家（SME）人才是邊境控制流程和航空業的高技能領域專家。

我與弗蘭克（Frank）討論過，我們不需要項目經理，但他還是堅持要求保留兩個人（項目經理和解決方案架構師）來管理公司報告和一些售前活動。他們倆都對要出售給客戶的產品有很好的領域知識。

弗蘭克（Frank）明白，將來我們不再需要這兩個“角色”，但是他建議保留這兩個人的角色，在目前將有助于我們跟銷售團隊就一直在開發的產品保持同步，以便讓他們不要將其作為單獨的“項目”出售。弗蘭克要求他們兩個都與銷售團隊工作，并且他們也定期與產品負責人工作，以了解我們產品的進度，以便他們可以相應地為我們的潛在客戶提供建議。

最終，我們意識到組件團隊在團隊之間引入了許多不必要的依賴與移交，這導致了遲來且昂貴的反饋，在整體回顧中我們也討論了這些反饋。使用這些反饋，我們開啟了以避免不必要的依賴的從組件團隊轉向特性團隊的對話。在對話期間我們還意識到，如果我們不盡快轉向特性團隊（跨團隊管理依賴關系將是一場噩夢），將來很難有效地添加更多團隊，因此我們開始討論創建特性團隊的方法。

在對話期間，團隊還提出了組建特性團隊的如下問題：

并非每個團隊都有實現下一個優先級條目所需的技能和知識

跨不同架構組件的特性實現的設計可能會變得混亂

特性團隊可能會卡在設計決策上

所有這些都是重要點，因此我們決定從一個特性團隊開始（“指南：過渡到特性團隊”），而不是大張旗鼓。我們創建了一個特性團隊，并要求他們端到端地交付特性。我們遵循XP（極限編程）的建議，為每個組件引入了“組件牧羊人（Component Shepherd）”作為導師，以避免最初出現任何技術故障。

“組件牧羊人”的主要作用是指導特性團隊改動相應的組件，并在團隊進行改動時提供利弊對比。所有牧羊人都更像旅行者（“指南：旅行者”）那樣工作，因此他們大部分時間都可以自由地輔導和指導多個團隊。團隊逐漸地（9-12個月）積累了多個組件的知識，從而很少再需要“組件牧羊人”的指導。

過渡到LeSS

Scrum的實施對我們最初的兩個團隊工作良好。我們提供的最初產品收到了客戶的良好反饋，從而引起了其他潛在客戶的極大興趣。我們的潛在客戶喜歡我們交付的特性，但他們也希望產品中有許多新功能。一旦有更多的客戶注冊了我們的產品，我們就決定增加更多的團隊。

我們沒有多團隊合作的經驗，因此開始探索可用于幫助我們的資源。我們發現了兩本書，分別是Craig Larman和Bas Vodde撰寫的《精益和敏捷開發大型應用指南》和《精益和敏捷開發大型應用實戰》。對于我們的案例，它們看起來像是完美的指南，尤其是關于大規模Scrum框架2（現為巨型LeSS）的概念，因為我們預計將來會增長到大約20至30個團隊。

這些書籍在提供有關規模化（以及由此對組織提出的挑戰）的準則方面如此豐富（現在仍然如此），以至于它成為我們在整個過程中進行規模化的指導力量。我們開始定期探索這些書中的想法，并進行了一本書中的許多“嘗試和避免……”的實驗。

多地點的離岸開發

盡管我們強烈推薦在同一地點辦公，但我們在當前辦公室的物理空間仍然受到一些組織上的嚴格限制，并且需要與位于不同時區的客戶進行互動。當我們要求管理層（執行委員會）提供額外預算（主要是更多的團隊）時，他們要求我們與位于印度和基輔的現有離岸合作伙伴進行合作，以確保我們在多個時區都有團隊存在（主要是中東和澳大利亞）來吸引和支持我們的新客戶。

我們接受了挑戰，但有一個條件，即一旦選擇供應商，我們將像在英國一樣進行面試和組建團隊，而不是接受下一個可用人員或團隊的典型離岸模式（“避免……外包商說，交給我們吧，我們為您做到敏捷”）。我們還決定在每個地點都有一些位于同一地點的團隊（“指南：在LeSS中組織多地點辦公”），以確保團隊之間能夠相互學習，這只有在同一地點的團隊中才有可能。我們還將把離岸團隊帶到英國至少進行4次Sprint（“嘗試……離岸之前先在一起進行幾次迭代”）。

我們以為在管理方面會遇到困難（基于過去的類似經驗），但是令我們驚訝的是，在開始離岸供應商選擇流程之前，我們的管理層和離岸合作伙伴都毫不費力地達成了一致。我認為他們了解過去離岸團隊的加入一直很痛苦。但是當他們意識到我們一直在以新的工作方式交付成果時，他們允許我們嘗試與離岸團隊合作的方式。

我們辦公室內的多地辦公體驗

我們與團隊討論了多地辦公的試驗，并確保不會對他們的工作產生任何影響。因為他們也知道我們需要更多的團隊，并且對物理地點有很大的限制。盡管大多數人都有多地辦公的經驗，但這不是我們最近的（檢視和調整）工作方式。在對話中，一名團隊成員問，在敏捷環境中與多地的團隊合作感覺如何？由于我們都沒有與多地敏捷團隊合作的想法，因此團隊中的一位成員給了我們一個想法，即我們在其它地點加入新團隊之前，先要經歷多地環境的挑戰。她建議“為什么不將現有的一個團隊搬到另一樓層，而僅使用電話或Skype與另一團隊進行溝通，即 沒有面對面的交流，看看這帶來了什么挑戰。我們非常喜歡這個想法，它與書中的一項實驗一致（“嘗試……即使位置靠近也按多地思考”）

一個團隊在下一個Sprint搬到的另一樓層（幸運的是，我們在那層上有一個可以容納團隊的空間，但只能用2周）。很快，我們可以看到，即使他們位于同一棟大樓且只有一層之隔，團隊也意識到了多地辦公向他們施加的挑戰。盡管他們已經合作了很長時間，但是無法看到他們，只能通過電話、電子郵件和Skype進行交流，他們還是因此失去了緊密的物理協作（例如白板會議）。

這是一個很好的實驗，可以為即將到來的“離岸團隊”建立“現場”團隊的同理心（這就是他們一開始的看法）。

離岸合作伙伴的選擇

我們訪問了三個地點（印度兩個，基輔一個），并受到了所有人的熱烈歡迎。

這些人都從大量的Powerpoint演示開始，介紹了他們的“敏捷”能力和已交付的“敏捷項目”的經驗。 很快就很明顯，他們對敏捷工作方式的大多數理解都是“錯誤的”。一次又一次的演講，很明顯這些團體要么是在大肆宣傳，要么是對他們所說的“敏捷”一無所知。我們認為他們在“創建Powerpoint幻燈片”方面要熟練得多，但通過交付迭代和增量的軟件來交付持續的價值呢？不見得行。

我們想知道為什么他們對敏捷的工作方式沒有這么了解。畢竟，這些公司可以訪問所有內容（培訓、書籍、聘請顧問和教練等以幫助他們）。我真誠地問了他們的一位經理，以便從他們的角度來理解這個問題。他的回答非常有趣且提供了有用的信息，幫助我們了解了離岸IT公司的工作方式。總而言之，離岸公司不向客戶提供咨詢服務。他們的商業模式通常圍繞以低廉的成本提供人員，并與客戶期望他們工作的方式保持一致。因此，他們不會真正地投資任何新事物，直到成為主流，并且客戶希望他們對新事物有所了解。

在拜訪了所有離岸候選人之后，我們意識到這將是一個漫長、痛苦而又令人興奮的旅程。因此基于跟他們的經歷，我們建議僅從印度班加羅爾的那個團隊開始。按照《精益和敏捷開發大型應用實戰》（“嘗試……更少的地點”）一書中的實驗，我們不想從多個離岸合作伙伴的多個地點開始，以創建不必要的復雜性。

“商業部門”推動我們同時使用這三個地點。但是，當我們向他們解釋了多個地點及多個合作伙伴的負面影響（溝通、協調失靈、語言和文化差異、與其中一個地點的簽證問題等）之后，尤其是在敏捷開發環境中，我們被允許先選其中一家，但他們還是期望將來可以用所有的三個地點。

除了上述提到的多個離岸地點的負面影響之外，我們還希望保持組織的簡單性，并繼續我們*成為敏捷(be agile)而不是做敏捷(do agile)*的旅程。我們已經在Scrum和Extreme Programming工程實踐方面有了一個良好的開端，我們希望增加更多的團隊，但不增加任何不必要的協調、離岸管理等開銷，以保持以客戶為中心。基本上，我們希望通過消除客戶和團隊之間任何不必要的復雜性來簡化組織，從而擴展產品的開發規模。在成功試驗兩個地點（英國和另一個地點）之前，我們致力于避免不必要的、人為的管理多個地點的復雜性。我們深知與離岸IT公司合作會帶來不必要的開銷，例如與項目經理、現場協調員、離岸項目經理、多個時區等打交道。

當我們自己試圖簡化組織設計保持以客戶為中心時，我們理解了為什么“商業部門”會迫使我們選擇這三個地點。高層迫使他們將新工作移至離岸地點以降低成本。他們表現得像一個會計師（還是一個很好的會計師），卻不了解其行為的整體系統含義。簡而言之，這是經典的局部優化。

我們部門的業績在整個組織中引起了積極的反響。我們的成功故事（高質量的產品、滿意的客戶、提早交付和持續交付、更多的業務等等）也觸及到產品開發外部的各種人員（例如HR、商務等），他們對我們不同的做法感到好奇。我們邀請商務部門的人員與我們的團隊會面，以便向他們解釋我們的工作方式。這與LeSS的采用規則有關：“對于產品組以外的大型組織，請使用現場現地（Gemba）來采用LeSS演進，創建以實驗和改進為準則的組織。”。訪問我們的時候，他們驚訝地看到我們在部門內創建的可視化效果。他們可以輕松地查看我們的產品待辦事項列表（墻上的故事地圖），每個團隊的Sprint待辦事項列表（白板上），構建的統計信息（構建狀態，缺陷數量等），監視器等，以及在地板上合作（主要是人們一起工作的噪音）（譯者注：在地板上合作指的是大家走來走去，面對面的溝通）盡管來自非技術部門，但他們的反應是您為什么不采用這種方式工作，這是如此明顯。他們還真心想幫我們跟離岸供應商協商一個更低的價格，如果我們愿意直接與10多個團隊工作的話。我們禮貌地拒絕了，并意識到我們還有很長的路要走，以使我們的組織精益化和系統化思考。他們顯然看不到增加10多個團隊相比于1個團隊來說的系統影響。他們只是從自身降低成本這一局部優化目標來看，而沒有意識到這樣做可能是增加了總體成本。

我們與離岸合作伙伴約定的條件之一（在我們決定與他們合作之前）是我們尋找“長期合作伙伴關系”，而不是臨時的項目方式（“嘗試……將離岸組織視為內部合作伙伴?”）。實際上，這意味著：

我們將采用相同的工作方式（如Scrum和XP中的工程實踐）和

相同的團隊組成（跨職能和自我管理）。

我們還提供了幫助，以Scrum、XP和精益思想為基礎，讓離岸管理人員理解和適應工作方式，這樣做我們實質上是忽略了組織邊界。我們說過，我們將在最初的3-6個月內提供一名教練，以幫助他們建立和完善對精益思維和敏捷工作方式的理解。這位敏捷教練的費用不需要他們承擔，因為我們將這視為與他們建立長期可持續伙伴關系的投資。

但是，作為回報，我們期望一種完全透明的文化和最少的離岸層級管理（“避免……擁有繁重管理工作的外包商”）。我們還明確表示，我們合作伙伴關系的基礎是建立在雙方的信任之上。否則，未來的合作將會是動蕩的，雙方都希望避免。

他們還將提供

開放的辦公工作環境（沒有任何隔間和獨立辦公屋）和

每個團隊成員將有兩個27英寸顯示器。

我想他們最初有些不安（例如，為開發人員提供27英寸顯示器可能給同一建筑物中的其它項目帶去問題；在團隊里沒有管理者），后來還是同意了，但建議包括一名經理學習新的工作方式，并幫助促進和協調新的工作環境，這在我們看來是合理的。令我們驚訝的是，這位經理其實是協作和透明工作方式的大力支持者，并且很高興與我們工作來“創造流動，在瀑布泥潭中等待了這么長時間后”（按他自己的話說）。

因此，經過一個月的飛行并多次訪問班加羅爾、德里和基輔后，我們有了一個離岸合作伙伴……但仍然還沒有團隊。

團隊選擇

我們給離岸合作伙伴提供了指南（而非詳細的工作規范），以說明我們對跨職能團隊所需技能的要求。我們主要是尋找在J2EE、SOA、JavaScript、SOLID設計原則、Oracle DB、TDD、持續集成、Jenkins和探索性測試方面經驗豐富的團隊成員。因為這是我們在班加羅爾的第一個團隊，所以我們希望確保我們不僅根據學習能力來挑選團隊成員，而且更重要的是要根據學習態度來挑選團隊成員。

我們尋找的人不僅對我們所尋找的技能有很好的了解，而且對不斷學習新技術和工作方式具有真正的好奇心。但是，我們不希望他們只想從他們可用的資源（書籍，互聯網，會議等）中學習，也想彼此學習。

我們認為選擇一個大約8人的團隊并不難，但是經過兩天的技術測試、結對編程（“嘗試…通過編程方式面試外包程序員”）和200人的面試之后，我們只選擇了符合我們團隊標準（學習能力和態度）的7個人。這解釋了四年程序員的問題，在《精益和敏捷開發大型應用實戰》（第13章，離岸開發）中對此進行了很好的描述：

“在全球范圍內，程序員的素質存在問題。他們通常不會在大學里學到關于良好的編程與設計有用的知識，因為計算機科學的教授（盡管他們才華橫溢，天賦嫻熟）對現實世界中產品開發的偉大代碼一無所知，并且他們當然不會花費時間與學生結對編程，或以任何有意義的方式指導學生編程。可以說，印度和中國教授的專業編程技能甚至更差。因此，尤其是在這些國家，普通人首先會加入編程技能要求非常低的外包公司。然后情況變得更糟：四年程序員問題。在大約四年后，人們期望不再是程序員，而成為經理。動機是可以理解的，更多的金錢和地位。

因此，平均而言，一群低技能的程序員在剛開始獲得一點技能和生產力后，就離開了有價值的工作。”

我們還意識到，在選定的七個團隊成員中，有四個只有兩年經驗，但是對學習的好奇心強，沒有什么瀑布開發經驗，并且更喜歡在敏捷環境中工作。其他三個人實際上都有一個架構師的頭銜，他們只是想不斷地編碼，并且渴望永遠能動手。所以我們以為終于有了第一個團隊，但到了晚上，我們得知一位成員無法加入我們，因為他在家中遇到了一些緊急情況，不得不搬到海得拉巴。

這次經歷中的主要學習

我們從這次經歷中學到的是，一家離岸公司可能有很多人，但他們可能沒有在敏捷環境中工作的正確技能。這不是因為他們沒有能力，而是大多數離岸公司都沒有設計成在這樣的協作環境中工作，這直接反映在為他們工作的員工所具備的技能集合上。當然，我們并不認為他們無法學習和適應環境，但是直到離岸公司提供了促進合作的環境，并且他們的客戶也真正地適應了合作、檢視和適應思維的工作方式之前，這種改變將是令人痛苦的慢。無論如何，我們有了一個6人組成的團隊作好了工作準備。

團隊入職

我們已達成協議，團隊將在英國與我們一起度過最初的四個Sprint（“嘗試……離岸團隊首先在一起進行了幾次迭代”），這需要2-3周的簽證處理時間。因此我們認為，在我們到那里的時候，團隊應該互相了解一點，但因為他們過去從未彼此合作過。我們與他們建立了一個為期兩天的研討會，以幫助他們了解最初要工作的產品和領域的愿景（“嘗試……離岸領域和愿景研討會”）。

在向他們介紹產品愿景之前，我們澄清了這個團隊將會長期存在，就像我們在英國的團隊那樣（“嘗試……穩定的離岸Scrum團隊”）。我們鼓勵他們通過結成三對來相互了解（兩人為一對）。他們選擇了搭檔后，要求他們花15分鐘了解彼此的情況，15分鐘后，他們必須將其搭檔介紹給團隊的其他成員。我們沒有規定他們應該如何了解和呈現這些信息，而是建議他們盡可能發揮創造力和以令人興奮的方式。此練習幫助六人邁向了成為團隊的第一步。

我們解釋并演示了整個產品，并讓他們使用了該產品。我們要求他們進行探索性測試，看看他們是否可以提出任何建議來改進現有功能。他們真的很喜歡產品用戶體驗的簡單性，并很快理解了各種用戶使用過程，然后提出了一些澄清和建議，我們的產品負責人對此予以記錄，并承諾考慮并回復。我們還與他們共享了Wiki，以便團隊可以詳細了解任何特定要求以更好地理解產品。

如前所述，班加羅爾辦事處已經從我們的辦事處建立了專用網絡。我們進行了必要的網絡和安全更改，以允許他們訪問我們的源代碼倉庫，構建服務器和其它環境。我們建議團隊在筆記本電腦上設置他們的開發環境，以盡快解決所有連接問題，并開始熟悉代碼結構和現有的架構。

離岸團隊與現場團隊合作

最初挑選的四周后，班加羅爾的團隊在周末抵達了我們的英國辦事處。我們安排他們呆在辦公室附近，這樣他們就不必擔心去辦公室的通勤了。我們的Sprint周期是周三到周二（2周一個Sprint），新團隊有兩天的時間觀察和探索我們在英國辦公室的工作方式。

他們還沒有經理的陪同，因為他仍在班加羅爾辦公室工作，來設置開放式辦公室環境并為團隊安排大顯示器。他想和團隊一起旅行，但我們建議他只有確保在班加羅爾辦公室中擁有商定的辦公環境后才能來英國。在沒有經理的情況下旅行對團隊來說有點棘手。首先，他們從未作為一個團隊一起旅行（他們的大部分“現場”經驗是獨立旅行，而不是作為一個團隊），他們到達“客戶現場”時，經常有一位“經理” 指導他們。因此，當直接與“客戶”接觸時，他們看上去有些不知所措。

在離岸訪問（尤其是在印度）中讓我們感激的一件事是，我們第一次到達他們的辦公室時受到了真正溫暖的歡迎。

每個到達的訪客都有一個牌子和一個美妙的手勢。

因此，離岸團隊到達英國辦公室時，我們也做了同樣的事情。我們在歡迎板上寫下他們的名字，當團隊到達辦公室時，我們在那里歡迎他們。

我們沒有從離岸供應商那里雇用Scrum Master，因為我們沒能找到合適的人選。因此，我們決定邀請現有的Scrum Master，Sylvie加入新團隊，以幫助團隊學習和深入了解Scrum。我們還要求他們與現有團隊配對，這樣他們不僅能夠觀察和學習工作方式，而且最重要的是，他們與其他團隊成員建立了個人關系。

Sylvie安排了一個架構工作坊（“指南：當前架構工作坊”）來審視當前的架構。我們的產品負責人也參加了該工作坊，并一個一個地解釋了各種用例，現有團隊中的許多人也參加了討論以解釋當前的架構。我們主要介紹了該產品的目的、當前的特性并繪制了架構，以幫助他們了解系統的不同視圖，即每種場景的邏輯視圖、開發視圖、流程視圖和物理視圖，以便他們可以了解目前為止已構建的系統的整體情況。

我們在小組附近用白板討論，這樣他們也可以保留信息以備將來參考。該工作坊持續了一天，使團隊對系統有了更全面的了解。

在工作坊結束時，Sylvie要求團隊提供有關工作坊的反饋，他們聽起來都相當積極。一位成員有趣地將工作坊稱為“KT會話”（知識轉移knowledge transfer）。這是一個有趣的觀點，Sylvie必須（反復）澄清，我們不會將任何工作轉移給離岸公司，但是就工作而言，新團隊已成為我們組織的一部分。他們與其他團隊是平等的，所以在團隊之間如何共享工作上也沒有任何區別（“嘗試……將離岸組織視為內部合作伙伴”）。當然，我們會在他們學習產品的各個方面時繼續向他們提供所有支持，但是他們應該專注于理解和學習的端到端（取決于他們所工作的特性），因為他們不會工作于某個特定組件，而是負責交付端到端特性（與其他團隊一樣）。

我們成功的關鍵因素之一是，我們從組件團隊轉變到特性團隊。我們從經驗中學到了這一轉變不僅給團隊帶來了挑戰，而且給整個組織帶來了挑戰。因此，我們希望確保我們的新團隊以特性團隊的身份開始，而不是陷入組件團隊的思維定勢中（“避免……基于組件或職能來組織地點”）。

第二天，團隊主要與已配對的現有團隊合作，并參與了Sprint評審、Sprint回顧和整體回顧。我們可以看到他們真的很欣賞這種透明和協作的工作方式。他們對所看到的團隊授權和自治感到驚訝，并期待著他們的第一個Sprint。

通常，我們的Sprint計劃第1部分會持續大約一個小時，因為Sprint的所有條目在上一Sprint中的產品待辦列表梳理會議期間均已細化。但是，由于我們有一個新團隊，產品負責人和現有團隊花了大約兩個小時來與新團隊一起仔細解釋（已經細化的）條目，并從他們那里獲得反饋。

我們有一個大型的開放式辦公室，并留有大量空間來促進協作（“指南：利于協作的環境”）。在這個空間的大面的墻上，團隊可視化了產品待辦事項列表，Sprint待辦事項列表（每個團隊），完成的定義以及當前的架構。因此，現有團隊解釋了下一個Sprint的目標，并與新團隊進行了對話，討論他們希望為第一個Sprint做點什么工作。對于新團隊來說，這是相對令人驚訝的，因為他們期望會由某人對他們“分配”條目。Sylvie問團隊，他們是否愿意獨自工作或加入另一個團隊以實現總體Sprint目標。團隊成員認為他們應該與另一個團隊合作，以便可以在Sprint期間獲得所需的所有支持（“嘗試……Scrum Master的意圖是建立自組織團隊”）。她再次澄清，盡管新團隊將擁有一個單獨的Sprint待辦事項列表，但他們將獲得實現Sprint目標所需的所有支持。因此，在進一步對話之后，兩個團隊都同意將該條目帶進他們的Sprint計劃第2部分。

Sprint計劃第2部分主要是我們的初始設計工作坊（“指南：多團隊設計工作坊”），以學習并同意我們將如何從技術上實現選擇的每個條目。兩個團隊花了大約三個小時參加他們的Sprint計劃第2部分，并都同意了在白板（魔術白板）上的思辨設計（speculative design）（擴展了現有的類圖和順序圖），并獲得了快速反饋。團隊保留了白板并將其移動到座位區域旁邊，以在當前（及將來）的Sprint中使用。經過初步評審并根據反饋采取糾正措施后，兩個團隊都把Sprint待辦事項列表放到團隊白板上準備就緒。對于團隊來說，這絕對是漫長的一天！

Sylvie請求他們對Sprint計劃會議兩部分給予反饋，并與我和其他技術教練分享，我們可以看到他們在學習過程中慢慢開始理解（并相信）我們向他們解釋的內容（關于工作方式）。當我們在班加羅爾選擇團隊時，其中一位團隊成員說，他們已經閱讀并聽到了許多有關協作、授權、透明性和安全性的陳詞濫調（特別是當客戶拜訪他們時），但這是他們第一次體驗到現實。甚至由自己選擇Sprint中工作的條目也令他們感到震驚，因為他們已經習慣于由經理“分配”工作。我們可以清楚地觀察和體驗到組織系統對人們行為的影響。這反映了LeSS指南“文化遵循結構”，意思是在大公司里（在很小的公司里不見得如此）組織設計（結構、政策、流程、權力關系等）影響著觀念和行為。

離岸團隊的技術卓越

盡管所有團隊成員都知道技術卓越相關的實踐，例如測試驅動開發、持續集成、結對編程、基于主干的開發和持續交付等，但他們并沒有如此嚴格地使用過。他們很快意識到團隊不應該在質量上妥協，而應該堅信內建質量。例如，盡管沒有人要求結對編程，但他們意識到其他大多數團隊都是結對工作的，因此他們也決定應該結對起來。

幾天后，Sylvie觀察到，該團隊將從技術教練那里受益（“嘗試……專家教練的評審而不是指示設計（dictating design）”）。Sylvie的觀察是基于團隊在編寫代碼之后才寫單元測試，以及他們缺乏對結對編程（共同解決問題并獲得持續反饋）的理解這一事實。她與團隊分享了自己的看法，并向團隊提供了一個選項 - 安排一位技術教練和他們一起工作，以幫助他們更有效地學習XP的實踐。她還注意到，沒有人回應她的觀察，至少有2-3分鐘的沉默（盡管她感覺就象有近10分鐘）。對于Sylvie和團隊來說，這是非常令人不舒服的情況！她在想：“為什么他們保持沉默？”，團隊在想：“誰來做決定？”。他們不習慣做決定（因為以前這是經理的工作）。

每個人都經歷了令人不安的2-3分鐘沉默之后，一名團隊成員問誰將做出這個決定。

“你怎么看？”她（Sylvie）問。

“經理到達后，我們是否應該與之討論？”他（團隊成員）回答說。

“經理會帶來什么新的信息以幫助你們做出決定？”她問。

“好吧，他會決定的。這些決定是由經理做的。”他回答。

“你們認為誰最適合做這些決定？”她問道。

“嗯，經理。他對‘項目’了解更多。我們不想沒有他在場的情況下做出決定。”另一位團隊成員回答。

“這是離岸通常的工作方式嗎？”她真誠地問。

“嗯，是的。”他們幾乎同時說道。

“好的，你們的經理這個周末到，今天是周四，那我們就下周一他在這邊時再討論。”她回復并結束了討論。

討論結束后，Sylvie決定與我、還有其他Scrum Masters和技術教練討論這個情況。因此，她在屋里召集了一個短會，問大家對這種情況的建議。盡管對我們大多數人來說這是一個敏感的情況，但我們對其在班加羅爾辦公室的工作方式了解得更多。我們本可以很容易地把決定“強加”給團隊，但是我們希望團隊和來自海外的經理真正了解自組織的重要性（和力量）。我們知道，對新團隊來說這將是一段漫長而令人興奮的旅程。一位Scrum Master也向我們暗示，我們自己在轉變初期也經歷了類似的旅程，因此我們應該對新團隊抱有同理心。這是一個有力的提醒，我們為此感謝了她。

周一，Scrum Master和教練及經理舉行了會議來分享上次討論。經理說，他知道談話的內容，因為團隊在他到達時已經與他討論過。他說，由我們決定團隊如何工作就行。由于沒有固定的范圍或時間表，他沒有特別的傾向性。盡管我們在供應商選擇過程中向經理和離岸公司提到了技術卓越和自組織對我們的重要性，但我們了解到，這些對話在“贏得合同”后很容易被忘記。因此，我們提醒了經理，并解釋了我們想要的的工作方式不只是對團隊，也是對經理。我們要求經理（真正地）確保團隊應該感到自組織的授權。我們希望他在合作期間對團隊更像一個引導者。不確定他是否理解我們的意思，但他肯定地點了點頭。

因此，我們與團隊就增加技術教練的話題進行了進一步的對話。我們讓經理向團隊解釋了技術卓越和自組織的重要性，并要求他對團隊決策給予支持。他很坦誠地說，他理解這些不僅是對團隊而且對他本人來說都是全新的工作方式，因此可能會遇到一些挫折，但承諾與團隊進行透明的討論。團隊同意聘請一名技術教練來幫助他們學習XP的實踐。團隊建議他們應該嘗試幾個Sprint，并在以后的團隊回顧中進行另一次對話。這是他們提出的第一個建議，可能會是成為自組織團隊的第一步。

因此，我們增加了一名技術教練。教練沒有任何特別的權力。他的主要職責是與團隊一起工作（結對），并向團隊介紹各種概念（TDD，A-TDD，持續集成，結對編程，設計原理等），以進行長期的學習和集中精力在內建質量上。

盡管團隊決定在下一次Sprint之后再評估引入技術教練的效果，但他們在當前的整體回顧中已經提到了積極的影響以及他們（個人）學到的東西。

技術教練花了三個Sprint后覺得團隊已經掌握了XP實踐的主要概念和應用，并同意繼續努力提高他們的技能。教練回到了原來的團隊，但團隊知道，如果他們需要進一步的幫助，他們將能夠與她聯系。

學到的教訓

我們從這次經驗中學到的是與離岸管理部門一起考慮決策，并幫助他們理解決策的理由和重要性以維持變革。他們在初期對團隊是有很強影響力的，因此對他們進行精益思維和敏捷原則的教育，對于長期持續的變革同樣重要。

離岸團隊又花了三個Sprint在現場工作，然后才搬回班加羅爾的辦公室。離岸團隊成員與其他團隊成員建立了真正的融洽關系。他們（逐漸地）與其他團隊成員之間更加開放和透明，并且從他們的互動中很明顯看出他們確實喜歡在英國的逗留和學習。他們請求我們是否可以讓Sylvie（Scrum Master）與他們一起到班加羅爾呆（工作）一會兒，以保持對學習的支持、持續變革和對離岸管理教授精益思維和敏捷原則。

我們問Sylvie是否愿意把握這個機會，在班加羅爾呆一段時間來提供幫助和支持。她很高興（很興奮）在班加羅爾呆上三個月。我們還認為這將有助于我們在班加羅爾為離岸團隊招募Scrum Master。

離岸團隊還建議在英國辦公室建立一個單一的聯絡點（現場協調員），以在他們需要任何支持時提供幫助。我們向所有團隊詢問了這一建議，有人建議不要為每個地點的整個團隊建立單一的聯系點（“避免…單點聯系人”），而是每個成員都應該選擇一個伙伴（“嘗試…伙伴系統” ）。伙伴將確保當任何人需要他們所在地點的任何支持時都可以找得到。我們要求他們自組織來選擇一個伙伴，在15分鐘內，每個離岸團隊成員和現場團隊成員都有了一個伙伴。因為在現場我們有更多的人員，每個離岸團隊成員其實有多個伙伴。

班加羅爾的工作環境

離岸團隊到達班加羅爾辦公室時，他們為設置的新開放空間環境感到非常驚訝。每個工作站都有兩個27英寸的顯示器，用于結對編程的更寬的辦公桌空間，一個網絡攝像頭（“嘗試……眼見為實 - 無處不在的便宜視頻技術和視頻文化”）和Skype / Google Talk設置以及用于支持設計工作坊的長長的白板。我們還在英國的廚房區域和班加羅爾的放松空間安裝了網絡攝像頭，來創造一個更加有趣和非正式的環境。兩個地點都有一個視頻會議室。盡管在英國這個視頻會議室主要是為我們團隊使用，但在班加羅爾的視頻會議室是與其他人共享的，因此他們確保在接下來的3個月中對每個Sprint的第一天和最后一天作了提前預訂。

多地配置的初始挑戰

由于我們總共只有五個團隊（現場和離岸），因此我們沒有計劃改變工作方式。我們認為應該無縫運行。但是很快，我們意識到了與多個地點的團隊合作的挑戰。盡管我們有可用的網絡攝像頭和會議設施，但互聯網連接不暢通常會造成很多問題，尤其是在跨團隊交流中。不同的時區也意味著我們必須調整Sprint計劃，Sprint評審和整體回顧會議的時間。

我們面臨的一個相當大的問題是，班加羅爾的團隊使用在英國托管的共享svn倉庫。即使我們在兩個地點之間擁有專用快速的網絡，但班加羅爾的團隊經常會遇到訪問svn的速度較慢的情況。他們與英國團隊討論了該問題，并同意使用基于Apache HTTP（“ httpd ”）服務器的svn從屬復制（“嘗試……跨地點在同一倉庫中進行持續集成”）。安裝Apache HTTP后，普通的svn寫入會立即被透明地推送到班加羅爾的所有復制的從屬倉庫，而普通的svn檢出或更新則直接從本地從屬獲得。

團隊面臨的另一個重要問題是在Sprint評審期間互聯網連接的丟失或緩慢。因此班加羅爾的團隊常常會為他們在Sprint中構建的特性（所有用戶場景）錄視頻，并在視頻播放后獲取反饋。錄像幫助團隊避免了在Sprint評審期間由于網絡故障而造成的不必要的時間浪費。向用戶播放視頻后，團隊、用戶和PO便會進一步探索學習內容以及下一步的工作。

增加更多的團隊

在對一個多地離岸團隊進行了四個月的試驗之后，我們相信可以在班加羅爾辦事處增加更多的團隊。我們與離岸團隊（和經理）討論了增加更多團隊的需求。他們都建議一次只增加一個團隊，因為我們可能很難找到合適的人。他們還提供幫助以確保更快地過濾人員，從而使我們不必經歷冗長而痛苦的過程（就像上一次我們選擇第一個隊伍時那樣）。我們接受了他們的建議，讓他們根據技術測試和初輪面試進行初步的技術篩選。這次我們在招聘團隊成員的同時也專注于招聘Scrum Master，離岸經理也邀請了外部的Scrum Master候選人。

實際上這次我們設法增加了兩個團隊和三個Scrum Master，因為我們也可以面試外部候選人。我們為外部候選人安排了一個月的準備時間，從而確保他們在加入團隊之前已經有了設置好的工作環境。

同時，我們還設法在英國又招聘了一個團隊。所以現在我們在英國有五個團隊，在班加羅爾有三個團隊。我們保持了將團隊帶到英國進行前四個Sprint的策略，以教授每個團隊掌握更好的技能和思維方式。

我們在增加團隊上成功的關鍵是，我們沒有偏離Scrum（原則：LeSS就是Scrum）。我們的產品（而不是每個團隊）有一個（且只有一個）產品負責人，并且我們確保正確的人員（客戶、SME和團隊）參與產品待辦列表梳理（LeSS規則）：

“?產品負責人不應獨自致力于產品待辦列表梳理；他們得到多個團隊的支持，而團隊與客戶、用戶以及其他利益相關者直接合作。”

我們產品的增長（更多的客戶和特性）對我們的產品負責人增加了許多要求。產品待辦事項列表增長以包含新功能，使得我們的產品負責人維護它變得越來越困難。盡管我們的產品負責人沒有參與條目的詳細澄清，但與9個團隊工作對他來說還是難以管理內部和外部重點。因此，我們決定引入需求領域和領域的產品負責人（“嘗試……在有多個團隊的情況下引入領域產品負責人”）。

我們的產品待辦列表已經是將所有以客戶為中心的特性組織在一起，因此提出以客戶為中心的需求領域并不難。我們在產品待辦事項列表中添加了新列，以便產品負責人和領域產品負責人可以過濾產品待辦事項列表以查看特定的需求領域。

領域產品負責人與其他領域產品負責人和整體產品負責人一起工作，以保持整體產品的焦點和相應地在其領域內對特性排序。

每個APO（領域產品負責人Area Product Owner）與大約4-5個特性團隊合作，所有團隊都在同一個兩周的Sprint周期中。

每個團隊都有一個Scrum Master（SM）。

18個月后，我們逐步在四個需求領域中（隨著產品范圍的擴大）建立了19個特性團隊。

協調與事件

協調

團隊坐在同一樓層的優勢之一是跨團隊的協作。例如，在需要跨團隊協作時，該領域的團隊成員通常會互相加入彼此的每日站會，學習并與他們的團隊分享學習的知識（“指南…偵察兵”）。針對復雜的特性或條目，兩個團隊通常會一起工作來共同解決問題（如今稱為暴徒式編程mob programming）。

如果大型且復雜的特性需要兩個以上的團隊一起工作，則通常由一個團隊來主要負責（“指南…帶頭團隊”），以確保他們學習、共享學習并就所需特性與任何內部或外部小組協調。例如，在開發該產品時，我們必須使用MATIP（基于互聯網協議的航空交通地圖Mapping of Airline Traffic over Internet Protocol）與Amadeus和Worldspan接收和傳輸航空預訂和票務信息，有一個團隊與第三方合作來學習如何在我們的產品中實現MATIP，并與其他團隊分享學習的經驗。考慮到這是我們第一次使用該協議，他們還負責去數據中心進行端到端測試以確保該特性按預期工作，從而將其部署到生產環境。

總體產品待辦列表梳理

當我們每個領域都有大約四到五個團隊時，要讓所有團隊坐在一起來梳理產品待辦列表變得越來越困難。我們選擇引入“總體產品待辦列表梳理”會議。該會議每個Sprint僅發生一次，主要目的是讓每個團隊的代表聚在一起，對他們將要帶入到團隊的產品待辦列表梳理（PBR）以為下一次Sprint做好準備的條目進行輕度的協作分析。他們還確保沒有一個團隊會從待辦事項中拿走所有高優先級的條目，而是平均分散到多個團隊，以最大程度地降低單個團隊未完成高價值條目的風險，從而避免“關鍵團隊”的脆弱性（“提示：將高優先級條目分散到各個團隊”）。在會議結束時，所有團隊都清楚地知道他們選擇梳理下一個Sprint的哪些條目，不僅知道自己團隊的，而且知道他們領域所有團隊選擇的條目。該會議的時間盒為每個Sprint一小時。

###（單團隊的）產品待辦列表梳理

團隊代表在整體產品待辦列表梳理（PBR）會議中選擇的條目由各自團隊梳理。每次梳理會議均由領域產品負責人主持，他常常會帶來相關的SME和客戶代表。每個團隊都圍繞用戶故事的三個關鍵方面（即卡片Card、對話Conversation和確認Confirmation，Ron Jeffries稱之為3C）開展對話，以確保在進行Sprint之前已準備、討論和確認了該條目。在我們兩周的Sprint中，一個領域內的每個團隊通常都要進行三到四次PBR會話（每次一個小時），這符合PBR占用Sprint 5-10％時間的的指導原則。

Sprint評審

我們最初的Sprint評審是在每次Sprint結束時，產品負責人、APO、SME和團隊之間進行的。隨著我們團隊的協作工作日趨成熟，我們有越來越多的SME、APO參與其中，每個條目在完成時都與產品負責人、SME進行了評審，但是我們很快意識到我們缺少跨團隊的產品進度和學習經驗。因此，我們嘗試了完全跨領域Sprint評審的形式，通常按每個領域（一個一個地）來評審每個領域對產品增量貢獻了什么以及是如何貢獻的。

所有領域（包括產品負責人和領域產品負責人）、業務利益相關者、SME和管理人員均參加這個評審；評審引發有趣的“產品重點”的對話。有時，這些對話本質上是探索性的。例如，我們如何改善特性或與其它可用產品集成以提高產品的整體功能等。其它時候則討論可以將本產品帶入的其它市場。所有這些討論產生出產品待辦列表中的新條目，以供將來探索。

這種評審形式對于團隊了解整個產品的增量以及了解不是他們構建但在同一Sprint中交付的功能非常有幫助。

Sprint回顧會

像預期的那樣，Sprint回顧會議通常由每個團隊分別進行，但有時某個領域的團隊會一起回顧，尤其當這些團隊共同工作于某個特性時。這有助于他們彼此之間進行對話，以學習如何進一步改善跨團隊的協作。一到兩個商定的行動會添加到下一個Sprint待辦事項列表中，并像其它任何Sprint待辦事項條目一樣進行跟蹤。

教練與持續改進

我們為開發團隊和高級管理團隊提供了有關Scrum、技術卓越和系統思想的持續指導，以促進協作、自組織和專精。

我們在整個部門有個根深蒂固的原則 - “先承諾才有成功”。對于管理團隊而言，這意味著他們必須先展現對創建透明、授權和信任的環境的承諾并投入到系統思考。我們花了很多時間指導管理團隊，以理解我們每個行動的因果關系。我們還幫助他們建立了價值流圖，以理解工作流程，從而識別系統中的浪費和改進領域。管理團隊不斷展現他們想獲取成功的承諾，他們投入時間來理解系統模型。盡管大多數先前的功能失調是由管理人員和結構造成的，但他們從中吸取了教訓并幫助我們創建了更好的未來系統狀態。他們幫助團隊創建了一個可以安全失敗的環境，團隊可以在其中學習并將學習到的經驗分享到整個組織。

影響與結論

這種轉變對企業的影響是巨大的。在第一個產品發布后的24個月內，我們的客戶增加了5-6個，而投資回報率則比開始時預期的增長了大約八倍。

我們從這種轉變中獲得的主要經驗是保持簡單。盡管我們在18個月內從兩個團隊發展到19個團隊，但是我們并沒有添加不必要的角色來管理依賴或進行協調而使組織設計復雜化。我們簡化了組織設計來“縮小規模”，并不斷消除團隊和客戶之間的任何障礙，從而獲得更快和更真實的反饋。

所有特性團隊一直致力于適應技術卓越。我們雇用了許多具有XP背景的優秀開發人員，他們幫助現有團隊成員采用A-TDD、TDD、結對編程、跨團隊編程、持續集成和持續交付。我們在18個月里從每月部署轉向持續交付。我們將完成的定義擴展到把每個條目部署到臨時環境（由于法規限制而不能部署到生產環境），并且我們使用特性開關來打開或關閉功能，直到這些特性被我們的客戶完全接受。啟用持續交付還幫助我們采用多變量測試進行了許多快速實驗，這使我們能夠確保在承諾做更大的特性之前先收集數據。

我們的離岸供應商適應并擁抱了我們的工作方式，班加羅爾的所有團隊都喜歡這種方式。對于大多數人而言，這不僅是一個定義職業的時刻，對于某些人來說而且是改變人生的時刻。他們都不想回到過去的工作方式，因此他們不斷致力于持續學習以提高自己的技能。離岸經理告訴我們，這個“項目”在他們公司內部引起了不同的好評。他們的員工甚至要求加入！離岸供應商聲稱，相比印度離岸市場20％的人員流失率，我們團隊的人員流失率僅為8％左右。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。