經典圖書《持續交付》已出版8年，一直受到軟體行業從業者的關注。書中的軟體開發原則和實踐也隨著商業環境VUCA特性的明顯增強而逐漸受到軟體技術人員的認可。這本書得以迅速、優質地在中國出版與譯者喬樑密不可分，圈內人都親切的稱喬樑為“喬幫主”。

喬樑是《持續交付》譯者，持續交付領域專家，持續交付和DevOps理念在國內的首批實踐者和佈道者，被業界稱為“國內持續交付第一人”。國內最早致力於通過敏捷開發與精益理論改善軟體價值交付效率的實踐者之一，精研各種軟體工程方法論。

8年後喬樑帶著他的全新著作《持續交付2.0：業務引領的DevOps精要》面向大眾。這本書將《持續交付》一書的思想融會貫通，經過8年的管理實踐，精心總結與提煉，提出“持續交付2.0雙環模型”;作者獨創性地將持續交付理論與當前的技術熱點DevOps理念完美結合。

同時《持續交付》一書作者Jez Humble為本書作序。騰訊副總裁曾宇、百度地圖事業部總經理李瑩、ThoughtWorks中國區總經理 張鬆滴滴高階技術總監路寧、百度工程效率部負責人李濤、阿里巴巴研發協同平臺負責人葉渡等眾多企業高管和技術專家聯袂推薦。

《持續交付2.0：業務引領的DevOps精要》

作者：喬樑

掃描二維碼，一鍵購買

2002年，我偶然得到一本書，名為《解析極限程式設計》。書中介紹的軟體開發方法與現實中使用的工作方法截然不同。書中的很多實踐看上去都不現實，如測試驅動開發、持續整合、結對程式設計、使用者故事等，這讓我感到很新奇，怎麼會有團隊這麼做呢？但看上去這些方法的確很誘人，於是我帶著“懷疑”的態度，在實際工作中引入了其中一些方法，但執行上還是打了一些折扣。例如，我沒有做測試驅動開發，而只是增加一些單元測試；沒有做結對程式設計，而是要求程式碼評審（code review）；沒有做持續整合，而是每日構建。一段時間後，雖然能感受到一些收益，但並沒有那麼顯著。

直到2005年，我的一個朋友向我展示了他們如何使用這種開發方式交付真實的軟體專案，和真實的編寫程式碼的過程。每一次修改程式碼，都編寫並執行一系列的自動化測試用例；每次提交都會進行持續整合。這是一種從未有過的編碼體驗，開發工程師很少需要啟動程式，通過單步除錯來找出程式碼中的問題。這使我真正相信，的確存在按照這種敏捷方式工作的團隊，而且離我並不遙遠。

2007年，我加入ThoughtWorks，希望能體驗敏捷軟體開發方式。作為一名需求分析師和交付經理，我加入了持續交付平臺GoCD的產品研發，我的搭檔就是Jez Humber（該產品的產品經理），他也是《持續交付：釋出可靠軟體的系統方法》的作者之一，書中很多實踐都來自我們團隊自己的軟體產品研發過程。從想法的誕生到產品上架，我經歷了一個完整的產品研發過程，也真正認識了敏捷開發方法，掌握了持續交付實踐。

2009年以後，我作為外部顧問或內部教練，開始為國內外很多企業提供相關的組織敏捷與精益轉型諮詢服務，客戶既有PC網際網路時代的巨頭，也有傳統IT企業；既有國內知名大企業，也有高速成長的移動網際網路創業公司。在與客戶合作的過程中，我對“持續交付”有了更深刻的理解，也對如何幫助組織實現“持續交付價值”有了全新的認識。

2007年，我認為包括極限程式設計在內的眾多敏捷開發實踐是快速高質量軟體交付的法寶；2010年之後，我發現實踐本身雖然非常重要，但更重要的是支撐實踐的組織管理方法、工作思路與理念。於是，我的口頭禪成了“別提敏捷，只解決問題！”。2012年後，更多的軟體開發方法與敏捷流派在國內開始盛行，但其背後的核心理念與主要工作原則並沒有根本性的變化。無論什麼樣的方法，都應該以“解決問題”為出發點，而“解決問題”的一個重要前提是“能夠正確定義問題，並達成共識”。

