溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

敏捷規(guī)模化框架的思考-再談Spotify

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

背景介紹

敏捷規(guī)模化框架的思考-再談Spotify



關(guān)于介紹 Spotify 的文章和相關(guān)材料，搜索引擎里搜索一下其實還是很多的， 那筆者為什么還要老生常談，再和大家聊一聊這個話題呢，其實更多的是基于實踐中的一些感慨，因為筆者正好在一家基于 Spotify 框架基礎(chǔ)上嘗試敏捷規(guī)?；墓竟ぷ鬟^，也看到了這個模式帶來的改變，但更感慨的則是一些形似神不似的“假敏捷”。

公司面臨的現(xiàn)狀是外包人員比例較高，這無疑增加了管理的復(fù)雜性，而同時有一定的存量系統(tǒng)需要進(jìn)行重構(gòu)和下線，加上為了滿足市場需求，又要不斷進(jìn)行產(chǎn)品更新迭代；管理難度高、重構(gòu)任務(wù)重、市場競爭大，成了擺在團(tuán)隊面前的三大難題，而最明顯的體現(xiàn)就是資源爭搶，業(yè)務(wù)團(tuán)隊希望盡快滿足需求、交付價值，技術(shù)團(tuán)隊要兼顧重構(gòu)和償還技術(shù)債務(wù)的任務(wù)。這樣的背景之下，公司決定借鑒 Spotify 的典型實踐，嘗試改變現(xiàn)狀。 


Spotify組織形式

敏捷規(guī)?；蚣艿乃伎?再談Spotify



關(guān)于 Spotify 這家公司的背景介紹，這里就不再贅述了，我們直接進(jìn)入主題， 聊一聊 Spotify 的典型實踐和組織架構(gòu)。

首先，筆者所在的公司希望借鑒 Spotify 的組織形式，第一步就是嘗試改變團(tuán)隊結(jié)構(gòu)，進(jìn)行“小隊化”，“部落化”， 這里有必要解釋下所謂的小隊和部落，Spotify 框架里最小的組織單元是 squad， 我們管它叫做小隊，小隊基本上可以理解為 Scrum 中的敏捷團(tuán)隊，包括了 PO、 Scrum Master 和 Team，我們期望這樣的形式可以做到資源對齊，每一個業(yè)務(wù)領(lǐng)域都有部落與之對應(yīng)，資源邊界更加清晰，溝通更加順暢，小隊本身的特點可以概括為三個方面：
  • 穩(wěn)定
  • 自組織
  • 特性團(tuán)隊
所謂穩(wěn)定是期望團(tuán)隊不要有大的變動，因為根據(jù)塔克曼模型，每一個團(tuán)隊都要經(jīng)歷組建、震蕩、規(guī)范、成熟和解散的幾個階段，如果一個團(tuán)隊一直無法保持穩(wěn)定，團(tuán)隊成員來來去去，那可能團(tuán)隊永遠(yuǎn)處于磨合期，這時再談文化建設(shè)、 敏捷轉(zhuǎn)型、高效合作、學(xué)習(xí)型組織這樣的話題，似乎都沒有意義，因為你沒有這一切的基礎(chǔ)-穩(wěn)定的團(tuán)隊；而自組織又是一個“好說不好做”的話題，至于特性團(tuán)隊，我們希望每一個小隊都是能夠獨立交付特性的，客戶的需求提出后，小隊可以給客戶一個滿意的答案，功能需求是完整的最重要的是有價值的，而相對應(yīng)的團(tuán) 隊形式就是交付某一個組件，對客戶來說這個組件沒有價值，因為它不能解決任何問題，而要想得到完整的產(chǎn)品特性，要依靠多個團(tuán)隊的協(xié)作，這種團(tuán)隊即組件團(tuán)隊。
敏捷規(guī)?；蚣艿乃伎?再談Spotify
而部落的概念是多個小隊的集合，之所以把他們定義為部落，是因為他們之前存在一定的關(guān)聯(lián)，比如：都交付某一個業(yè)務(wù)領(lǐng)域的特性；有部落就有部落長， 我們叫他酋長，他是這個大團(tuán)隊隊的負(fù)責(zé)人，需要為團(tuán)隊提供支持和指導(dǎo)。
敏捷規(guī)?；蚣艿乃伎?再談Spotify
那回到公司部落化的話題上來，首先公司組織了培訓(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)劃分到了不同的小隊和部落，但是橫向他們依然屬于一個分會，分會也有負(fù)責(zé)人， 比如測試分會的負(fù)責(zé)人就類似傳統(tǒng)架構(gòu)的測試經(jīng)理，區(qū)別是分會負(fù)責(zé)人不會有過重的管理職能，更多的是賦能、輸送血液，他要招聘新成員、要不斷利用各種手 段提高測試人員的能力水平。好的，又有問題了，測試人員該向誰匯報，績效誰來評？
而協(xié)會的概念更多的是基于興趣的小組，比如 Python 協(xié)會，管你是 java 開發(fā)還是性能測試工程師，只要你感興趣就可以參與，筆者認(rèn)為這是很好的實踐， 因為大家需要有機會去學(xué)習(xí)感興趣的東西，去接觸不同的朋友，長期來看這也是團(tuán)隊建設(shè)的好手段。但是這個層級在公司的實踐中，似乎被拋棄了。并沒有興趣小組，因為大家要把全部的精力放在完成功能交付上。
敏捷規(guī)?；蚣艿乃伎?再談Spotify
所以這也引出了 Spotify 很重要的一種文化，創(chuàng)新文化，Spotify 是非常鼓勵創(chuàng)新的，他們可以在每個迭代留時間做創(chuàng)新嘗試，甚至用一個完整的迭代來做創(chuàng)新活動，而我們并沒有考慮過創(chuàng)新，原因就是需求太多，工作太忙。
這恰好類似下方的這幅圖展示的含義：一位朋友在路燈下找鑰匙，別人會問你為什么只在這里找，你確定是掉落在這里嗎？他說不確定，但是這里有光，我能看得到，而我們難道不也是這樣嗎？我們關(guān)注的都是看得到的地方，那我們永遠(yuǎn)被限定在了這里，我們忙于日常交付似乎永遠(yuǎn)沒有時間創(chuàng)新，但當(dāng)你試著將目光放的更遠(yuǎn)時， 可能答案就在那里等著你。
敏捷規(guī)?；蚣艿乃伎?再談Spotify


