原文：Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds 
作者：Henrik Kniberg, Anders Ivarsson 
翻譯：姜信寶（Bob Jiang），程嘉利 
姜信寶（Bob Jiang），中國北方第一位CST（Certified Scrum Trainer），國內知名電商資深敏捷教練、金牌講師，Certified LeSS Practitioner，《Scrum精髓》譯者。 
責編：陳秋歌，關注前端開發、敏捷開發等領域，尋求報道或者投稿請發郵件chenqg#csdn.net。另有「CSDN 敏捷開發高階群」，內有各大IT領域敏捷管理帶頭人、敏捷教練，關注敏捷開發的管理者可加微信Rachel_qg申請入群，請備註姓名+公司+職位。

多個團隊一同從事產品開發真是一項挑戰！

到目前為止，我們見過的最令人印象深刻的案例之一，就是 Spotify 公司：儘管 Spotify 擁有 30 多個團隊，位於 3 個不同的城市，但他們仍然保持著敏捷開發的思維。

Spotify 是一家非常吸引人的公司，它改變了整個音樂產業。雖然這家公司從成立到現在只有 6 年，卻已經擁有 1500 萬活躍使用者以及 400 萬付費使用者。該公司的產品可以被譽為是“一個神奇的音樂播放器，可以讓你瞬間找到、播放世界上任何一首歌曲”。

Alistair Cockburn（敏捷軟體開發創始人之一）在參觀 Spotify 時曾說道：“太棒了！我從1992 年開始就一直希望有人能夠實現這套矩陣式組織結構的設計（參考上圖），很高興今天我看到了”。

那麼這一切是怎麼做到的呢？

我們倆在會議演講中、在各種討論中多次提到我們在 Spotify 如何工作、這家公司如何在數百名開發人員中運用敏捷，很多人對這個話題很感興趣，所以我們決定以此為題寫一篇文章。

宣告：

• 文中提到的模型不是我們發明的。
• Spotify，和其他優秀的敏捷型公司一樣，處於高速地發展中。這篇文章只是我們當前工作方式的縮影。我們的敏捷旅程仍在進行中，並未結束。我們估計，當您讀到這篇文章的時候，很多事情已經發生變化了。

分隊（Squads）

分隊是 Spotify 的最小開發單位。

一個分隊類似於一個 Scrum 團隊，也很像一家迷你型創業公司。分隊中的成員坐在一起，他們具備設計、開發、測試和產品釋出所必需的全部技能和工具。一個分隊是一個自組織團隊、決定自己的工作方式——有的分隊使用 Scrum 中的迭代（Sprint），有的分隊使用看板（Kanban），還有的綜合使用上述方法。

每個分隊都會有一個長期的使命，比如：開發和優化 Android 客戶端、打造 Spotify 廣播功能的使用者體驗、擴充套件後臺系統、提供支付解決方案，等等。如下圖所示，不同分隊負責使用者體驗的不同部分。

Spotify 鼓勵每個分隊都運用精益創業原則，比如 MVP（Minimum Viable Product，最小可行產品）和驗證性學習（Validated Learning）等。MVP 意味著儘早地、頻繁地釋出； 驗證性學習意味著使用度量（Metrics）和 A/B 測試（A/B tesing）來確認什麼可行，什麼不行。用一條標語來總結的話，就是：“思考、構建、交付、調整（Think it, Build it, Ship it, Tweak it）”。

由於一個分隊長期持續地從事某一類任務以及開發產品的某一個部分，所以分隊成員逐漸都成為了該領域的專家——比如，如何打造非常棒的廣播體驗。

大部分的分隊都擁有非常棒的工作環境：辦公區、休息區、個人雜物室、幾乎所有的牆都是白板……，我們從未見過比這兒更好的工作空間！

沒錯，這是一隻飛來飛去的玩具鯊魚，這種東西在 Spotify 很常見。

為了激勵學習和創新，公司鼓勵每個分隊把大概 10%的工作時間用在“黑客日（Hack Days）”上。在黑客日期間，大夥可以做任何自己想做的事情：通常大家會嘗試一些新想法並和夥計們分享。有的團隊每兩週舉辦一天黑客日；有的團隊則攢夠了日子，搞一個“黑客周”。黑客日不僅有趣，還是一個讓大家緊跟新工具、新技術的好途徑，有時候非常重要的產品創新也誕生於黑客日！

