Scrum等敏捷開發框架，最初都是為5到9人的小團隊設計的。通過保持專注和合理利用新技術，在相當長的時間里小團隊仍然可以支撐業務發展。

隨著業務成長，小團隊的產出可能跟不上業務需要，團隊就會面臨規模化的問題。從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，手機淘寶分為幾條業務線，同一條業務線內還分為幾個獨立業務。例如，微淘和淘寶直播都屬于內容平臺業務線，二者的內容生產、傳播渠道、受眾和盈利模式不同，因而是相對獨立的業務單元。二者有獨立的業務、產品和研發團隊，業務目標也分開設定和衡量。

技術上解耦是各業務單元能夠獨立發展的前提。為了解決團隊間的依賴，手機淘寶對架構做了容器化改造：一些必要的初始化操作放在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的工作是引導和支持信息流動和知識共享，而不會像傳統職能經理那樣負責分配工作。

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

無限制特性團隊

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

不同于圍繞業務單元組建的特性團隊，無限制特性團隊沒有相對獨立的業務領域，多個特性團隊共享一份產品代辦列表（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和阿里健康的案例，我相信多團隊開發一個產品仍然可以保持敏捷。

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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里敏捷教练：多团队开发一个产品的组织设计和思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。