敏捷水手——單體法到微服務之旅

\
本文要點
\\
探究持續四年多的漸進式改革是什么樣子；\\t
探索為什么在變革軟件和組織設計時要遵循康威定律；\\t
看看如何將領導力應用到不同的團隊、領域和層級；\\t
舉例說明變革管理如何依賴于理念和一貫的長遠目標；\\t
了解從職能型團隊到跨職能團隊的變革需要做多少工作以及能帶來多少回報。\

簡介

過去幾年，eSailors IT Solutions在技術和組織層面進行了重大變革：從功能筒倉到跨職能團隊，從看似裝配線的工作流到動態循環，從單體平臺到微服務，從層次化的命令-控制到團隊運作的領導力。本文將簡要介紹他們的變革之旅。本文將帶你了解大約四年之前我們從哪里開始，經歷了哪三個主要的變革階段才成為現在這個樣子。對于每個階段，本文都將概要地介紹以下幾個方面的內容：

我們當時的組織設置；\\t
主要的技術棧；\\t
我們面臨的最重要的挑戰；\\t
我們希望取得的變革成果以及我們實際取得的成果；\\t
我們的經驗教訓以及它們如何推動了進一步的改進。\

貫穿本文的一個重要主題是康威的假說“設計系統的組織……其產生的設計和架構等價于組織間的溝通結構。”1我們將把這一理論作為一面特殊的鏡子，用它來照一照我們自己的歷史。將組織設計和軟件設計對照有什么意義？我們從對公司溝通模式的探究中學到了什么？為什么康威定律仍然在傷害著我們？

我們從哪里開始

以前，在漢堡，對于那些只有75名工程師、全部員工大約只有120多人的小型軟件公司而言，生活很簡單。面對著大約300萬的客戶，我們的點子來自當事人、市場或法律部門。我們的平臺平均要服務于大約35萬活躍客戶，每年2.5億訂單。工作流程是由項目經理組織的。知識被職能筒倉完全隔離：軟件部門負責編寫特性，質量保證部門負責保證質量，運維部門負責確保軟件的穩定運行。如果我們需要修改任何基礎設施組件（如增加新服務器、不同的操作系統程序包），一個隸屬于其他部門（及國家）的團隊就需要進行必要的安裝準備。由于各種各樣的預算、合作和/或溝通問題，這種方法經常導致嚴重的延期。

圖1：eSailors的裝配線

我們那時的組織設置是什么樣子？

我們那時的組織設置是什么樣子？如圖1所示，我們的工作流組織非常像老式工廠里的一條裝配線。大多數員工都是在那五個部門（項目管理/市場營銷、設計、開發、QA、運維）的其中一個部門里工作。每個部門都有自己的管理結構，都有團隊負責人和部門主管。遵循著特定的沖刺周期和步驟，軟件工件從一個部門傳遞到下一個部門：

步驟1：市場營銷部門、法律要求或項目經理界定特性，但不進行有效的預驗證或評估；\\t
步驟2：設計部門根據經驗進行設計；\\t
步驟3：開發部門在一個軟件工件中實現功能，團隊使用Scrum，但對于UI變更，會咨詢一個專門的前端團隊（3周）；\\t
步驟4：QA部門測試（2周）；\\t
步驟5：為了防止基礎設施方面的更改，基礎設施團隊會準備系統；\\t
步驟6：Ops團隊將軟件工件部署到生產環境，并對其進行維護；\\t
步驟7：一個專門的團隊進行Bug修復。\

簡而言之，我們的價值流是瀑布式Scrum2。就是說，我們在傳統結構下實現了Scrum，我們的敏捷理念所關注的是局部，而不是整個系統。此外，我們在很大程度上還是筒倉形式的組織，采用傳統方式進行管理，以決策制定為中心，溝通通常是單向的，由自上而下的策略和自下而上的報告所主導。我們的組織設置如圖2所示：

圖2：eSailors最初的組織設置