一個分隊沒有正式任命的領導，但是會有一個產品負責人（Product Owner）。產品負責人負責把團隊的待辦任務進行優先順序排序，但從不干涉團隊如何完成這些任務。不同分隊的產品負責人緊密合作，共同維護一個巨集觀層面上的產品路線圖（Roadmap）文件，指引整個 Spotify 產品發展方向；與此同時，每個產品負責人也各自維護一個自己所在分隊的產品待辦項列表（Product Backlog）。

每個分隊也可以有一位敏捷教練，幫助團隊改進工作方式。敏捷教練負責主持回顧會議、組織 Sprint 計劃會議、做一對一輔導……，等等。

理想情況下，每個分隊是一個高度自治的“迷你型創業公司”，他們可以和利益相關者直接對話，且和其他分隊沒有阻塞型依賴關係。對於一個擁有 30 多個團隊的公司，想要達到這樣的狀態，絕對是個挑戰！我們雖然已經取得了很大的進展，但是仍有許多改進工作要開展。

為此，我們每個季度會對每個分隊進行一次調查，幫助我們聚焦於需要改善哪些地方以及瞭解到每個分隊需要哪些組織層面上的支援。下圖是我們某次對一個部落中的 5 個分隊的調查結果。

圓圈表示當前狀態，箭頭表示趨勢。比如，我們可以看到這樣一個情況：3 個分隊報告了釋出方面的問題，但是問題似乎並沒有得到改善——這方面需要我們的緊急關注！ 我們還可以看到第 4 分隊沒有很好地得到敏捷教練的支援，但是這個問題已經在改善中。

以下是各個調查項的評判參考標準：

• 產品負責人（Product Owner）——分隊內有專職的產品負責人對任務的優先順序進行排序；排序時，產品負責人能夠綜合考慮商業價值和技術因素。
• 敏捷教練（Agile Coach）——分隊有一位敏捷教練幫助團隊識別障礙、指導團隊持續進行過程改進。
• 支配自己的工作（Influencing Work）——分隊內的每個成員都可以支配自己的工作、可以積極參與工作計劃的制訂、可以選擇自己做什麼任務。每個成員都可以把自己 10%的工作時間投入到黑客日中。
• 易釋出（Easy to Release）——分隊可以(並且確實做到！)輕鬆釋出產品，而不需要很多的爭論和同步。
• 量身定製的流程（Process that fits the team）——分隊擁有自己的工作流程並且持續對其進行改進。
• 使命（Mission）——分隊有一個隊內所有人都知道並關心的使命；待辦項列表中的故事都是和這個使命相關的。
• 組織層面的支援（Organizational Support）——分隊知道去哪裡尋求解決問題所需的支援，無論是技術問題還是“軟性問題”（“soft” issues）。

部落（Tribes）

部落是多個工作在相關領域的分隊的集合——比如音樂播放器、後臺基礎架構等。

部落可以看作是迷你型創業分隊的“孵化器”，每個部落都非常地自主自治。每個部落有一名酋長，他負責為部落內的各分隊提供最好的棲息地（Habitat）。一個部落中的所有分隊在同一個辦公地點工作，通常各分隊的辦公區都是彼此相鄰的，辦公區附近的休息區促進了分隊間的交流與合作。

部落規模的確定是基於“鄧巴數（Dunbar Number）理論”的。“鄧巴數理論”認為在超過 100 人的組織中，大部分人很難維持穩固的社會關係（信不信由你，對處於強烈生存壓力下的組織來說，“鄧巴數”實際上要比 100 大。Spotify 並不屬於這樣的情況）。當一個組織變得過大後，我們就會開始看到限制性的規定、官僚主義、政治鬥爭、冗餘的管理層級，以及其他各種浪費。（譯註：鄧巴數，也稱 150 定律，是指能與某個人維持緊密人際關係的人數上限，通常人們認為是 150。）

所以 Spotify 的每個部落都小於 100 人。

部落內會定期舉辦非正式的聚會，大家會在聚會上給部落中的其他人（以及任何出席聚會的人）展示自己正在做什麼、已經交付了什麼、別人能從自己正在做的事情中吸取到什麼經驗或教訓。展示內容包括可工作的軟體、新工具與新技術、酷斃了的黑客日專案……。

分隊間依賴

