Spotify 的敏捷擴張之道:部落、班、橫向編組與

同業公會
Henrik Kniberg & Anders Ivarsson
June 18, 2013

Contents
1

班(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 與 Tom Poppendieck 所推薦的「教授與企業家」(Professor
and 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