Spotify敏捷模式詳解三部曲第一篇：研發團隊

 

本文轉自：Scrum中文網

引言

2018年4月，來自北歐瑞典的音樂流媒體公司、百億美圓獨角獸Spotify創造了歷史，它成爲了當代上市公司當中，第一家經過「直接上市」的方式在美國紐交所成功掛牌的公司。這家公司改變的可能不只是人們聽音樂的習慣，並且還有企業進入資本市場的方式。截至2018年初，Spotify擁有1.59億的全球活躍用戶數量、7000萬的付費用戶數和46%的付費用戶增加率。Spotify是當之無愧的音樂流媒體領域的霸主，排名第二的蘋果音樂，不管是付費用戶仍是活躍用戶，都只有Spotify的一半。

是什麼成就了Spotify？他們是如何打造出這麼一款深受用戶喜好的產品的？幸運的是有Henrik Kniberg的存在。Henrik Kniberg是全球知名的敏捷和精益教練，也是一位多產的做家，他參與了Spotify公司的這一過程，並寫下了多篇文章，向外界揭開了Spotify公司的神祕面紗。

筆者經過本身的收集和整理，梳理出了Spotify敏捷模式的整個過程，並經過一系列的文章呈現給你們。在本期的文章中，筆者將首先介紹Spotify的研發團隊。

組織架構

Spotify採用的是一種很是獨特的組織架構，以下圖所示：

整個研發組織有多個稱爲「Tribe部落」的單元組成，每一個部落中包括多個「Squad小隊」，從橫向的維度把擁有相似技能的人放在一塊兒造成「Chapter分會」和「Guild協會」。

Squad（小隊）

組織定位：

• 相似於一個高度自治的、迷你的「創業公司」。

• 肩負一個長期的使命，長期從事某一類任務或者開發產品的某一個部分。例如：

1）功能特性小隊：專一於某塊功能特性，例如搜索功能。

2）客戶端APP小隊：專一於使特定的客戶端平臺更容易發佈，例如：iOS、Android.（注意：他們不進行業務特性開發）。

3）基礎設施小隊，專一於讓其餘小隊更有效率，提供工具和例行事物，例如：持續交付、A/B測試，監控和運維。

團隊成員：

• 不存在官方任命的團隊領導。

• 有一位產品負責人（Product Owner）。

1） 各小隊的產品負責人緊密合做，共同維護一個宏觀的產品路線圖（Roadmap），指引整個 Spotify 公司的產品發展方向。

2） 每一個產品負責人也分別維護一個本身所在小隊的產品待辦列表（Product Backlog）。

• 可能會有一位敏捷教練（Agile Coach），幫助團隊改進工做方式。

• 具有開發產品須要的全部知識和技能，例如設計、開發、測試、發佈等。

• 一般少於8我的。

工做方式：

• 坐在一塊兒工做。

• 自組織管理本身的工做。

• 定義和改進本身的工做流程。

辦公環境

Tribe（部落）

組織定位：

• 在相關領域工做的多個小隊的集合，例如音樂播放器、後臺基礎架構等等。

• 能夠當作是迷你創業小隊的「孵化器」。

團隊成員：

• 每一個部落有一名酋長，他負責爲部落內的各小隊提供最好的棲息地（Habitat）。

• 部落規模大小基於「鄧巴數（Dunbar Number）理論」而定（小於100人）。

工做方式：

• 一個部落中的全部小隊在同一個辦公地點工做，一般各小隊的辦公區是彼此相鄰的，辦公區附近的休息區能促進了小隊間的交流與合做。

• 會按期在部落內開展非正式的聚會，在聚會上相互展現本身正在作什麼、已交付了什麼、其餘人能從本身正在進行的事項中獲得什麼經驗教訓。展現內容包括能工做的軟件、新工具與新技術、很是酷的黑客日/黑客周項目……

「鄧巴數理論」：即150定律，由英國牛津大學的人類學家Robin Dunbar在1990s年代提出。

該定律認爲：人類智力容許人類擁有穩定社交網絡的人數是148人（四捨五入爲150）。Spotify認爲在超過 100 人的組織中，大部分人很難維持穩固的社會關係。當一個組織變得過大後，咱們就會開始看到限制性的規定、官僚主義、政治鬥爭、冗餘的管理層級，以及其餘各類浪費。

組織對小隊的支持

每一個季度，組織會對每一個小隊作一次調查，以肯定小隊須要在哪些方面改善以及須要在組織層面提供哪些支持。

 

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