為了變得更加敏捷，每個產品開發團隊都竭盡全力。圖3展示了我們的團隊設置。在本圖及后續出現的圖片中，DEV表示開發人員，QA表示質量保證，PM表示項目經理。即使每個團隊都有一名質量工程師，最終的質量檢查和軟件審批也還是由一個專門的質量部門所完成。團隊的質量工程師必須以一種質量部門審批時能夠執行的方式準備測試。

圖3：eSailors最初的開發團隊設置

我們的技術呢？

我們一點也不感到奇怪，這種模式反映在了我們的軟件架構中。技術被設計成一個單體平臺，基于一個緊耦合的代碼庫構建，總是作為單個軟件進行部署。我們的代碼大約有80%都打包在一個工件中。eSailors的工程師習慣將這個平臺稱為“大泥團”，因為它沒有一個可理解的架構，而且很難擴展和維護。部署是通過一個復雜的工具完成的，而且還受限于版本控制系統的邏輯。有時候，提交幾個小時后才看到單元測試失敗。由于構建和部署過程的復雜性，這個技術棧讓變更變得相當困難。

我們如何設法變革我們的流程？

康威定律指出，“設計系統（廣義而言）的組織其產生的設計和架構等價于組織間的溝通結構”。我們那時從對現狀的審查中了解到了什么？我們如何行動起來設置這兩種結構？我們的計劃是什么，而我們實際上取得了什么樣的成果？

我們從康威定律中汲取的其中一個最重要的教訓是：轉化成創新性產品以及縮短上市時間不能只依賴于技術變革。相反，組織變革和技術息息相關，需要對這兩個維度都進行檢查和相應的調整。雖然這在概念上聽起來很簡單，但改變我們的組織設置和思維花費了我們很長時間，而且現在仍然是我們需要首先處理的問題。

圖4：第一步：新的團隊設置

檢討我們的裝配線問題，我們決定創建跨職能團隊，由他們對整個系統開發的生命周期負全責。為了達到這個目標，我們從組織設置入手。我們解散了Bug修復團隊，讓特性團隊為自己的錯誤負責。這也可以幫助他們更好地理解操作上的需求。我們認為，跨職能團隊應該包含全棧職責，所以我們將原先共享的前端團隊的成員分配到特性團隊。同時，我們將沖刺周期改為兩周，一周用來開發，一周用來測試。

我們希望從這些組織變革中得到什么呢？從根本上說，我們希望提高軟件質量，縮短交付時間。我們實際上得到了什么呢？好了，我們的結果讓人覺得有點矛盾。一方面，加大團隊的自主權和責任感讓人們更清楚問題所在。但是，所有團隊都開始尋找可持續的解決方案，而不是修復問題。這種情況就是由圖4所示的新的組織設置所導致的。

讓開發團隊負責Bug從許多方面改善了運維和開發部門之間的溝通。DevOps交流項目啟動（開發人員在一個沖刺期間呆在Ops部門，反之亦然）。開發人員主動請求參與呼叫中心的工作及使用監控工具。組織文化日益趨向于端到端職責，這種變化越來越明顯。開發人員、運維人員和基礎設施人員開始定期討論系統和管理問題。這是進一步改進的關鍵。簡化后的裝配線如圖5所示。

圖5：第一步：管道

不出所料，領導力在許多層面得到了增強。過去，作為功能專家，工程師們習慣于構建自己的I型技能集。現在，他們開始讓自己向著跨職能團隊的T型領導者發展。團隊自己承擔了技術決策的職責，而不是專注于一種核心的架構。

另一方面，我們的共享代碼庫還是保持不變，還是會導致小的改進開發成本很高。

而且，我們開始認識到，我們的Scrum方法在許多方面都是失敗的。它沒有為我們提供正確的指導，卻首先增加了我們的負擔。我們經常因為需要修復即將出現的Bug而完全忽視了我們的沖刺承諾。將大的特性分割成較小的故事然后排定它們的優先級，這項工作費時費力。也許，最大的阻礙是作為我們主要客戶的項目管理和市場營銷部門的無法撼動的瀑布式思維。我們使用Scrum框架，但是在實現過程中沒有采用特性范圍。團隊的產品經理充當了管理者，將瀑布項目計劃分割成較小的不可變部分，而不是減少前期文檔以及檢查和調整每一個小的開發步驟。而且，我們的前端開發人員的工作流程很難管理。有許多次，團隊的其他人員都停下來，等待UI修改完成。在其他沖刺中，他們又無事可做，這種讓人沮喪的境況導致部分前端開發人員離職。

