Spotify的敏捷擴張之道：部落、班、橫向編組與同業公會

Henrik Kniberg & Anders IvarssonJune 18, 2013

Contents1 班（Squads） 2

2 部落（Tribes） 6

3 班與班之間的相依性 7

4 橫向編組（Chapters）與同業公會（Guilds） 10

5 咦？這不就只是個矩陣組織（matrix org）嗎？ 10

6 來談談架構如何？ 11

7 這是怎麼辦到的？ 11

1

多個團隊一同從事產品開發，真是一項艱鉅的挑戰！而 Spotify便是我們迄今看到讓人印象深刻的極佳範例之一。即使公司成長到擁有

三十個團隊，橫跨三座城市，仍然保持著敏捷開發的態度。Spotify是一家大幅扭轉音樂產業的驚人公司。雖然這家公司僅成立六年，卻已經擁

有一千五百萬名活躍會員，以及四百萬名付費會員。而這家公司的產品則被比喻為「可以讓你瞬間尋找、播放世界上所有歌曲的神奇音樂播放器」。敏捷開發之父之一，Alistair Cockburn一度來訪 Spotify，便說：「太好了！我從 1992

年開始就一直希望有人可以實踐這套矩陣組織的設計，我的確非常喜聞樂見。」這究竟是怎麼辦到的呢？我們經常在研討會中發表、以及在許多座談會中討論我們在 Spotify工作的方式，以

及這家公司如何在擁有數百名開發者的狀況下從事敏捷開發。許多人對此津津樂道，於是我們打算寫一篇以此為題的短文。在此聲明： Spotify（以及許多採用敏捷開發的好公司）都在急遽成長中。這篇文章

只是當下這個片刻我們工作方式的縮影，我們的旅程還在進行中，尚未結束。在您閱讀這篇文章的此刻，相信很多事情也都已經改變了。

1 班（Squads）Spotify開發團隊的基本單位是「班」。

2

一個班的規模相當於一個 Scrum 團隊，設計上也很像一家迷你的新創公司。班兵位置全都在一起，並且擁有設計、開發、測試、釋出產品的所有技能與工具。一個班是一個自我管理的團隊，可以自行決定自己想要的工作方式—有些班採用 Scrum衝刺（Sprints），有些使用看板（Kanban）管理，有些則會混合上述幾種方法取徑。

每個班都有各自的長期任務，像是建構並改進 Android 版本的客戶端軟體、改善Spotify廣播功能的使用經驗、擴大後端平台營運、提供付費解決方案等等。下圖便標出了哪些班負責哪一塊的使用者經驗。

我們鼓勵每個班都採用精實創業（Lean Startup）的原則，像是 MVP（最小可行產品，miimum viable product）以及「驗證後的學習心得」（Validated Learning）。MVP代表我們應該盡早並且經常釋出產品，而「驗證後的學習心得」則代表使用量化標準以及 A/B測試確認什麼該做、什麼則反之。我們可以用一句口號總結「思考、建造、出

3

貨、調整」（Think it, build it, shit it, tweak it.）。因為每個班都長期有自己獨特的任務，以及產品的一部分，每個班都可以成為自己

領域中的專家—例如，創造出讚呆了的 Radio使用經驗。大部分的班都有自己超棒的工作環境，包括一塊辦公桌區域、沙發區、還有個人的

「雜物」室。幾乎每面牆上都是白板。我們從來沒有看過這麼好的空間！

沒錯，那隻鯊魚就是天天飛來飛去。一點都不奇怪。為了激勵學習與創新，我們鼓勵每個班都花上十分之一的時間搞黑客松。在黑客松

期間內，每個人都可以搞自己想搞的事情，試試看有什麼新點子，並且與同儕分享。有些班在每個月的第二週搞上一天的黑客松，有些則是把額度留下來，再一次搞上一個星期。黑客松不但有趣，同時也是讓團隊跟上新工具與新技術發展腳步的好方法，引導我們的產品不斷創新！

4