1. 產品負責人（Product Owner）——小隊內是否有專職的產品負責人對任務的優先級進行排序？排序時，產品負責人是否可以綜合考慮商業價值和技術因素？
2. 敏捷教練（Agile Coach）——小隊是否有敏捷教練幫助團隊識別障礙、指導團隊進行持續地過程改進。
3. 支配本身的工做（Influencing Work）——小隊內的每一個成員均可以支配本身的工做？能夠積極參與制定工做計劃？能夠選擇本身作什麼任務？每一個成員是否均可以把本身 10%的工做時間投入到黑客時間？
4. 容易發佈（Easy to Release）——小隊是否能夠（而且確實作到）輕鬆發佈產品，而不須要不少的爭論和同步？
5. 合適的流程（Process that fits the team）——小隊擁有本身的工做流程而且持續對其進行改進？
6. 使命（Mission）——小隊是否有一個小隊全部人都知曉並關注的使命？產品待辦項中的故事是否都與此使命息息相關？
7. 組織級支持（Organizational Support）——小隊是否知曉該從何處尋求解決問題所需的支持，不管是技術問題，仍是「軟」問題（「soft」 issues）？

管理小隊間依賴

核心思想：

• 依賴就意味着堵塞和等待。

• 要儘可能減小小隊間的依賴項。

實踐方法：

1. 常常對小隊進行依賴調查：大家的工做依賴於哪些小隊？這些依賴是否阻塞或拖慢了大家的工做？嚴重到了什麼程度？
2. 基於調查結果，討論如何消除有問題的依賴，特別是引發了工做阻塞的以及跨部落的依賴關係。爲了消除這些有問題的依賴，常常會調整任務優先級、團隊組成、架構或技術方案。
3. 必要時，召開SoS（Scrum of Scrums）協調會議。
4. 開發小隊自行發佈成果，運營小隊只負責「鋪路」。

 

Chapter（分會）

組織定位：

• 負責傳播知識和開發工具。

• 相似於傳統的職能部門。

團隊成員：

• 同一個部落、相同技能領域、擁有類似技能的一些人。（技能領域，例如：例如敏捷教練，或Web開發。）

• 分會有一個領導，就是分會成員的直線經理，是一個服務式的領導，負責教導和指導分會成員的工做，執行員工發展、定薪等。

• 分會的領導，同時也是某個小隊的成員，參與小隊平常工做。

工做方式：

• 每一個分會按期聚會，討論專業知識及遇到的挑戰。

Guild（協會）

組織定位：

• 分享知識、工具、代碼和實踐。

• 輕量級的「興趣愛好社區」。

團隊成員：

• 囊括整個公司的成員，彙集和分享特定領域的知識，例如領導力，Web開發或持續交付。

• 每一個協會都有一個「協會協調人」，負責組織和協調協會的活動。

• 任何人均可以隨時加入或離開協會。

工做方式：

• 每一個協會按期組織一些研討會。

如何解決系統的總體一致性？

1. 現狀&問題：

1) Spotify 的技術是高度面向服務的。

2) 一共有 100 多個獨立的系統，每一個系統均可以單獨地維護和部署。

3) 一般小隊須要更新多個系統來完成新特性的開發。

4) 若是沒人關注系統總體一致性的話，那麼系統架構就會變得一團糟。

2. 解決方案：

• 系統負責人（System Owner）：每一個系統都有一個或一對系統負責人（鼓勵結對）。對某些關鍵的運營系統，系統負責人由開發和運營結對組成（Dev-Ops Pair）—— 一我的擁有開發視角，另外一我的擁有運營視角。
  • 系統負責人負責協調和指導開發人員，以免開發人員之間的衝突。
  • 系統負責人關注於：質量、文檔、技術債、穩定性、可擴展性和發佈流程。
  • 系統負責人並不是專職，一般也是小隊成員或分會領導，還有其餘的平常工做。
  • 系統負責人會不時地執行一次「系統負責人日」，以整理一下系統。（系統負責人要在「系統負責人日」上投入的時間，不一樣的系統差別較大，可是一般很多於10%。）
• 一個首席架構師，負責協調跨越多個系統的、較高層面的架構問題。
  • 評審新系統的開發工做，以免一些常見錯誤，並確保新系統和現有的架構設計是一致的。架構師的反饋只是建議和輸入——系統設計的最終決策取決於小隊。

與傳統矩陣式組織的區別

傳統矩陣式組織形式

1) 項目立項時，「職員」由「職能經理」從職能部門「分配」到「項目」。

2) 在項目中，「職員」由項目的「項目經理」分配任務。

3) 「職員」要例行向「職能經理」進行工做的「彙報」。

4) 項目結項後，「職員」從「項目」釋放，回到「職能部門」，等待分配到下一個「項目」。

• Spotify的組織形式：

1) 「職員」在「小隊」中「持續」工做，與小隊中其餘人員共同「打造」一款優秀的「產品」。

2) 「分會」和「協會」爲「職員」提供「服務」，分享知識、工做、代碼和實踐，解決如何小隊成員「如何作得更好」的問題。

• Spotify的組織設計思想：

1) 採用社區（Community）來替代傳統的層級式組織（Hierarchical Structure）。

2) 「教授和企業家」模型：

3) 產品負責人（PO）就是「企業家」，關注於交付優秀的產品，

4) 分會領導是「教授」，關注於技術卓越。

本文是Spotify敏捷模式詳解三部曲第一篇：研發團隊，本系列文章的下一篇將繼續介紹Spotify的研發管理過程，敬請期待。