背景介紹
關(guān)于介紹 Spotify 的文章和相關(guān)材料，搜索引擎里搜索一下其實還是很多的， 那筆者為什么還要老生常談，再和大家聊一聊這個話題呢，其實更多的是基于實踐中的一些感慨，因為筆者正好在一家基于 Spotify 框架基礎(chǔ)上嘗試敏捷規(guī)?；墓竟ぷ鬟^，也看到了這個模式帶來的改變，但更感慨的則是一些形似神不似的“假敏捷”。
公司面臨的現(xiàn)狀是外包人員比例較高，這無疑增加了管理的復(fù)雜性，而同時有一定的存量系統(tǒng)需要進行重構(gòu)和下線，加上為了滿足市場需求，又要不斷進行產(chǎn)品更新迭代；管理難度高、重構(gòu)任務(wù)重、市場競爭大，成了擺在團隊面前的三大難題，而最明顯的體現(xiàn)就是資源爭搶，業(yè)務(wù)團隊希望盡快滿足需求、交付價值，技術(shù)團隊要兼顧重構(gòu)和償還技術(shù)債務(wù)的任務(wù)。這樣的背景之下，公司決定借鑒 Spotify 的典型實踐，嘗試改變現(xiàn)狀。Spotify組織形式
關(guān)于 Spotify 這家公司的背景介紹，這里就不再贅述了，我們直接進入主題， 聊一聊 Spotify 的典型實踐和組織架構(gòu)。
首先，筆者所在的公司希望借鑒 Spotify 的組織形式，第一步就是嘗試改變團隊結(jié)構(gòu)，進行“小隊化”，“部落化”， 這里有必要解釋下所謂的小隊和部落，Spotify 框架里最小的組織單元是 squad， 我們管它叫做小隊，小隊基本上可以理解為 Scrum 中的敏捷團隊，包括了 PO、 Scrum Master 和 Team，我們期望這樣的形式可以做到資源對齊，每一個業(yè)務(wù)領(lǐng)域都有部落與之對應(yīng)，資源邊界更加清晰，溝通更加順暢，小隊本身的特點可以概括為三個方面：
而部落的概念是多個小隊的集合，之所以把他們定義為部落，是因為他們之前存在一定的關(guān)聯(lián)，比如：都交付某一個業(yè)務(wù)領(lǐng)域的特性；有部落就有部落長， 我們叫他酋長，他是這個大團隊隊的負責人，需要為團隊提供支持和指導(dǎo)。
那回到公司部落化的話題上來，首先公司組織了培訓(xùn)工作，對核心成員做了培訓(xùn)，說明了什么是部落化，部落化能幫我們解決什么問題，比如：部落化能讓產(chǎn)品和研發(fā)變?yōu)椤耙桓K上的螞蚱”，部落化能解決資源爭搶的現(xiàn)狀，培訓(xùn)后大家對這個模式充滿期待，但是似乎漏掉了什么？部落化固然好，但是它一定是建立在敏捷基礎(chǔ)之上的，而被培訓(xùn)者有多少人真正理解了敏捷的精髓，敏捷宣言重點強調(diào)的又是什么？是不寫文檔嗎？還是不需要制定計劃？先不管，規(guī)?；牟椒ヒ呀?jīng)邁出了。既然縱向做了部落化，就要談到 Spotify 的橫向拉通了，Spotify 中有分會和協(xié)會的概念，分會主要是基于角色或職能的，比如測試分會，雖然測試人員已經(jīng)劃分到了不同的小隊和部落，但是橫向他們依然屬于一個分會，分會也有負責人， 比如測試分會的負責人就類似傳統(tǒng)架構(gòu)的測試經(jīng)理，區(qū)別是分會負責人不會有過重的管理職能，更多的是賦能、輸送血液，他要招聘新成員、要不斷利用各種手 段提高測試人員的能力水平。好的，又有問題了，測試人員該向誰匯報，績效誰來評？而協(xié)會的概念更多的是基于興趣的小組，比如 Python 協(xié)會，管你是 java 開發(fā)還是性能測試工程師，只要你感興趣就可以參與，筆者認為這是很好的實踐， 因為大家需要有機會去學(xué)習感興趣的東西，去接觸不同的朋友，長期來看這也是團隊建設(shè)的好手段。但是這個層級在公司的實踐中，似乎被拋棄了。并沒有興趣小組，因為大家要把全部的精力放在完成功能交付上。
所以這也引出了 Spotify 很重要的一種文化，創(chuàng)新文化，Spotify 是非常鼓勵創(chuàng)新的，他們可以在每個迭代留時間做創(chuàng)新嘗試，甚至用一個完整的迭代來做創(chuàng)新活動，而我們并沒有考慮過創(chuàng)新，原因就是需求太多，工作太忙。這恰好類似下方的這幅圖展示的含義：一位朋友在路燈下找鑰匙，別人會問你為什么只在這里找，你確定是掉落在這里嗎？他說不確定，但是這里有光，我能看得到，而我們難道不也是這樣嗎？我們關(guān)注的都是看得到的地方，那我們永遠被限定在了這里，我們忙于日常交付似乎永遠沒有時間創(chuàng)新，但當你試著將目光放的更遠時， 可能答案就在那里等著你。
我們的嘗試
Spotify 的核心價值觀是：創(chuàng)新、激情、真誠、協(xié)作、好玩，如果只是簡單的做部落化而不考慮背后的價值觀，那一點都不好玩。所以筆者寫這些內(nèi)容并不是為了吐槽公司做得有多不好，而是把這個反模式寫出來，如果您的公司恰好也希望借鑒Spotify，那請先想好什么是重點。而我們發(fā)現(xiàn)這些問題后，也在努力解決這些問題。首先，我們開始試著讓敏捷開始開花結(jié)果，我們開始做培訓(xùn)，不只是針對領(lǐng)導(dǎo)層，也不只是針對核心骨干，而是全員，我們期望大家理解敏捷的核心思想， 我們通過看板做可視化，通過各種各樣的信息輻射源促進透明，我們做興趣社區(qū)，做敏捷交流小組，我們嘗試多種方法開好回顧會，同時公司層面也開始推動 DevOps 落地。我們期望發(fā)布更容易，這樣就可以實現(xiàn)頻繁的發(fā)布，發(fā)布的規(guī)模也會變的很小，這樣我們就更容易發(fā)布，也就形成了良性的循環(huán)。但是當我們不斷的追求快速交付價值的過程中，卻逐漸的忽略了質(zhì)量，我們 開始發(fā)現(xiàn)質(zhì)量下降，我們開始不斷的救火，所以我們很快進入了第二個階段提高質(zhì)量。提高質(zhì)量似乎比快速迭代更難，我們從很多細小的點出發(fā)，我們梳理 DOR， 明確 DOD，我們開始推動結(jié)對代碼評審（因為結(jié)對編程領(lǐng)導(dǎo)不認可，只能退一步海闊天空），我們開始考慮測試左移。大家都明白，大部分的缺陷是在開發(fā)階段引入的，但是大部分缺陷是在測試階段的后期才被發(fā)現(xiàn)，甚至是在版本發(fā)布之后，而隨著時間的推移修復(fù)的成本成指數(shù)級增長，所以我們期望盡早發(fā)現(xiàn)缺陷， 我們開始提高單元測試覆蓋率，我們開始推動團隊做重構(gòu)，以求得到更好的設(shè)計。我們也考慮測試右移，接入了更好的線上監(jiān)控工具，開始做灰度發(fā)布，質(zhì)量提升的工作還在不斷嘗試，整個組織也在不斷成長。
還有很多話沒有說
這篇文章只是個引子，我期望后續(xù)把更多更具體的實踐、做法和經(jīng)驗分享出 來，透過全文，大家可以發(fā)現(xiàn)我對 Spotify 的介紹并不多，而更多的是說明我們在參考 Spotify 轉(zhuǎn)型后，所面臨的問題和應(yīng)對措施，其實各種公司轉(zhuǎn)型都一樣， 任何一種框架模仿起來都很簡單，哪怕 SAFe 這個大家都覺得比較復(fù)雜的框架， 花些時間和精力，再請高人做下指點，也能模仿個七七八八，但是這似乎都不是重點，重點的是文化的轉(zhuǎn)變，兵馬未動糧草先行，轉(zhuǎn)型未動文化先行，我們雖然沒有做到文化先行，但總歸還是打破了組織重力，改變了組織文化，所以走到現(xiàn)在，我們對后續(xù)的路更充滿期待，我們不期望到達一個完美的終點，我們要做的是持續(xù)改進。路還很長，似乎這個過程比結(jié)果更有趣。
重慶分公司
重慶分公司
