關於介紹 Spotify 的文章和相關材料，搜尋引擎裡搜尋一下其實還是很多的， 那筆者為什麼還要老生常談，再和大家聊一聊這個話題呢，其實更多的是基於實踐中的一些感慨，因為筆者正好在一家基於 Spotify 框架基礎上嘗試敏捷規模化的公司工作過，也看到了這個模式帶來的改變，但更感慨的則是一些形似神不似的“假敏捷”。
公司面臨的現狀是外包人員比例較高，這無疑增加了管理的複雜性，而同時有一定的存量系統需要進行重構和下線，加上為了滿足市場需求，又要不斷進行產品更新迭代；管理難度高、重構任務重、市場競爭大，成了擺在團隊面前的三大難題，而最明顯的體現就是資源爭搶，業務團隊希望儘快滿足需求、交付價值，技術團隊要兼顧重構和償還技術債務的任務。這樣的背景之下，公司決定借鑑 Spotify 的典型實踐，嘗試改變現狀。
關於 Spotify 這家公司的背景介紹，這裡就不再贅述了，我們直接進入主題， 聊一聊 Spotify 的典型實踐和組織架構。
首先，筆者所在的公司希望借鑑 Spotify 的組織形式，第一步就是嘗試改變團隊結構，進行“小隊化”，“部落化”， 這裡有必要解釋下所謂的小隊和部落，Spotify 框架裡最小的組織單元是 squad， 我們管它叫做小隊，小隊基本上可以理解為 Scrum 中的敏捷團隊，包括了 PO、 Scrum Master 和 Team，我們期望這樣的形式可以做到資源對齊，每一個業務領域都有部落與之對應，資源邊界更加清晰，溝通更加順暢，小隊本身的特點可以概括為三個方面：所謂穩定是期望團隊不要有大的變動，因為根據塔克曼模型，每一個團隊都要經歷組建、震盪、規範、成熟和解散的幾個階段，如果一個團隊一直無法保持穩定，團隊成員來來去去，那可能團隊永遠處於磨合期，這時再談文化建設、 敏捷轉型、高效合作、學習型組織這樣的話題，似乎都沒有意義，因為你沒有這一切的基礎-穩定的團隊；而自組織又是一個“好說不好做”的話題，至於特性團隊，我們希望每一個小隊都是能夠獨立交付特性的，客戶的需求提出後，小隊可以給客戶一個滿意的答案，功能需求是完整的最重要的是有價值的，而相對應的團 隊形式就是交付某一個元件，對客戶來說這個元件沒有價值，因為它不能解決任何問題，而要想得到完整的產品特性，要依靠多個團隊的協作，這種團隊即元件團隊。而部落的概念是多個小隊的集合，之所以把他們定義為部落，是因為他們之前存在一定的關聯，比如：都交付某一個業務領域的特性；有部落就有部落長， 我們叫他酋長，他是這個大團隊隊的負責人，需要為團隊提供支援和指導。那回到公司部落化的話題上來，首先公司組織了培訓工作，對核心成員做了培訓，說明了什麼是部落化，部落化能幫我們解決什麼問題，比如：部落化能讓產品和研發變為“一根繩上的螞蚱”，部落化能解決資源爭搶的現狀，培訓後大家對這個模式充滿期待，但是似乎漏掉了什麼？部落化固然好，但是它一定是建立在敏捷基礎之上的，而被培訓者有多少人真正理解了敏捷的精髓，敏捷宣言重點強調的又是什麼？是不寫文件嗎？還是不需要制定計劃？先不管，規模化的步伐已經邁出了。既然縱向做了部落化，就要談到 Spotify 的橫向拉通了，Spotify 中有分會和協會的概念，分會主要是基於角色或職能的，比如測試分會，雖然測試人員已經劃分到了不同的小隊和部落，但是橫向他們依然屬於一個分會，分會也有負責人， 比如測試分會的負責人就類似傳統架構的測試經理，區別是分會負責人不會有過重的管理職能，更多的是賦能、輸送血液，他要招聘新成員、要不斷利用各種手 段提高測試人員的能力水平。好的，又有問題了，測試人員該向誰彙報，績效誰來評？而協會的概念更多的是基於興趣的小組，比如 Python 協會，管你是 java 開發還是效能測試工程師，只要你感興趣就可以參與，筆者認為這是很好的實踐， 因為大家需要有機會去學習感興趣的東西，去接觸不同的朋友，長期來看這也是團隊建設的好手段。但是這個層級在公司的實踐中，似乎被拋棄了。並沒有興趣小組，因為大家要把全部的精力放在完成功能交付上。所以這也引出了 Spotify 很重要的一種文化，創新文化，Spotify 是非常鼓勵創新的，他們可以在每個迭代留時間做創新嘗試，甚至用一個完整的迭代來做創新活動，而我們並沒有考慮過創新，原因就是需求太多，工作太忙。這恰好類似下方的這幅圖展示的含義：一位朋友在路燈下找鑰匙，別人會問你為什麼只在這裡找，你確定是掉落在這裡嗎？他說不確定，但是這裡有光，我能看得到，而我們難道不也是這樣嗎？我們關注的都是看得到的地方，那我們永遠被限定在了這裡，我們忙於日常交付似乎永遠沒有時間創新，但當你試著將目光放的更遠時， 可能答案就在那裡等著你。
Spotify 的核心價值觀是：創新、激情、真誠、協作、好玩，如果只是簡單的做部落化而不考慮背後的價值觀，那一點都不好玩。所以筆者寫這些內容並不是為了吐槽公司做得有多不好，而是把這個反模式寫出來，如果您的公司恰好也希望借鑑Spotify，那請先想好什麼是重點。而我們發現這些問題後，也在努力解決這些問題。首先，我們開始試著讓敏捷開始開花結果，我們開始做培訓，不只是針對領導層，也不只是針對核心骨幹，而是全員，我們期望大家理解敏捷的核心思想， 我們透過看板做視覺化，透過各種各樣的資訊輻射源促進透明，我們做興趣社群，做敏捷交流小組，我們嘗試多種方法開好回顧會，同時公司層面也開始推動 DevOps 落地。我們期望釋出更容易，這樣就可以實現頻繁的釋出，釋出的規模也會變的很小，這樣我們就更容易釋出，也就形成了良性的迴圈。但是當我們不斷的追求快速交付價值的過程中，卻逐漸的忽略了質量，我們 開始發現質量下降，我們開始不斷的救火，所以我們很快進入了第二個階段提高質量。提高質量似乎比快速迭代更難，我們從很多細小的點出發，我們梳理 DOR， 明確 DOD，我們開始推動結對程式碼評審（因為結對程式設計領導不認可，只能退一步海闊天空），我們開始考慮測試左移。大家都明白，大部分的缺陷是在開發階段引入的，但是大部分缺陷是在測試階段的後期才被發現，甚至是在版本釋出之後，而隨著時間的推移修復的成本成指數級增長，所以我們期望儘早發現缺陷， 我們開始提高單元測試覆蓋率，我們開始推動團隊做重構，以求得到更好的設計。我們也考慮測試右移，接入了更好的線上監控工具，開始做灰度釋出，質量提升的工作還在不斷嘗試，整個組織也在不斷成長。
這篇文章只是個引子，我期望後續把更多更具體的實踐、做法和經驗分享出 來，透過全文，大家可以發現我對 Spotify 的介紹並不多，而更多的是說明我們在參考 Spotify 轉型後，所面臨的問題和應對措施，其實各種公司轉型都一樣， 任何一種框架模仿起來都很簡單，哪怕 SAFe 這個大家都覺得比較複雜的框架， 花些時間和精力，再請高人做下指點，也能模仿個七七八八，但是這似乎都不是重點，重點的是文化的轉變，兵馬未動糧草先行，轉型未動文化先行，我們雖然沒有做到文化先行，但總歸還是打破了組織重力，改變了組織文化，所以走到現在，我們對後續的路更充滿期待，我們不期望到達一個完美的終點，我們要做的是持續改進。路還很長，似乎這個過程比結果更有趣。
IDCF FDCC認證學員。10餘年工作經驗，現就職於平安銀行PMO團隊，高階專案經理/PMP/PBA/ACP/ITIL4/DevOps Master，以程式設計師身份開啟自己的職業生涯，之後轉型做專案管理工作，早期主要做傳統專案管理，後期開始接觸敏捷，並開始對敏捷、DevOps以及各種新事物、新思維充滿熱情，現主要負責敏捷轉型、研發效能改進、內訓師等工作。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31558019/viewspace-2700368/，如需轉載，請註明出處，否則將追究法律責任。