每個班並沒有正式派任的主管，但是卻有一位「產品所有者」（Product Owner，以下簡稱 PO）。PO負責排定每個班所該負責大小事項的優先順序，但是並不介入事項應該如何完成。每個班的 PO則同心協力，維護一份路線規劃文件，統整 Spotify所應該前進的方向，而每位 PO再各自負責規劃所屬團隊的待辦事項。每個班也可以接觸一位「敏捷教練」（Agile Coach），負責協助團隊改善工作方式。

敏捷教練會負責專案回顧、召開 Scrum衝刺籌備會議、一對一教練…等等。理想上，每個班都自主運作，而且可以與利益相關者直接接觸，與其他班沒有相依

關係。基本上就像是新創公司一樣。但，我們有三十個團隊，這的確是大挑戰！我們雖然運作了一段時日，但還是有很多可以改善之處。於是，我們每一季都對每個班做一份調查，幫助我們了解應該改善哪些地方，以及

每個班需要怎樣的組織支援。以下是我們對一個「部落」（Tribe）中五個班的調查結果。

圓圈代表的目前的狀態，箭頭則代表趨勢。從中我們可以讀出，有三個團隊回報了在釋出軟體方面出現問題，而且沒有改善—這一塊我們迫切需要注意！我們注意到，第四班雖然需要敏捷教練的支援，但已經獲得改善了。

• 產品所有者（Product owner）：這個班是否有一位負責排定工作事項優先順序，並且同時從商業與技術層面考量的產品所有者。

• 敏捷教練 （Agile coach）：這個班是否有一位負責協助班兵發覺並持續改進自己不足之處的敏捷教練。

• 對工作的影響（Influencing work）：是否每位班兵都可以透過積極參與規劃過程、志願承擔任務而影響自己的工作內容。每位班兵也是否都可以花上 10%的時間參與黑客松。

• 釋出產品的容易程度 （Easy to release）：這個班是否可以用最少的成本讓產品上線。

• 流程適合團隊的程度 （Process that fits the team）：這個班是否覺得目前的流程適合自己團隊，以及願意持續改進工作流程。

• 任務（Mission）：這個班是否有明確任務，同時每位班兵都知道並且關心這項任務，同時也有與這項任務有關的待辦事項文件。

• 組織支援（Organizational support）：這個班是否知道如何尋求解決問題所需的各項支援，包括技術問題，以及各種「軟性」事項。

5

2 部落（Tribes）「部落」則是好幾個在共同領域中的班的集合，像是音樂播放器、後端資訊架構等等。

「部落」可以想成是班這種等級的新創公司的「育成中心」，同時也有一定程度的自由與自主。每個部落會有一名酋長，負責分派部落中每個班最適合的棲息地。同一個部落中的班都位在同一間辦公室，通常就是比鄰而處，而用來進行協作的沙發區便位在各班的中間。一個部落的大小是根據「鄧巴數」（Dunbar Number）設計的，也就是，絕大多數人

沒有辦法在超過一百人的組織中維持緊密的社交關係（話說你可能不相信，其實還不用到達這個數字，就足以在組織中產生生存壓力了，雖然 Spotify沒有遇到這個問題）。一旦組織過分龐大，我們就會看到各種限制性的規定、科層結構、政治、管理過度分層以及其他各種浪費行為。所以每個部落都被設計成小於一百人。每個部落會三不五時舉辦集會，讓部落裡頭的其他人看到誰正在做什麼，誰已經做

出了什麼，以及可以從誰正在做的事情中學到什麼。集會內容包括開發中版本的展示、新工具與新技術，以及酷炫的黑客松專案…等等。

6

3 班與班之間的相依性

既然我們有許多班，自然就會產生班與班之間的相依性。—相依性不盡然是壞事，好幾個班之間，為了要打造些真正的好東西，便往往需要一同工作。然而，我們的目標仍然是盡可能讓每個班都維持自主，所以會特別企圖減少造成阻礙，或是讓某個班工作效率低落的相依性。為此，我們經常詢問每一班：你們現在要等其他哪些班完成工作？有哪些相依關係

已經造成工作卡住或是延遲？範例如下：

我們接下來會討論解決造成問題的相依性的解決方案，特別針對造成工作卡住以及跨部落的相依性。這些討論通常會導出重新安排工作事項優先程度、重新安排組織、架構改變或是技術解決方案。

7