我們如何改變了航向？

我們從自己的變革中學到了什么？我們哪里違背了康威定律的觀點？這如何促進了進一步的提升？下面是我們找到的部分答案：

Scrum并不適合所有的團隊、所有的情況。那就是為什么我們必須要求人們檢查和調整自己的工作流程以滿足需要，并鼓勵他們了解業務的全局。\\t
所以，我們需要敏捷團隊關注端到端的價值流程，而不是仍然面向筒倉的Scrum。而且，我們需要敏捷教練有企業家的跨部門的視野，而不是像Scrum主管那樣只專注于一個團隊。\\t
我們還認識到，不只是領導者需要一個更趨向于T型的技能集，所有的工程師都需要。在特定領域擁有知識深厚的I型專家挺好，只要他們能夠并且愿意涉及其相應技術之外的主題。在理想情況下，將來我們的工程師既對跨部門協作持開放態度，又樂于改進軟件質量，而不會等到有了明確的業務需求才那么做。\\t
承擔起Bug修復的職責增進了我們對系統性問題的了解。另一方面，在使用一個大型共享數據庫的情況下，全心全意地投入到業務領域及相關軟件仍然相當困難。為了提升我們的速度和敏捷性，我們越來越迫切地感覺到要減少對業務端和技術端的依賴。\\t
如果不給團隊的產品經理充分授權，讓他們可以推動產品愿景的實現，那么他們就無法增加價值。我們只有對每個團隊充分授權，讓他們在整個開發過程中自主地創建、檢查及調整他們的特性，而不只是執行來自外部的需求，我們才可以有所作為。\\t
自上而下推動的決策過程無法達到預期的結果。為了鼓勵更多的創新，我們也必須支持自下而上的過程。\\t
雖然團隊授權是該做的事情，但跨不同團隊和部門的溝通以及協作仍然是一個大問題。\\t
只是改革我們的組織設置及創建新的角色是不夠的。作為一項分層橋接的跨職能的團隊活動，為了建立領導力，我們還必須解決所有管理角色之間的沖突。\

簡而言之，我們認識到，我們必須投入更多的精力，以便使用正確的方法構建正確的東西，而不是忙個不停。而且，我們必須加快我們的整體流程，并為此定義清晰的職責。為此，我們設定了新的改進指標。

首先，我們提升了UX和產品管理的重要性。在最高管理層的推動和外部培訓師的支持下，我們實現了一個包括用戶測試、用戶實驗室和團隊UX工程師在內的UX流程。同時，產品經理承擔為我們的客戶開發有價值的軟件的全部職責。為了減少眾所周知的溝通障礙，測試部門成了工程部門的一部分。如圖6所示，這形成了一個新的組織設置和工作流程。圖7展示了新的團隊設置。

圖6：新的組織設置和工作流程

圖7：第二步：新的團隊設置

不再堅持“純粹的”Scrum，團隊開始尋找新的敏捷方法。團隊改變了自己的組織方式。這是以一系列的團隊建設專題討論會為支撐的。我們通過這些研討會評估現狀，定義可以作為構建基礎的基本優勢，商定新的規則和價值觀。同時，通過運用各種不同的同伴反饋方法，我們培養了開放溝通和相互幫助的文化。

管理團隊也關注團隊建設。他們在整個業務部門內進行元回顧，定義可以作為構建基礎的優勢，深入問題和解決方案。一項重要的改進是，我們開始共同合作，創造性地評估相互矛盾的角色，提取出了精益領導力的第一個概念。任務重疊，界限模糊，決策策略讓人困惑，對于這種有些混亂的局面，我們如何有效地進行簡化？實際上需要什么樣的指導？每一種領導角色都增加了什么價值？需要多少角色？那些角色之間的職責如何劃分？