我們的嘗試

敏捷規(guī)模化框架的思考-再談Spotify



Spotify 的核心價值觀是：創(chuàng)新、激情、真誠、協(xié)作、好玩，如果只是簡單的做部落化而不考慮背后的價值觀，那一點都不好玩。所以筆者寫這些內(nèi)容并不是為了吐槽公司做得有多不好，而是把這個反模式寫出來，如果您的公司恰好也希望借鑒Spotify，那請先想好什么是重點。而我們發(fā)現(xiàn)這些問題后，也在努力解決這些問題。
首先，我們開始試著讓敏捷開始開花結(jié)果，我們開始做培訓(xùn)，不只是針對領(lǐng)導(dǎo)層，也不只是針對核心骨干，而是全員，我們期望大家理解敏捷的核心思想， 我們通過看板做可視化，通過各種各樣的信息輻射源促進(jìn)透明，我們做興趣社區(qū)，做敏捷交流小組，我們嘗試多種方法開好回顧會，同時公司層面也開始推動 DevOps 落地。我們期望發(fā)布更容易，這樣就可以實現(xiàn)頻繁的發(fā)布，發(fā)布的規(guī)模也會變的很小，這樣我們就更容易發(fā)布，也就形成了良性的循環(huán)。
但是當(dāng)我們不斷的追求快速交付價值的過程中，卻逐漸的忽略了質(zhì)量，我們 開始發(fā)現(xiàn)質(zhì)量下降，我們開始不斷的救火，所以我們很快進(jìn)入了第二個階段提高質(zhì)量。
提高質(zhì)量似乎比快速迭代更難，我們從很多細(xì)小的點出發(fā)，我們梳理 DOR， 明確 DOD，我們開始推動結(jié)對代碼評審（因為結(jié)對編程領(lǐng)導(dǎo)不認(rèn)可，只能退一步海闊天空），我們開始考慮測試左移。
大家都明白，大部分的缺陷是在開發(fā)階段引入的，但是大部分缺陷是在測試階段的后期才被發(fā)現(xiàn)，甚至是在版本發(fā)布之后，而隨著時間的推移修復(fù)的成本成指數(shù)級增長，所以我們期望盡早發(fā)現(xiàn)缺陷， 我們開始提高單元測試覆蓋率，我們開始推動團(tuán)隊做重構(gòu)，以求得到更好的設(shè)計。我們也考慮測試右移，接入了更好的線上監(jiān)控工具，開始做灰度發(fā)布，質(zhì)量提升的工作還在不斷嘗試，整個組織也在不斷成長。

敏捷規(guī)模化框架的思考-再談Spotify


還有很多話沒有說

敏捷規(guī)?；蚣艿乃伎?再談Spotify



這篇文章只是個引子，我期望后續(xù)把更多更具體的實踐、做法和經(jīng)驗分享出 來，透過全文，大家可以發(fā)現(xiàn)我對 Spotify 的介紹并不多，而更多的是說明我們在參考 Spotify 轉(zhuǎn)型后，所面臨的問題和應(yīng)對措施，其實各種公司轉(zhuǎn)型都一樣， 任何一種框架模仿起來都很簡單，哪怕 SAFe 這個大家都覺得比較復(fù)雜的框架， 花些時間和精力，再請高人做下指點，也能模仿個七七八八，但是這似乎都不是重點，重點的是文化的轉(zhuǎn)變，兵馬未動糧草先行，轉(zhuǎn)型未動文化先行，我們雖然沒有做到文化先行，但總歸還是打破了組織重力，改變了組織文化，所以走到現(xiàn)在，我們對后續(xù)的路更充滿期待，我們不期望到達(dá)一個完美的終點，我們要做的是持續(xù)改進(jìn)。路還很長，似乎這個過程比結(jié)果更有趣。

敏捷規(guī)?；蚣艿乃伎?再談Spotify

- 作者：楊久成 - 
IDCF FDCC認(rèn)證學(xué)員。10余年工作經(jīng)驗，現(xiàn)就職于平安銀行PMO團(tuán)隊，高級項目經(jīng)理/PMP/PBA/ACP/ITIL4/DevOps Master，以程序員身份開啟自己的職業(yè)生涯，之后轉(zhuǎn)型做項目管理工作，早期主要做傳統(tǒng)項目管理，后期開始接觸敏捷，并開始對敏捷、DevOps以及各種新事物、新思維充滿熱情，現(xiàn)主要負(fù)責(zé)敏捷轉(zhuǎn)型、研發(fā)效能改進(jìn)、內(nèi)訓(xùn)師等工作。
向AI問一下細(xì)節(jié)
推薦閱讀：
  1. 初識敏捷
  2. 再談ThinkPHP

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手