我當然不是思想無用論的支持者。相反，我認為思想對每個人對事物的認知和理解至關重要。但諮詢經歷告訴我，對事物的正確理解，並不能確保正確的思想和理念在現實中落地，也不能確保對企業有大的和直接的幫助。對方法應用者而言，其目標是通過對思想理念的認知，能夠儘早解決自己（或者客戶）所面臨的棘手問題。

正如企業經營管理一樣，軟體工程發展的歷程也是各種方法論不斷出現與發展的過程。從20世紀60年代“軟體工程”這一術語的誕生，到20世紀70年代提出瀑布軟體開發模型，以及1985年提出的迭代增量開發和1986年Barry Boehm在“A Spiral Model of Software Development and Enhancement”一文中提出的噴泉模型，20世紀90年代的軟體能力成熟度模型整合（Capability Maturity Model Integration，CMMI）的產生和多種輕量級軟體開發方法，21世紀初敏捷宣言的正式發表，再到精益軟體開發方法、看板方法，以及持續交付和DevOps運動。所有這一切變化，既反映出該領域的快速變化，也反映出沒有哪一種理論或方法能夠完全解決這個領域面臨的所有問題。

本書希望能夠讓讀者在瞭解“持續交付”全貌的基礎上，當遇到與IT組織效能相關的問題時，能夠以適當的思考方式和背景知識來應對，讓你在今後的工作中少走一些彎路，至少遇到相似問題時，可以有所參考。

從“軟體工程”這一名詞誕生以來，“質量”和“效率”就是它的目標。IT組織大都在這條路上探尋，從最初的瀑布模型，到CMMI，很多組織曾經尊其為軟體開發過程的“聖經”。而當“敏捷運動”興起時，他們想要“做”敏捷；當聽說“持續交付”，他們想要“做”持續交付。現在，DevOps也來了！在各種各樣的交流大會裡，不斷傳來DevOps勝利的凱歌，各種媒體也在報道它的好處。很多公司又想要“DevOps”了……

我們的確聽到過一些美妙的“故事”，但它們可能都不屬於我們自己。在自己身邊，就連“如何讓大家對這些理念或實踐達成共識”都成了一大困難，這令你感到無比困擾。就像走在一團迷霧之中，耳邊一直聽到美妙的音樂響起，也隱約看到遠處的點點亮光，然而腳下的“路”卻忽明忽暗。

多年工作經歷讓我對這一領域有了新的認識，並進行總結與反思。“持續交付”是一個非常有吸引力的名字，總會讓人浮想聯翩，業務人員似乎看到了一絲希望“所有的需求，上午提出來，下午就能拿到手”。然而，太多的企業低估了自己所面臨的困難。這些困難一部分是顯性的，如沒有自動化測試，也做不到自動化部署，主幹開發更是不可想象；還有一部分困難是隱性的，例如，職能部門之間的“牆”存在已久。業務人員嫌開發團隊的軟體交付速度慢，開發團隊嫌業務人員提出的需求不靠譜。這很可能歸因於每個人的價值思考方式。

本書的目標是希望企業中所有角色轉換價值思考的角度，改進軟體服務端到端的商業價值交付方式，提升相關人員之間的協作效率，最終達到以安全可靠的方式快速驗證想法，縮短實現真正商業價值的時間。也就是說，《持續交付2.0：業務引領的DevOps精要》不僅關注“從需求列表到可執行的軟體”這一過程，還提出“價值探索—快速驗證”雙閉環，如圖0-1所示，這也是本書的書名“持續交付2.0”的由來。

事實證明，沒有放之四海皆準的企業管理解決方案，能夠完美解決每個企業遇到的問題。但是，管理者只有從整體視角出發，抵住區域性優化的誘惑，才能在資源有限的情況下，引領企業創造更大的價值。本書提供了一個整體框架，給出了這個框架中各節點所涉及的原則與相關的實踐方法，同時介紹了它們的優勢與約束。

圖1　持續交付雙閉環模型

如果你將“持續交付2.0雙環模型”應用到整個企業範圍，就是一種企業級的組織管理變革指引；如果你將它引入某一個團隊，對這個團隊來說，就是團隊工作模式的改進套路。既然“持續交付2.0”是一個管理框架，企業勢必要根據自己的實際情況來進行定製。因此，書中列舉了很多實際案例，告訴你，其他企業或團隊如何應用這些實踐方法，達到它們的目標。這些案例也說明，解決方案與實施路徑很難在企業之間進行復制，企業必須應用書中的原則，結合自身的實際情況（產品形態及所處的商業競爭階段、團隊的規模與人員技能水平、軟體系統架構，以及組織管理機制與文化等），逐步探索出自己的道路。