為了培養更多自下而上的流程，我們還修改了我們用來管理變更方案的方法。作為其中的一部分，我們開始在那些方案中包含更多的功能專家。我們新增了所謂的變更團隊，而不只是執行由高級管理人員定義的策略。該團隊的成員來自那些受變更影響最大的團隊，他們被賦予了自主權，可以在一個清晰的界限內研究并實現自己的解決方案。這與其他增強所有權的策略是一致的，比如各種社區實踐、有關松弛時間或聯合黑客馬拉松的明確協議。

我們主要關注的是提升人們提出更多思路和解決方案的內在動機，而不是試圖通過諸如金錢、獎金等這些由高級管理人員定義的外部動力來激勵人們。為了消除這種外部動力，其中一項改革是將薪金的一些動態部分移到了固定部分。由于其中的部分指標不再由上層管理人員定義，所以團隊自己設置自己的指標。

同時，我們繼續將我們的軟件拆分成微服務。在咨詢了外部軟件架構師之后，我們為了實現那個目標開啟了一項重大的重構計劃。通過這項計劃，我們希望可以獲得完整的跨職能團隊，通過獨立部署縮短上市時間。我們希望創建對特定領域的技術和業務全權負責的團隊。

在建立了重構團隊并提取了第一個微服務后，項目終止了。高級管理人員的整體參與度還是太低，而且作為一個整體進行重構太大太冒險。由于重構計劃停止了，所以周期時間仍然很長，創新成為意外而不是慣例。我們的技術債務仍在增加。這反映出，我們的組織結構仍然妨礙改進。我們把大量的時間浪費在了權限討論上，而不是提升軟件質量或者實現新的技術。為了有效地實現微服務，我們需要給產品團隊更大的自主權，讓他們選擇自己的工具，并全權負責包括部署在內的整個軟件生命周期。即使在上述大規模的重構計劃終止以后，工程師們還是深信，將共享的遺留代碼庫遷移到更小的服務不可避免。現在，我們的新做法是，只要有新需求添加到相應的代碼區域就刪除舊有的業務邏輯部分。

作為改進工作的一部分，團隊改變了維護內部部署和測試框架的習慣做法。他們停下來開發自己的解決方案，致力于保持現有工具的穩定性。我們一致同意使用一種新的策略，讓我們可以使用開源的部署和測試工具部署每一個新的服務，而不是使用舊有的內部工具。這樣，產品團隊變得日益強大，對有效地改進東西越來越有信心，他們開始推動創新。

發現新大陸

所有這些指標把我們帶到了哪里？什么有了實際的提升，什么保持不變，而什么變得更糟？以下是對我們2015年及2016年前2個季度一直忙于開展的工作的總結。

在技術方面，我們繼續向著獨立的微服務發展。同時，我們改善了基礎設施部門和工程部門之間的合作。基礎設施部門的人員開始向工程師們的實際需求看齊，而不是或多或少地獨立創建和維護他們自己的服務，忽視了依賴。

逐漸地，部分產品團隊承擔起了為新服務創建所需基礎設施以及運維新服務的職責。因此，團隊現在可以從操作系統層面開始加入自己的技術。這是逐步建立DevOps文化的其中一個先決條件。

我們還實現了工程工具的現代化。工程師現在可以自由選擇自己的工作站或者筆記本電腦，而不是一個中央虛擬機。一方面，他們有更大的自由來創建自己的環境和工具，另一方面，他們必須增強自己的主人翁意識。此外，我們使用GitHub開辟了新的軟件開發路徑。

在組織設置方面，我們繼續向著精益領導力發展。如圖8所示，我們刪除了ScrumMaster的角色。對于這個角色，我們認為其作為敏捷催化劑的功能已經完成，團隊已經足夠成熟，可以實現自組織。我們一舉建立了一個精益-敏捷教練（LAC）池，可以提供支持團隊及管理者的新途徑。

圖8：現在的開發團隊設置