這項調查同時也幫助我們找出班與班之間相依性的模式，例如，似乎愈來愈多班是因為公司營運部門造成進度落後。我們會用簡單的圖表，追蹤不同類型的相依性隨著時間如何增長或減少。

Scrum開發方式有一套技巧叫做「Scrum的 Scrum」，定時讓不同團隊之間分別派員開會討論團隊間的相依性。我們在 Spotify通常不太使用「Scrum的 Scrum」，主因是，絕大多數的班的獨立程度都相當足夠，而不需要這類協調會議。反之，Spotify是視需要才舉辦「Scrum的 Scrum」。例如，我們最近有一個大型專

案，需要協調好幾個班在幾個月內之間如何工作。

為了完成這項專案，團隊間每天，都舉辦一場用以判斷並且解決班與班相依性的會議，並且使用白板與便條紙追蹤還沒有解決的相依問題。

8

在許多公司中，造成相依性問題的根源，來自開發方與營運方。許多與我們一起合作的公司，往往在開發方與營運方的往返中，存在摩擦與拖延。

Spotify有一個獨立的營運團隊，他們的任務並非為各個班釋出產品，而是給予每個班各自自行釋出產品時所需的支援；支援內容包括公司架構、文書、例行事務等。我們該說，他們的工作是「為產品鋪路」。

這是一套非正式，但是運作有效的協作方式，所仰賴的是面對面溝通，而不是撰寫大量密密麻麻的文件。

9

4 橫向編組（Chapters）與同業公會（Guilds）凡事都有另一面，全然自主所隱藏的反面就是喪失規模經濟。第一班的測試人員正

在與之搏鬥的問題，可能另一班的測試人員上週就解決了。如果每一班、每個部落的測試人員可以齊聚一堂，他們便可以一同分享知識，並且打造可以造福每一班的工具。如果每一班都完全自主，而不與其他班溝通，我們還要一家公司做什麼呢？還不如

把 Spotify切割成三十家小公司。這就是為什麼我們需要橫向編組以及同業公會。這項設計是凝聚公司的黏膠，讓我

們可以在不喪失自主精神的前提下，給予我們規模經濟的好處。橫向編組就是技能與你相同，在類似領域、同一部落中工作的一群家人。

每個橫向編組也經常聚會，討論他們專業領域問題以及特殊的挑戰。我們有測試人員編組、網頁開發者編組，以及後端編組。橫向編組的組長屬於管理人員，負責像是人才培訓、設定薪資等傳統工作內容。不

過，橫向編組的組長也同樣隸屬於某一班，也要參與日常工作內容，而不致與現實脫節。但現況其實總是比像上面那張漂亮的圖片混亂一些。例如，橫向編組的組員並不會

均衡分配在每一個班當中，某幾班可能會有很多網頁開發者，而某幾班則完全沒有。但我們希望上面這張圖可以讓您認識我們的理念。至於同業公會，則是更有機、範圍更寬闊的「互利社群」，是想要分享知識、工具、

程式碼還有實作練習的一群人。橫向編組通常會侷限在同一個部落中，但是同業公會則往往橫貫整個組織。我們有網頁技術公會、測試人員公會、敏捷教練公會…等等。

10

一家公會通常會包含該領域中所有的橫向編組及其組員。像測試人員公會就包含了所有橫向編組中的測試人員，但是任何人有興趣，也都可以主動加入。每家公會都有一「公會協調人」，至於所做的工作嘛，就是協調囉。舉個例子，我們最近就有場「網頁技術公會非研討會」，就是一個集所有 Spotify網

頁開發者於斯德哥爾摩的開放空間聚會，一同討論網頁技術領域的挑戰與解決之道。

另外就是我們的敏捷教練公會。整個組織中到處都有敏捷教練，但是他們會定時聚會，不斷分享知識，共同完成更高階的組織改善工作；我們也將這些工作事項，用一塊「改進事項」白板追蹤。

11

5 咦？這不就只是個矩陣組織（matrix org）嗎？沒錯，說穿了，某方面就是如此。但與我們平常所知的矩陣組織不太一樣。在許多的矩陣組織中，擁有相同技能的人們，是一起被「關」進功能性的部門中，