先談談本書的結構和內容。全書共包括3部分內容。第一部分介紹了“持續交付2.0”的雙環模型；第二部分主要討論使用“持續交付2.0”框架中可能遇到的問題，以及改進過程中需要遵循的原則。第三部分主要是案例分享，目的是讓讀者體會在持續改善過程中，不同企業和團隊的實施重點與解決方案的不同。書中具體內容如下所示。

第一部分主要講述“持續交付2.0”雙環模型（即持續交付“8”字環）和“持續交付2.0”的4個工作原則，還會介紹兩個閉環“價值探索”與“快速驗證”的執行步驟與相關原則。

第1章討論持續交付的發展必然性，並介紹“持續交付2.0雙環模型”及其4個基本原則。

第2章討論“價值探索環”（簡稱“探索環”）的4個核心環節，以及每個環節的指導原則與實踐方法。只有業務方能夠以“精益”方式思考，持續交付才能更顯威力，否則很可能退縮成為持續交付1.0的單環模式，即只有“快速驗證環”。

第3章簡單闡述“快速驗證環”（簡稱“驗證環”）中各環節的主要活動，並給出各環節的工作方法。

第二部分主要闡述“持續交付2.0”的實施七巧板中，三大主要板塊的工作原則與實踐方法。這三大板塊包括組織機制、軟體架構與基礎設施。其中組織機制是一個複雜課題，本書僅討論持續交付所需的文化，以及建立文化的四步法。組織架構、人才結構、激勵機制等內容將在本書的續篇中專題討論。基礎設施部分是產品研發過程中最基礎的工作。這部分首先討論持續交付部署流水線及其工具設計原則，然後分別介紹部署流水線的建立與優化必須關注的五大領域，也就是說，業務需求協作流程、分支與配置管理、構建與環境管理、自動化測試管理，以及部署釋出與監控管理。

第4章討論持續交付能力的提升需要企業具有信任、安全和持續改善的組織文化，並介紹豐田公司和谷歌公司用過的改善組織文化四步法。

第5章討論軟體架構對實現持續交付快速驗證能力的重要性、有利於持續交付的軟體架構特徵，以及軟體架構改造的3種方式，即“拆遷”“絞殺”和“修繕”。

第6章討論如何利用約束理論和精益思想，發現流程中的瓶頸，使各角色之間的業務需求協作更加順暢，提升需求流動速度。

第7章討論快速驗證環所依賴的部署流水線的設計原則與工具鏈建設草案。

第8章討論程式碼倉庫的分支方式對持續交付的重大影響，以及不同分支方式下部署流水線的建設方案。最後介紹程式碼分支的數量對釋出策略的影響。

第9章回顧持續整合的歷史，並講解如何判斷團隊是否在實踐“持續整合”，還給出企業實施持續整合的五大步驟。

第10章討論軟體釋出以前制訂自動化測試策略需要考慮的因素，還介紹持續整合對自動化測試用例的編寫與執行要求。最後，為了提高自動化測試的投資回報率，團隊如何為遺留系統編寫和增加自動化測試用例。

第11章討論軟體配置管理,它是持續交付快速驗證環的基礎。對程式碼、配置、環境、資料做好配置管理，最終實現一鍵部署和一鍵測試，讓各角色在協作過程中能夠全部實現自動化服務，並且互不影響，解放人的大腦和雙手，做更有價值的事情，而讓機器做它擅長的事——不斷地重複

第12章討論降低生產部署與釋出風險的技術與方法。

第13章討論軟體在執行時，資料收集與分析的重要性，以及衡量資料監測環節的衡量指標，包括正確性、完整性和及時性，此外，還介紹測試扁平化趨勢，以及生產環境上的質量巡檢與演習。

第三部分主要是實戰案例的分析。它們分別代表不同型別的公司、不同大小的團隊以及不同的軟體產品特點。我將帶你深入案例現場，瞭解當時狀況，分析問題，並提出解決思路。

第14章介紹一個百人工程師的網際網路產品團隊歷經一年時間，如何打造快速運轉的“持續交付2.0雙環模型”，並且做到可持續運轉。