我們還加大力度，使重要的信息盡可能地透明。可視化管理系統的問題變得愈加重要。產品經理引入了所謂的“墻”來展示有關當前業務選項和即將到來的變更的信息。圖9展示了設在辦公室中央開放空間里的這塊板子的最新版本。通過這種方式，我們增加了業務流程的透明度，從通過評估和選擇創建業務選項，到開發、驗證和完成——這塊看板增強了人們的求知欲，促進了溝通交流。

圖9：“墻”

談及透明度，整個公司都開始每個季度會面，分享團隊在最近一個季度里完成的工作以及他們希望在下一個季度里達到什么目標。以新方法為基礎，我們還構建了更為透明的變更方案。變更團隊的實施方案會同各方面的利益干系人進行公開討論，例如，使用魚缸討論法的形式。這種方法更容易讓那些受影響的人參與進來，了解工作進展，促進總體投入。這還有助于直接傳遞變更的內容和原因，讓人們對變更的實現方法有一個統一的認識。變更的能量來自于面對面的交流和協商一致的行動，而不是官方公告、正式的啟動會議或者專家的總體規劃。

我們提供了一系列的領導力培訓，例如，關于如何領導一個人員來自各個領域的自組織團隊。第一次，來自不同領域的領導者，如產品經理、團隊負責人、董事和HR，都致力于就未來如何管理公司達成共識。為了有效地支持自組織，需要什么？就能力和實踐來說，這意味著什么？共同探討精益和敏捷領導力的原則，他們還增進了彼此之間的了解，增加了信任和相互理解。

所有這些方案幫我們減少了筒倉邏輯，培養了專注于整個價值流的跨團隊協作。與此同時，整個工程部門還形成了一種事后反思和回顧的新文化。實際問題和重大事宜現在都是直接溝通，而不是背后指責和議論。不管是在系統層面，還是在個人層面，提供和接收誠實的反饋都是非常有價值的。

我們現在的狀況

所有這些變革對我們的業務有什么影響？我們的變革之旅對我們現如今的自我組織方式有什么意義？再次對照康威定律，圖10和11展示了我們現在的組織結構。

圖10：2016年eSailors的組織方式

圖11：2016年eSailors的組織結構

在擺脫了裝配線流程后，現在，跨職能產品團隊成為我們關注的焦點。它們是我們保持高效、作出所有重要決策以及推動任何必要變革的引擎。產品團隊的重點工作不再是根據特定的規范開發軟件產品，然后交付給或多或少不連通的部門，相反，他們既可以決定實現什么，又可以決定如何實現。其他部門提供支持服務，比如數據、基礎設施或者咨詢。每個團隊都可以獨立地部署和監控他們的軟件。不過，他們通常會合理利用運維部門提供的工具。類似地，團隊可以自己做些用戶研究，但會有一個用戶實驗室為他們提供支持。

圖12說明了現如今的產品團隊如何涵蓋了整個開發周期。該循環始于識別客戶需求和痛點。基于在這個發現階段了解到的內容，我們可以發現商機，并使用一個特定的畫布對它們進行評估。接下來是設計原型以及用戶測試，從中我們可以了解到實現正確的功能所需要的一切信息。經過一定數量的循環后，這些功能就不會發布到生產環境里了，然后我們會進行監控，并通過A/B測試進行微調。

圖12：eSailors的開發周期

我們的技術也發生了極大的變化。從原先一個很小的技術集和占主導地位的“大泥球”，我們設法減少了后者，并增加了前者的多樣性。我們不再什么系統都僅使用一種數據庫解決方案（Oracle），而是在生產環境中使用多種不同的數據庫（Oracle、Mongo、Redis、Elasticsearch、Cassandra）。我們不再僅僅關注一門編程語言（Java），我們現在使用不同的語言（Java、Scala、Go、Swift）。還有其他新的工具和庫，例如，docker、ansible、vagrant、angularJs、consul或openstack。每個團隊都有特定的功能領域。他們現在有權自己選擇最適合團隊需求的技術棧，為他們的特性構建解耦合的微服務。通過選擇恰當的工具，而不是實現某項共享技術的變通方案，將新特性交付到生產環境變得越來越快越來越簡單。這是可能的，因為團隊的工程師現在可以專注于自己的部分，并對自己所開發的服務的全生命周期負責。如果不是對技術棧全權負責，如果需要向其他部門進行徹底地交接，那么這種技術的異構性是不可能的。

