敏捷規模化框架的思考-再談Spotify

發布時間：2020-08-18 19:50:00 來源：ITPUB博客閱讀：182 作者：DevOps訂閱號欄目：開發技術

背景介紹

關于介紹 Spotify 的文章和相關材料，搜索引擎里搜索一下其實還是很多的，那筆者為什么還要老生常談，再和大家聊一聊這個話題呢，其實更多的是基于實踐中的一些感慨，因為筆者正好在一家基于 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 的介紹并不多，而更多的是說明我們在參考 Spotify 轉型后，所面臨的問題和應對措施，其實各種公司轉型都一樣，任何一種框架模仿起來都很簡單，哪怕 SAFe 這個大家都覺得比較復雜的框架，花些時間和精力，再請高人做下指點，也能模仿個七七八八，但是這似乎都不是重點，重點的是文化的轉變，兵馬未動糧草先行，轉型未動文化先行，我們雖然沒有做到文化先行，但總歸還是打破了組織重力，改變了組織文化，所以走到現在，我們對后續的路更充滿期待，我們不期望到達一個完美的終點，我們要做的是持續改進。路還很長，似乎這個過程比結果更有趣。

敏捷規模化框架的思考-再談Spotify

- 作者：楊久成 -

IDCF FDCC認證學員。10余年工作經驗，現就職于平安銀行PMO團隊，高級項目經理/PMP/PBA/ACP/ITIL4/DevOps Master，以程序員身份開啟自己的職業生涯，之后轉型做項目管理工作，早期主要做傳統項目管理，后期開始接觸敏捷，并開始對敏捷、DevOps以及各種新事物、新思維充滿熱情，現主要負責敏捷轉型、研發效能改進、內訓師等工作。

向AI問一下細節

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

敏捷規模化框架的思考-再談Spotify

猜你喜歡

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

敏捷規模化框架的思考-再談Spotify

猜你喜歡

最新資訊

相關推薦

相關標簽