並且被「指派」任務，還要向功能性的經理「回報」。Spotify很少做這些事情。我們的矩陣組織的一致目標就是產出。也就是說，人們是在有固定位置的班裡聚集起來，透過每個人身上的不同技能，協

同合作、自主管理，最終產出傑出的產品。這是矩陣的縱軸，也是最主要的一條，因為這是人們實體上聚集在一起的方式，也是花上最多時間的地方。至於橫軸，則是知識、工具與程式碼的分享。這就是橫向編組組長所要促進並支援

的事情。我們可以想成，縱軸是「做什麼」（What），橫軸則是「怎麼做」（How）。橫直錯綜，

讓每位班兵不但知道「接下來要做什麼」，也知道「怎樣做才做得好」。

12

這也符合Mary Poppendieck與TomPoppendieck所推薦的「教授與企業家」（Professorand Entrepreneur）模式。PO便是「企業家」或「產品冠軍」，專注在如何產出好的產品，至於橫向編組組長，便是「教授」或「才能領袖」，專注在技術上的卓越。在這兩種角色之間，存有健康的緊張關係。企業家往往想要加速開發，但教授則往

往想要收斂但是把事情做好。我們同時需要這兩種觀點，因此我們說這種緊張關係很「健康」。

6 來談談架構如何？

Spotify的科技是高度服務導向的。我們有超過一百個子系統，每個子系統都可以獨立維護並且佈署。當中包括後端服務，像是歌單管理、搜尋、付費管道等，還有客戶端軟體，像是 iPad音樂播放器，還有許多特殊元件，像是廣播功能，甚至音樂播放器當中的「最新情報」區塊等等。

13

技術上，我們允許任何人都可以改動任何系統。因為許多班其實是積極的功能開發團隊，他們通常就同時要改動好幾個系統，才有辦法在產品中添加新功能。這套模式的風險在於，如果沒有人盯著整體系統的整合性，系統架構就會變得一團

亂。為了降低風險，我們也設置了「系統所有者」（System Owner）這樣的角色。每套

系統都有一到兩位系統所有者（我們也鼓勵兩人配對工作）。對於營運上特別重要的系統，我們會配置一組「開發—營運」人員作為系統所有者，也就是，其中一人以開發的角度出發，另外一人則從營運的眼光看事情。系統所有者是關於該系統的技術或架構事務的負責人。同時也負責協調與引導要在

這套系統中開發的工程師，保證當中不會出亂子。系統所有者所該關心的事情包括品質、文件、技術負債、穩定性、可擴充性、以及釋出流程。系統所有者並非瓶頸或象牙塔的工匠。他並不需要獨自一人決定所有的決策，或撰

寫所有的程式碼，或負責所有釋出工作。他通常也只是某個班的成員，或某個橫向編組的組長，只是在日常工作之外，再加上某套系統的所有權。不過，每隔一段時日，他也需要有個「系統所有者日」，找段時間清理系統內部。一般我們希望系統的維護工作可以少於他十分之一的工作時間，但當然，系統不同，工作量也有所不同。我們也有一位首席架構師，負責協調橫跨許多系統的高度架構問題上的相關工作。

他要審閱新系統的開發，確認新系統沒有出現常見錯誤，以及將他們拉到我們的架構中。首席架構師的回應通常是給予建議，最終設計的決策權，還是在負責新功能的班中。

7 這是怎麼辦到的？

Spotify的成長非常快速，在三年中，我們的技術人員從三十位成長到兩百五十位，我們也有一份自己的成長的痛苦！而讓我們擴大規模的模型—班、部落、橫向編組與公會，也是一年前才終於成形，大家也都還在適應這一套方式。但目前，根據我們的調查與回顧，這套擴大規模的模型看來運作不錯！也給了我們一套繼續成長的藍圖。儘管公司成長快速，但員工的滿意度仍然不斷上升，到了 2012年四月，在滿分五分中，

14

我們得到 4.4分。不過，任何快速成長的組織，今天的解答也往往造成明日的問題。給點耐心吧，我

們的故事還沒結束。

• Henrik Kniberg (henrik.kniberg@spotify.com)• Anders Ivarsson (anders.ivarsson@spotify.com)

翻譯：楊維中原文 http://www.scribd.com/doc/113617905/Scaling-Agile-Spotify

15