第15章介紹在無法“測試右移”的情況下，一個大專案中的小團隊如何改變團隊協作模式，從“死亡行軍”轉變為“無缺陷交付”。

第16章介紹一個微服務化開發團隊如何在專案執行的過程中，通過逐步對基礎設施板塊中各模組進行改造，提升交付質量與頻率，並推動運維人員也做出改變，真正成為一個“DevOps團隊”。

持續交付1.0關注於“從提交程式碼到產品釋出”的過程，如圖2所示，並且提供了一系列工作原則和優秀的實踐方法，可以提升軟體開發活動的效率。

圖2　持續交付1.0的關注點

但是，我在實際諮詢過程中發現，一些軟體功能在開發完成之後，對使用者或者業務來說，並沒有產生什麼影響，有些功能根本沒有使用者來使用。可是，這些功能的確花費了團隊的很多精力才設計實現。這是一種巨大的浪費。這種“無用”的功能生產得越多，浪費就越大。我們是否可以找到一些方法，讓我們付出的努力對業務改善更加有效，或者只用很少的成本就可以驗證對業務無效呢？

精益思想

2011年出版的《精益創業》一書給了我一些啟示。其核心思想是，開發新產品時，先做出一個簡單的原型——最小化可行產品（Minimum Viable Product，MVP），這個原型的目標並不是馬上生產出一個完美的產品，而是為了驗證自己心中的商業假設。得到使用者的真實反饋後，從每次試驗的結果中學習，再快速迭代，持續修正，在資源耗盡前從迷霧中找到通往成功的道路，最終適應市場的需求。

Eric Rise在書中強調，精益創業就是一個“開發—測量—認知”的驗證學習過程，如圖3所示。也就是說，把創意快速轉化為產品，衡量顧客的反饋，然後再決定是改弦更張，還是堅守不移。

圖3　“開發—測量—認知”環

該書主要關注於創業初始階段，將精益思想貫穿於產品“從0到1”的過程。事實上，它也可以用於產品“從1到n”的過程中。

1996年，Womack、Jones和Roos在《精益思想》一書中指出，精益思想是指導企業根據使用者需求，定義企業生產價值，按照價值流來組織全部生產活動，使價值在生產活動之間流動起來，由需求拉動產品的生產，從而識別整個生產過程中不經意間產生的浪費，並消除之。

在精益管理理論中，“浪費”是指從客戶角度出發，對優質產品與良好服務不增加價值的生產活動或管理流程。並指出，業務生產中所有活動都可以歸結為以下兩種活動，也就是增加價值的活動和不增加價值的活動，而不增加價值的活動就是浪費。在被歸類為“浪費”的活動中，又可以分為必要的非增值活動和純粹的浪費。必要的非增值活動是指從客戶的角度看雖沒有價值，卻可以避免（潛在的）更大的浪費或降低系統性風險的活動，如圖4所示。

圖4　軟體產品開發中的活動浪費

例如，生產流水線上的裝配工作是增值活動，質量檢查是必要的非增值活動，而因材料供應不足產生的生產等待以及因質量缺陷導致的返工都被認為是不必要的浪費。在軟體產品服務的全生命週期中，也同樣包含多種“浪費”，例如，無效果的功能特性、各生產環節中的等待（如圖5所示）、沒人看的文件、軟體缺陷、機械性的重複工作等。

圖5　使用者視角的增值活動與浪費

儘管“消除所有浪費”幾乎是不可能的，但是，我們仍舊要全面貫徹“識別和消除一切浪費”的理念，持續不斷地優化流程與工作方式，達到高質量、低成本、無風險地快速交付客戶價值的目的。

雙環模型

自2009年Flickr（一個聚合全球知名熱門圖片分享網站）聲稱其網站每天部署10次之時起，“主幹開發+持續整合+持續釋出”已成為矽谷知名網際網路公司應對VUCA環境的一種主流軟體研發管理模式。這種變化的原動力並不是來自技術團隊本身，而是來自業務與產品方的訴求。為了在VUCA環境中更快地瞭解海量使用者，快速驗證大量業務假設和解決方案，他們改變了業務探索的模式，並催生了軟體研發管理模式的改變，兩種模式相互促進，從而形成了網際網路軟體產品研發管理的雙環模式，即“持續交付2.0”，如圖6所示。

