《敏捷無敵之DevOps時代》讀後感
背景：
2020年基於我司業務形態，我開始實行敏捷專案管理。以敏捷為道，Scrum為法，迭代為術，禪道作器，大張旗鼓的搞了2年敏捷開發。隨著時間推移，問題出現在2022年，當時我們已經完全按照Scrum的模式在運作著10個專案，以及專案團隊。我們基於禪道提煉瞭如：任務準期率、任務準交率、計劃偏差率等指標。但是其中一項指標成了我們10個團隊的核心痛點，即：需求交付週期。我們在2022年年底覆盤的時候發現全年下來，需求交付的平均週期為40天，也就意味著一個需求從登記到禪道到關閉的平均週期是40天。這是我們無法接受的，也是業務部門（內部甲方）無法接受的。
問題出在我們的釋出與迭代是強關聯的，我們的迭代是2週一次，然後一個迭代就釋出一次，也就是說一個需求在理論上最快釋出週期是21天(3周)，這裡說的是理論值如下圖：
除非剛好，提出需求的那天正好是迭代開啟的頭一天，那樣可以做到14天，但是那種情況太極限了。另外也不是剛剛提出需求，下個迭代就可以安排開發。所以普遍性來說，算上排期，一個需求平均交付週期在這種模式下最快就只能做到21天。
但是，不可接受的事情是我們10支專案團隊，平均需求交付週期是40天，甚至比21天還要多2周。一個經典的案例是使用者需求增加一個Excel匯入匯出的功能，問我們要多久。我們開發人員評估的工時是2小時，但是客戶問我們什麼時候能用上，我們回答卻是2周以後。使用者不理解，我們也不理解。至此，如何將迭代與釋出脫鉤，就成了我研究的課題。
擺在我們面前的有兩條路線可以選擇一條是SAFe，一條是DevOps。 由於我們在2020~2022年期間先後取得了Scrum Master 和 PMI-ACP的認證。所以思維定式上會去靠攏SAFe， 完全實行SAFe對人員的要求很高，轉型也很痛苦。因此，我只採用了SAFe中的「釋出火車」這一重點實踐。 固定每週2、4 為釋出週期。 在試行2個月後，研發人員抱怨聲音越來越大，抱怨的主要原因是開發人員根本跟不上。其實這裡所謂的跟不上，經過我後面的調研不是指開發能力不行，而是對程式碼沒有基於需求做主分支管理。至此，我開始研究另外一條路線：DevOps 。
寫在前面：實施DevOps兩個月之後，我將需求平均交付週期從原來的40天，成功的縮短到了23天，並且後續任然有信心降低到15天內。
正文：
我入手的第一本書籍是《DevOps實踐指南》。說實話，這本書把我整的有點懵逼。書中講了很多運維人員和開發人員的實操案例。雖然我本身具備10年的.Net開發經驗，但是我現在本職工作是專案經理，這對我來說並沒有解決我的核心痛點。也可能是我們目的性太強，造成了我耐不住性子去讀這本書。不過，這本書在我小白階段的時候，至少跟我說清楚了什麼是：DevOps？
早期在百度搜尋DevOps，多數解釋就是：開發運維一體化，打通開發與運維之間的部門牆之類的。其實，這只是狹義的DevOps的理解。通過潛伏到各種微信群中，聽到各種大佬對DevOps的解釋，有的說是工具鏈，有的說是是流水線，有的說是實現自動化，有的說是實現CI/CD（持續整合/持續部署）。
這種渾渾噩噩的階段，直到讀完《DevOps實踐指南》才慢慢好轉，那麼究竟什麼是DevOps?
我認為現在最好的定義是：研發效能。 特別是這個「效能」，不是研發效率，效率指的是團隊的產能，速度。 而效能是這個「能」字是指的：賦能。 這樣才解釋清楚，在廣義的DevOps是怎麼適配到IT的研發場景。緊接著問題又來了，怎麼個賦能法才叫DevOps？還是沒說清楚什麼是DevOps？我們先把這個問題先放一下，先來回答另外一個問題：什麼是敏捷？
其實，在我入門敏捷的時候，也具有同樣的困惑，什麼是敏捷？是Scrum？是Xp？還是水晶？ 後來明白了，符合敏捷宣言的都是敏捷。
再回到前面那個問題，什麼是DevOps ？如何為研發效率賦能？是否也有類似敏捷宣言這樣更具體的解釋，答案是有的《DevOps實踐指南》給出了DevOps 三大原則： 流動、反饋、持續學習。 簡單來說符合 流動、反饋、持續學習的就是DevOps，並且DevOps自身也在不斷進化更新。
可是，還是有點抽象。這個持續學習還好理解，無論是理論指導實踐，還是實踐完善理論，持續學習始終是向上的攀升的正確途徑。
那麼剩下的兩個問題：
1，流動是什麼？
2，反饋是什麼？
帶著這兩個問題我又分別入手了《價值流動》、《敏捷無敵之DevOps時代》這兩本書。
關於《價值流動》我之前寫過另外一篇讀後感，這裡不做贅述，總之該書解釋清楚了流動的是啥，如下圖：
|
描述 |
交付物 |
|
|
特性 |
為推動業務結果而增加的新價值；對客戶可見 |
新的業務價值 |
|
缺陷 |
為修復影響客戶體驗的質量問題 |
質量 |
|
風險 |
致力於解決安全、隱私和合規風險 |
安全、治理、合規 |
|
債務 |
軟體架構和運維架構的改進 |
消除未來交付的障礙 |
到這裡我的問題更多了，前面我們要解決的問題是如何將迭代與釋出脫鉤？ 如何將需求交付週期從40天降下來？我們通常認為的需求就是上表中的特性，這裡一看不但需求對應的特性沒有 透明化，另外的缺陷、風險 和債務也是不透明的。但是總而言之，一句話：當前我是看不見需求的流動， 這也就解釋了為什麼我潛伏微信群的時候，有大神解釋DevOps 就是流水線，流動的東西就是上面的四大流動項。
上面解釋清楚了什麼是流動，以及流動的是什麼。那麼轉換成為行動任務就是，打造一套體系讓流水線，實現視覺化、透明化。這讓我們想起了考ACP的時候的 「價值流圖」 有異曲同工之妙。
就像木桶定理一樣，決定一個木桶能裝多少水，取決於那麼短板。 無論是特性、缺陷、風險、還是債務。對應的是四條處理流程（流水線），而將這個流程以進行視覺化，就能發現過程中的短板，並加以改善。根據我淺薄的理解，我悟到這裡，算是對「流動」有了一個較為具體的認知。
那麼反饋又是什麼？ 基於我對敏捷的認知，反饋就是以最小可行產品實現快速上線，獲得使用者反饋，並立即優化調整。通過閱讀《敏捷無敵之DevOps時代》之後，我有新的理解。通過各種工具建設對 觀測指標 進行提煉，對各項指標進行治理形成反饋，並利用這些反饋進行改進和優化，從而形成猶如PDCA的正向迴圈。
所以，這裡又說明白了為什麼我潛伏在微信群中，大佬說DevOps是 工具鏈。
說到工具鏈，不得不說我們潛伏微信群時候，大佬的另外一個解釋：自動化。前面講的基於四大流動項，可以打造四條流水線。那麼流水線除了做價值流圖分析過程短板以及等待浪費以外，還可以針對流程本身進行提速。 這裡我們可以簡單的對映一下現實生活中的工廠，手動流水線 和 自動化流水線。
至於怎麼自動化，說來也簡單。就是把重複勞動的事情交給機器去做，現實生活中的流水線不也是這樣的嗎？這裡對於解決了哪些重複勞動不做篇幅（PS.前期在B站一搜DevOps，老是出來一堆工具的實操教學，一直給我整的挺懵逼。）
這裡再回頭說一下，釋出與迭代怎麼脫鉤，通過我對這些DevOps工具的瞭解，接觸到了CI/CD。
CI (Continuous Integration)：持續整合。它涉及將開發人員的程式碼頻繁地整合到共用儲存庫中，並使用自動化構建和測試工具對程式碼進行驗證。
CD (Continuous Delivery/Continuous Deployment)：持續交付/持續部署。它涉及自動化地構建、測試和部署應用程式以實現快速且可靠的交付。
本身，CI/CD 概念並不複雜，為什麼我們前面用釋出火車團隊反應這麼大呢？ 前文中也有描述，沒有基於需求建立分支這是其一，建立分支缺乏管理，無法有效的實施持續整合、持續部署這是其二。
通過建設CI/CD，基於需求建立分支，配合工具使用。做好的功能通過測試，就釋出。不再等到迭代結束再發布，一下子就把需求交付與迭代脫鉤了，我們的交付週期也很快的從40天降低到了30天內。
寫到這裡，我再提煉幾個關鍵詞： 流動、反饋、持續學習、透明化、視覺化、自動化、工具鏈、流水線，CI/CD。
到這裡，還不是DevOps建設的全貌，接下來就要大刀闊斧的動起來了~！
感悟：
前面已經講過，由於在團隊內部實行「釋出火車」，造成的團隊各種抱怨。為了達成共識，這次我選擇了外來和尚唸經。由於市場上也有不少的成熟的DevOps解決方案，我先後組織了4場「解決方案供應商" 線上交流會，讓團隊對DevOps有了一致的認知，也成功勾起了大家對組織改善的意願。
這裡我規劃了三條建設路線同步進行：
其一，是工具鏈。包括：禪道18.0、GitLab、SonarQube、Jenkins、Selenium、Jmeter、K8s、Docker、Zabbix、WebFunny
其二，是流程與規範，包括：專案管理流程、需求管理流程、缺陷管理流程、敏捷運作機制、禪道使用規範、.Net編碼規範、JAVA編碼規範、GtiLab使用規範、持續整合規範、持續部署規範、測試管理規範、製品管理規範、伺服器監督管理規範、應用系統監督管理規範。
其三，是過程性指標與結果性指標。包括：需求總數、需求從登記到設計週期、需求從設計到評審週期、需求從開發到提測週期、需求從測試到釋出週期、程式碼提交次數、部署頻率、部署成功率 等指標。
緊接著趁熱打鐵，直接把DevOps轉型當做專案來做，發起了對DevOps的立項：
專案背景：
數位運營中心是敏捷型交付組織，具有邊設計邊生產邊實施、使用者需求多且變更頻繁、軟體使用過程中需要快速響應等組織特性。隨著部門業務量的倍速增長，管理複雜度不斷增加，同時需要更精細化的觀測指標進行管控，產品設計、專案管理、軟體開發、質量測試等過程缺乏規範性，尤其對細節管理需要實現過程與結果透明化，需要一套適合自己的面向企業服務的軟體生產管理體系與工具，同時拉通各個職能角色，使軟體生產業務資料透明可視；縮短需求生產週期，降低開發成本，進而實現開發運維一體化，提升管理效率。
專案目標：
目標1：需求平均交付週期從40天降低至25天。
目標2：需求按期交付率從90%提升至95%。
目標3：人均需求交付數從1.5提升至1.8。
目標4：軟體釋出一次成功率實現透明化，並提升至80%
專案收益：
投入180人天，獲得約14人編制的產能，計算如下：
數位運營中心以70人為基準，當前月度人均交付需求數為1.5。 通過建設DevOps研發效能體系，預計產能提升至月度人均交付需求1.8。
通過計算可知：
當前產能：70*1.5=105
目標產能：70*1.8=126
提升產能：126-105=21
釋放同等人力：21/1.5=14人，以人均薪資1萬元計算，約每月降本14萬元，全年降本168萬。
專案藍圖：
成果：
再回到一開始的問題，我們通過建設藍圖裡的一系列工具，成功實現了基於需求做程式碼版本的主分支管理，實現了一週2釋出的頻次。自此也完成了釋出與迭代脫鉤，雖然目前DevOps研發效能這個專案還沒有完全結束。但是我們已經成功實現了交付週期從原來40天縮短到了23天。大致成果如下圖：
