阿里敏捷教練：多團隊開發一個產品的組織設計和思考

時間 2019-12-06

原文原文鏈接

摘要： Scrum等敏捷開發框架，最初都是爲5到9人的小團隊設計的。經過保持專一和合理利用新技術，在至關長的時間裏小團隊仍然能夠支撐業務發展。隨着業務成長，小團隊的產出可能跟不上業務須要，團隊就會面臨規模化的問題。

Scrum等敏捷開發框架，最初都是爲5到9人的小團隊設計的。經過保持專一和合理利用新技術，在至關長的時間裏小團隊仍然能夠支撐業務發展。web

隨着業務成長，小團隊的產出可能跟不上業務須要，團隊就會面臨規模化的問題。從1個團隊拓展到3個團隊，仍然能夠經過簡單的團隊間溝通保持高效協做。當產品複雜到須要5個以上團隊同時開發時，咱們須要必定的組織設計來保證團隊間的順暢協做，使得多團隊共同開發一個產品時仍能保持敏捷性。算法

保持小團隊

在初創企業或產品剛起步時，團隊一般都不大。隨着業務的發展，需求愈來愈多，產品愈來愈複雜，不少團隊的第一反應都是加人。事實上，加人並非惟一選擇，也未必是最優選擇。不少時候，小團隊能交付驚人的業務成果。架構

一方面，經過保持專一：Do one thing and do it well，小團隊能夠聚焦於核心業務，摒除沒必要要的干擾。有一款微處理器ARM比英特爾先作出來，團隊的一個leader說：「回過頭來看，當時咱們決定作一款微處理器的時候，我認爲我作了兩個重要的決定。我信任個人團隊，而且給了團隊兩件英特爾和摩托羅拉永遠不會提供給他們員工的東西：第一是缺錢，第二是缺人。他們不得不保持簡單」。相似的，創辦於2009年的WhatsApp於2014年被Facebook收購時，公司只有55名員工，全球活躍用戶達到4.5億人，日發送短消息達160億條。併發

另外一方面，隨着開源運動、中臺技術和雲化技術的發展，不少非核心業務邏輯能夠藉助外力快速搭建，在業務高速發展的同時，繼續保持一支精幹的團隊。例如，在阿里巴巴研發協同平臺「雲效」上，二十分鐘就能夠搭建一套Spring Boot web application的持續集成流水線，包含靜態代碼掃描、單元測試、編譯、打包、部署、接口測試。不只操做方便快捷，還省去了採購機器、部署和管理 build farm的開銷。app

業務單元特性團隊

即使努力保持專一併用盡了技術紅利，有時業務的發展仍是遠遠超出預期，此時組建多個團隊勢在必行。框架

比較理想的選擇是按照業務單元來組建特性團隊。一個業務單元相似於一家小型創業公司，有本身的長期使命和願景，有相對清晰的業務邊界和盈利模式。人員方面，各業務單元有獨立的業務、產品和研發團隊。技術方面，各業務單元能夠獨立完成產品開發的全流程，包括業務決策、產品設計、開發、測試和發佈，儘可能避免業務單元之間的依賴。工具

做爲一個超級app，手機淘寶分爲幾條業務線，同一條業務線內還分爲幾個獨立業務。例如，微淘和淘寶直播都屬於內容平臺業務線，兩者的內容生產、傳播渠道、受衆和盈利模式不一樣，於是是相對獨立的業務單元。兩者有獨立的業務、產品和研發團隊，業務目標也分開設定和衡量。單元測試

技術上解耦是各業務單元可以獨立發展的前提。爲了解決團隊間的依賴，手機淘寶對架構作了容器化改造：一些必要的初始化操做放在common容器中，各業務在本身的bundle中。各業務bundle按需加載，只能依賴底層的common架構，不能相互依賴。這樣各業務bundle能夠並行開發，互不干擾。學習