多個分隊之間必然會有依賴關係。有依賴關係並不一定是壞事——分隊間有時確實需要一起工作才能完成真正超棒的產品特性。然而，我們的目標是讓分隊間越獨立自治越好，尤其是要把阻塞或拖慢了某個分隊工作的依賴項減到最少。

為此，我們經常對所有的分隊進行調查：你們的工作依賴於哪些分隊？這些依賴是否阻塞或拖慢了你們的工作？嚴重到了什麼程度？下面是一個例子：

有了調查結果，接下來我們就會討論如何消除有問題的依賴，特別是引起了工作阻塞的以及跨部落的依賴關係。為了消除這些有問題的依賴，我們經常會重排任務優先順序、重組團隊、調整架構或技術方案。

這種調查還會幫助我們觀察到分隊間互相依賴的模式，比如，越來越多的分隊看起來是被運營拖慢了。我們利用非常簡單的圖表來跟蹤各種型別的依賴是如何隨著時間增加或減少的。

Scurm 中有一個實踐叫“scrum of scrums”——這是一個同步會議，會議由每個 scrum 團隊出一名代表參加，大家在會上討論團隊間的相互依賴。 在 Spotify，通常我們並不怎麼進行 scrum of scrums，主要原因是大部分的分隊都相當的獨立，他們並不需要這樣的協調會議。

然而，如果有必要，我們也會“按需”進行 scrum of scrums。比如：最近我們有一個大型專案，需要多個分隊協同工作幾個月。為了更好的合作，分隊間每天會開一個同步會議，會議上大家一起去識別和解決分隊間的依賴關係，並使用白板和記事貼來跟蹤尚未解決的依賴。

許多公司中依賴問題的常見根源存在於開發（Dev）和運營（OPS）之間。大多數公司都存在從開發到運營的移交，期間伴隨著一些摩擦和延誤。在 Spotify 也有一支獨立的運營團隊，但是他們的工作不是為分隊進行釋出——而是為分隊自己釋出程式碼提供支援；支援可能是以下形式：基礎架構、指令碼或程式。在某種意義上，運營團隊是“為產品鋪路”。

這是非正式但有效的協作方式，基於面對面的溝通而不是詳細的流程文件。

分會（Chapter）和協會（Guild）

任何事物都有缺點，充分自主的可能缺點是損失了規模經濟的效益。分隊 A 的測試人員碰到的問題可能和分隊 B 的測試人員上週剛剛解決的一樣。如果所有的測試人員可以湊在一起，跨越分隊和部落的話，那麼他們就可以分享知識以及建立對所有分隊都有益處的工具。如果每個分隊充分自主，且互相之間沒有溝通的話，那麼為什麼還需要有公司呢？乾脆把 Spotify 拆成 30 個不同的小公司好啦。這就是我們為什麼還會有分會和協會。分會和協會使公司團結在一起，在不犧牲太多自主權的情況下，也為我們帶來一定的規模經濟。

分會是在同一個部落、相同能力領域內擁有相似技能的一些人。

每個分會定期湊在一起討論專業領域知識及他們遇到的挑戰——比如測試分會，網頁開發分會或者後臺分會。

分會領導是該分會成員的直線經理，和傳統的直線經理一樣，他們的職責是發展員工、設定薪水等等。但是，分會領導也是分隊的一份子，也要參與日常工作，這樣才不會和實際情況脫節。

但現實情況總是比上圖更加混亂。比如，分隊之間的分會成員不是均勻分佈的；有的分會有很多網頁開發人員，有的分會一個也沒有。上圖只是一般的思路。

協會則是一個具有更廣泛影響的“興趣社群”，它包含這樣一群人，他們想要分享知識、工具、程式碼和實踐。分會是在部落內的，而協會通常跨越整個組織。比如，網頁技術協會，測試協會，敏捷教練協會等等。

協會包含所有相關領域的分會成員，比如測試協會包含所有測試分會的成員，不過每個對協會感興趣的員工都可以加入其中。

每個協會都有一個“協會協調人”，他也就負責協調而已 :o)

說一個協會工作的例子，最近我們舉辦了一場“網頁協會非會議”，這是一次開放空間活動，Spotify 的所有網頁開發人員聚到斯德哥爾摩來討論他們領域內的挑戰和解決方案。（譯註：非會議是一種議程由參與者推動並建立的會議。會議的籌備一般不是由某個單獨機構或一小群機構組織的。）

另一個例子是敏捷教練協會。敏捷教練遍佈在整個組織，但是他們持續地分享知識，並且定期聚會討論組織層面改進的工作，這些都記錄在一個改進白板上。（如下圖）

等等，這不就是矩陣組織嗎？

沒錯，這是矩陣組織。但也不完全是。這個和我們常用的矩陣結構是不同型別的。

大多數矩陣組織中，相似技能的人“扎堆兒”到一起形成職能部門，接著“被分配”到專案中，並且“彙報”給職能經理。

Spotify 不是這樣的。這裡的矩陣偏重於交付。

在 Spotify 員工分成穩定的、坐在一起的分隊，擁有不同技能的人一起協作和自組織以交付一個優秀的產品。這是矩陣裡的垂直維度，也是員工分組工作的主要維度。

水平維度是有關分享知識、工具和程式碼的。分會領導的職責就是促進和支援這些工作。

在矩陣裡，可以認為垂直維度是“做什麼（What）”，水平維度是“怎麼做（How）”。矩陣結構確保每個分隊成員可以領會“下一步做什麼”以及“如何做好”。

這也符合 Mary Poppendieck 和 Tom Poppendieck 建議的“教授和企業家（Professor and Entrepreneur）”模型。產品負責人（PO）就是“企業家”，關注於交付優秀的產品，而分會領導是“教授”，關注於技術卓越。

這兩個角色之間存在良性的緊張關係，因為企業家傾向於快速交付和走捷徑，然而教授傾向於慢下來和把事情做對。兩個方面都是必須的，因此我們說這是良性的緊張關係。

來談談系統架構如何？

Spotify 的技術是高度面向服務的。我們有 100 多個獨立的系統，每個系統都可以單獨地維護和部署。這些系統包含後臺服務如播放列表管理、搜尋和支付，還包含客戶端如 iPad 播放器，也包含特定的元件如廣播、或音樂播放器中的“最新動態”。

從技術上講，每個人可以修改任意一個系統。既然分隊是高效的特性團隊，那麼通常團隊 
需要更新多個系統來完成新特性。

這個模型的風險是，如果沒人關注系統整體一致性的話，那麼系統架構就會變得一團糟。

為了降低這個風險，我們有一個“系統負責人（System Owner）”的角色。每個系統都有一個或一對系統負責人（我們鼓勵結對）。對有些關鍵運營系統，系統負責人是開發和運營結對的（Dev-Ops Pair）—— 一個人有開發人員的視角，另一個人有運營人員的視角。

系統負責人是系統技術或架構問題的“關鍵先生”。系統負責人負責協調和指導開發人員，以避免開發人員之間的衝突。系統負責人關注於以下事情：質量、文件、技術債、穩定性、可擴充套件性和釋出流程。

系統負責人不應該是瓶頸或者與世隔絕（原文是象牙塔裡的架構師）。系統負責人不必一個人完成所有的決策、程式碼或釋出。通常系統負責人是分隊成員或分會領導，除了系統負責人的工作之外，他還有其他的日常職責。然而，系統負責人會時不時地進行一個“系統負責人日”以清掃一下系統。通常我們儘量使清掃系統的工作佔用系統負責人少於十分之一的時間，但是系統之間有很大的不同。

我們還有一個首席架構師的角色，他負責協調跨越多個系統的、較高層面的架構問題。他還會評審新系統的開發工作，以避免一些常見錯誤，並確保新系統和現有的架構設計是一致的。架構師的反饋只是建議和輸入——系統設計的最終決策取決於分隊。

所有這些是怎麼辦到的？

Spotify 發展的非常迅速——過去 3 年技術人員從 30 人增長到 250 人——因此我們也有成長的煩惱！本文介紹的大規模敏捷模式（分隊、部落、分會和協會）也是去年（2011）逐步引入的，所以員工還在慢慢適應。但到目前為止，從調查和回顧來看，這個模式似乎相當棒！也給了我們一套繼續成長的藍圖。儘管人員增長迅速，但員工滿意度還是持續地增長；2012 年 4 月得分是 4.4（滿分 5 分）。

然而，和每一個不斷髮展的組織一樣，今天的解決方案會產生明天的問題。所以敬請關注，故事還沒有結束 :o)