我們還沒有完成我們的微服務架構，但是我們使用微服務實現了所有的特性。我們還在繼續逐步地改進我們的架構。發布新服務的提前期也有了顯著的改善。現在，新服務幾分鐘內就可以構建、標記、測試和部署到生產環境。有時候，從構思到完全實現只需要一天，而不是幾周。

雖然我們取得了許多成果，但是我們仍然面臨著巨大的挑戰。一方面是技術挑戰，比如我們的架構的復雜性、我們接下來的微服務旅程或者保證設施隨時可用的困難。同時，我們面臨著組織和業務上的挑戰。在通向始終如一的精益敏捷企業的道路上，我們還面臨著一項挑戰，就是團隊沒有真正的得失責任。即使一個產品團隊成功地使其價值流的所有干系人都參與進來，其工作的整體成本和回報對這些人來說也是不透明的。

完備的企業產品管理職責是當前困擾我們的一個問題。產品經理關注收益（收入、注冊量……），而成本本身（人員編制、工資、硬件、外部服務、培訓……）是工程成本中心的一部分。內部基礎設施的成本或者產品的營銷成本根本沒有體現到產品團隊上。

為了追蹤行動的成本和收益，我們在數據及KPI可視化方面取得了很大的進步。但是，因為無法將實現成本、基礎設施的成本和工作映射到這類行動上，所以通常很難評價一項實現是否增加了任何價值。

跨團隊交流和整個系統的公共視圖是困擾我們的另一個問題。現在，我們還不是很清楚應該如何改進我們的端到端工作流。目前，我們即將研究如何使用我們的“墻”（見圖9）作為一種方法來更好地管理我們的價值流——即所謂的看板“飛行高度（flight level）”34。通過擴大業務視角，我們可以從一步一步的價值創造流程中獲得新的視角……而且，為了統一監控和積極控制整個公司里正在發生的事情，我們考慮將所有領域的代表都包含進來。我們堅信，這可以提升我們的能力，讓我們可以更好地區分選項，改善提前期，通過較小的努力提供更大的價值。

參考資料

“How Do Committees Invent?” Melvin E. Conway\\t
“分析師瞭望：Water-Scrum-fall是敏捷的現狀”Dave West\\t
“領導自組織團隊” Siegfried Kaltenecker（免費下載）\\t
“看板的飛行高度” Klaus Leopold\

關于作者

Michael Gruczel是esailors移動App團隊的團隊負責人。在實際的工作中，他像仆人一樣工作，但有時候又是一名具有破壞性的領導者。他曾經做過咨詢顧問，為德語版的Java Magazin和jaxenter寫過一些技術文章。感興趣的讀者可以通過linkedin、twitter（@mgruc）聯系他，或者通過他的github個人資料了解他。

Sigi Kaltenecker是Loop Consultancy的聯合常務董事，專注于精益和敏捷變革。他已參與了多家國際性公司的改革，包括Alcatel、bwin.party、eSailors、Kaba、ImmoScout24、Magna、RWE、Swiss Federal Railways或Thales Group。Sigi是《領導自組織團隊》、《看板改革領導力：創建持續改進文化》（Wiley 2015)）的作者，并在“Peer Feedback Loops”上發表了一系列的文章。感興趣的讀者可以通過電子郵件（siegfried.kaltenecker@loop-beratung.at）聯系他。

Hans Gruber是eSailors漢堡公司的工程負責人和董事總經理。他有很強的工程背景，在類似Tele2和bwin.party這樣的國際性企業里逐步建立起自己的專長。他致力于通過采用精益和敏捷實踐來改善團隊，因為他堅信，技術和產品團隊可以做到精益求精，并借此提供卓越的客戶價值。感興趣的讀者可以通過linkedin聯系他。