按照獨立的業務邊界來組建特性團隊，團隊能獨立發佈新功能，迅速得到市場反饋，經過不斷試錯找到業務發展的方向。測試

全球第一大音樂平臺、音樂流媒體公司Spotify也按照業務單元組建團隊。在" Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds "[1] ，敏捷教練Henrik Kniberg詳細介紹了Spotify模式。

Spotify的30多個「小分隊」（squad）分佈在全球的三個城市，每一個squad負責產品的特定方向（例如搜索或radio）。每一個squad至關於一個小創業公司，squad沒有特定的主管，只有一位產品負責人（Product Owner）。PO負責業務方向，squad成員組成跨職能團隊交付業務結果。PO幫助squad制定目標和管理優先級，也會按期維護公司層面的產品路線圖並確保squad的目標與公司戰略相匹配。squad被鼓勵應用精益創業原則，例如先交付MVP（minimum viable product），並經過A/B測試來驗證假設。此外，squad能夠獲得敏捷教練的幫助，敏捷教練引導squad持續改進並幫助團隊移除障礙。

在squad之上，spotify還有兩層組織架構：具備相關專業知識的人橫向組成「分會」（chapter），工做在類似領域的squad組成「部落」（tribe）。此外，具備相同興趣的人組成「行會」（guild）。

這套架構的主要目的，是促進全公司範圍的信息和知識共享。員工向chapter lead彙報，在轉換squad時彙報線不變。儘管看上去像普通的矩陣式組織，這個矩陣是向產品交付傾斜的。同一個squad的成員坐在一塊兒，組成高度自治的跨職能敏捷團隊，共同決定產品目標以及如何交付產品。橫向的chapter維度只是爲了更方便地共享知識、工具和代碼。chapter lead的工做是引導和支持信息流動和知識共享，而不會像傳統職能經理那樣負責分配工做。

注：圖片來自於https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

與此相似，淘寶直播的業務、產品和研發團隊也彙報給不一樣的職能經理。高度統一的業務目標把團隊成員凝聚在一塊兒，團隊共同決定業務方向、業務目標以及如何達成目標。職能經理爲業務發展提供支持和幫助，並幫助團隊成員在職業道路上成長，並不會把主要精力放在具體的產品交付上。淘寶直播敏捷實踐參見《阿里敏捷教練，全面解析淘寶直播敏捷實踐之路》。

無限制特性團隊

有時團隊在業務發展時壯大了，可是通過了一段高速發展，原有的業務方向遇到了瓶頸，新的業務方向還在摸索中。此時，業務方向還不明朗，難以按照明確的業務單元組建團隊，團隊須要快速適應業務方向的變化。此時，要鼓勵團隊廣度學習，避免局部優化。

不一樣於圍繞業務單元組建的特性團隊，無限制特性團隊沒有相對獨立的業務領域，多個特性團隊共享一份產品代辦列表（Product Backlog），按照統一的優先級交付產品功能。無限制特性團隊，並不是全部團隊都相同的無差異特性團隊，每一個團隊仍是能夠有本身的特點和專長，只要多個團隊組合起來可以按照Product Backlog的優先級交付特性便可。

2018年3月，我支持阿里健康互聯網醫療業務線時，正遇到這樣的狀況：互聯網醫療業務通過兩年多的摸索，找到了一些可能的發展方向，可是尚未找到很是明確的盈利模式，多個方向都須要進一步嘗試。研發團隊包括服務端開發、H5開發、Android開發、iOS開發、測試等30多位同窗。

在原有的資源池模式下，每個月職能經理按照產品經理的輸入，分配研發同窗到各個項目中。因爲業務的複雜性，產品涉及的核心應用有15個以上，除了電商平臺的商品、庫存、營銷等基本功能，還包含互聯網醫療特有的問診、掛號等服務，並涉及到算法和AI。人員技能的瓶頸很是突出：部分核心應用只有一位同窗特別瞭解。