圖6　持續交付2.0的雙環模型

“持續交付2.0”是一種產品研發管理思維框架。它將精益創業與持續交付1.0相結合，強調業務與IT間的快速閉環，以“精益思想”為指導，全面貫徹“識別和消除一切浪費”的理念，通過一系列工作原則與實踐，幫助企業以一種可持續方式，高質量、低成本、無風險地快速交付客戶價值。

對企業來說，開發軟體產品的目標是創造客戶價值。因此，我們不應該僅僅關注快速開發軟體功能，同時還應該關注我們所交付的軟體的業務正確性，以及如何以有限的資源快速驗證和解決業務問題。也就是說，不斷探索發現真正要解決的業務問題，提出科學的目標，設計最小可行解決方案。通過快速實現解決方案並從真實反饋中收集資料，以驗證該問題是否得以解決。這是一個從業務問題出發，到業務問題解決的完整業務閉環，簡稱為持續交付“8”字環。

它由兩個相連的環組成：第一個環為“探索環”，其主要目標是識別和定義業務問題，並制訂出最小可行解決方案進入第二個環；第二個環為“驗證環”，其主要目標是以最快速度交付最小可行方案，可靠地收集真實反饋，並分析和驗證業務問題的解決效果，以便決定下一步行動，如圖7所示。

探索環包含4個可持續迴圈步驟，分別是提問、錨定、共創和精煉。

（1）提問，即定義問題。通過有針對性的提問，找出客戶的具體需求，並找出具體需求後的原因，即具體需求後要解決的根本問題。在提問中形成團隊期望達成的業務目標或者想要解決的業務問題。如果問題無法清晰定義，那麼找到的答案自然就會有偏差。因此，在尋找答案之前，應該先清晰地定義問題。

（2）錨定，即定義結果目標指示器。針對問題進行資訊收集，經過分析，去除干擾資訊，識別問題假設，得到適當的衡量指標項，並用其描述現在的狀況，同時討論並定義我們接下來的行動所期望的結果。

（3）共創，即共同探索和創造解決或驗證該問題的多種具有可行性的解決方案。

（4）精煉，即對所有的可行試驗方案進行選擇，找到最小可行性解決方案，它既可能是單個方案，也可能是多個方案的組合。

驗證環也包含4個可持續迴圈的步驟，分別是構建、執行、監測和決策。

（1）構建：是指根據非數字化描述，將最小可行性解決方案准確地轉換成符合質量要求的軟體包。

（2）執行：是指將達到質量要求的軟體包部署到生產環境或交到使用者手中，並使之為使用者提供服務。

（3）監測：是指收集生產系統中產生的資料，對系統進行監控，確保其正常執行。同時將業務資料以適當的形式及時呈現出來。

（4）決策：是指將收集到的資料資訊與探索環得出的對應目標進行對比分析，做出決策，確定下一步的方向。

探索環就像是一部車子的前輪，把握前進方向。驗證環則像車子的後輪，使車子平穩且驅動快速前進。它們之間相互促進，探索環產生的可行性方案規模越小，越能夠提高驗證環的運轉速度；如果價值驗證環能夠提高運轉速度，則有利於探索環儘早得到真實反饋，有利於快速決策，及時對前進方向進行驗證或調整。

本文摘自《持續交付2.0：業務引領的DevOps精要》

《持續交付2.0：業務引領的DevOps精要》

作者：喬樑

掃描二維碼，一鍵購買

持續交付2.0不只是關於軟體的交付模型，而是從業務問題出發，關注業務假設驗證速度的雙環業務模型。只有從業務目標出發的持續交付實踐才有強大的創造力和生命力！ 

書中指出，持續交付2.0雙環模型高速運轉的三個支柱分別是組織機制、軟體架構和軟體交付基礎設施，同時給出了提升價值探索環以及快速驗證環運轉速度的多種可行方法。 

本書還為我們呈現了在企業內部改善持續交付2.0能力所需遵循的基本原則，包括組織文化建設、軟體系統架構、業務協作、配置管理、構建整合、自動化測試、釋出與監控七大板塊，並指出各領域實踐關鍵點，以及多種可實操性方法。同時，通過3個完整的實踐案例過程分析，說明每個企業或團隊都必須從自己的業務目標出發，根據自己的實際情況，制定自己的改善路線。