2018年4月至5月，商品模塊負責人和AI問診模塊負責人前後休假，相應模塊的技術方案設計幾乎停滯，嚴重拖累進度。爲了平衡複雜的人員技能和項目須要，職能經理常常絞盡腦汁，仍然難免捉襟見肘，一線同窗身兼多個項目很是廣泛。多個項目都依賴同一位團隊成員時，不得不串行等待。在多個項目間頻繁切換也增長了上下文切換成本。

爲了解決人員技能瓶頸的痛點，同時考慮到互聯網醫療特定的業務發展階段，嘗試了無限制特性團隊共同交付一個產品的協做模式：30人自由組合成兩支特性團隊。組隊只需知足約束條件：人數均衡，核心應用在每一個團隊都有人瞭解，新老結合，男女搭配。組隊成功後，兩支團隊從同一份Product Backlog裏按照優先級領需求。若是某個團隊沒法獨立完成當前最高優先級的需求，先由這個團隊認領，另外一個團隊派師傅指導。師傅主要是培養徒弟，具體工做由認領團隊的同窗動手完成。

因爲資源瓶頸的限制，2018年5月1日到6月14日需求交付的累計誤差（需求實際交付日期與計劃交付日期的誤差累加）達到了151天。通過兩個月的努力，兩支特性團隊都具有了完成各種需求的能力，團隊能夠徹底按照Product Backlog的優先級領需求，既不須要團隊成員併發支持多個項目，也不須要等待資源瓶頸的釋放。6月15日到7月31日的累計交付誤差縮短到了3天。8月1日到8月31日繼續保持準時交付，累計交付誤差爲2天。團隊成員的我的能力獲得了充分鍛鍊，主動拓展技能承擔重任的同窗得到了晉升，獲得了承認。團隊的自組織能力也獲得了發展，遇到問題和阻礙，團隊成員會主動想辦法解決，再也不事事依賴職能經理。職能經理的角色從派活變成了輔導和幫助團隊，減小了救火時間，有更多時間考慮團隊的長遠發展。

綜上，無限制特性團隊方案解決了業務需求等待資源瓶頸的痛點，不是讓業務發展來匹配人員的技能，而是人員拓展技能匹配業務發展的須要。與此同時，團隊成員的我的能力獲得了鍛鍊，團隊的自組織能力獲得了發展，也解放了職能經理。

不管是業務單元特性團隊，仍是無限制特性團隊，每一個團隊都要具備獨立交付產品特性的能力。一個複雜的產品特性，一般都須要修改多個模塊才能實現。多個團隊修改同一個模塊時，如何保證模塊設計的一致性，並及時清理代碼償還技術債？

引入模塊守護者一般是個有益的實踐：每一個模塊最好有兩位模塊守護者互相backup，修改模塊代碼須要請模塊守護者作code review，一些複雜的修改最好預先進行設計評審。模塊守護者能夠是兼職的，只要保證每週抽出必定比例的時間維護模塊代碼便可。

隨着業務方向愈來愈清晰，業務模式逐漸穩定，無限制特性團隊會逐步找到相對固定的分工合做模式，每一個特性團隊會逐步找到本身最擅長和最感興趣的產品方向。明確的產品方向，爲團隊提供了長期深耕的條件，團隊逐步成爲某一領域的專家。此時，無限制特性團隊就完成了向業務單元特性團隊的過渡。

小結

經過手機淘寶、Spotify和阿里健康的案例，我相信多團隊開發一個產品仍然能夠保持敏捷。

在業務方向明確的狀況下，按照業務單元組建特性團隊是最理想的選擇。在業務方向不明朗的狀況下，能夠先組建無限制特性團隊，再逐步過渡到業務單元特性團隊。不管採用何種組織設計，目的都是快速跑通業務閉環：持續地交付業務價值，並在真正的市場環境中檢驗假設，經過快速試錯找到在必定的利潤水平上爲企業或終端用戶提供產品和服務的可行方法。

參考文獻：

[1] https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify