《持續交付》譯者《持續交付 2.0》作者

                                                                                        騰訊高階管理顧問

講師介紹

大家都叫我“喬幫主”？這個綽號是我 2010年以領域專家身份加入百度PMO時得到的。

當時百度並沒有工程生產力部門，而是負責軟體過程度量的 SQA。在加入之後，該部門的職責已經改為：“通過引入先進軟體研發模式，並在百度各產品線進行推廣，從而提升生產效率“。

現在，DevOps 運動興起，持續交付研發理念已被廣泛接受。

而在當時，我們戲稱自己是“丐幫”，因為持續整合和持續交付這種軟體交付方式在當時還很難被人接受，所以只能向不同團隊“兜售（祈求）”我們的持續交付研發方式，也不一定被人“理睬”。

而我一身正氣，是不是和《天龍八部》中的喬幫主有點兒像，哈哈哈。

在過去的10年裡，我為不同型別的企業提供組織轉型和研發效率方面的諮詢工作，今天這個題目是我對過去這麼多年的總結。

更多的實踐原則與方法在我的新書《持續交付 2.0》。本會場可以看到一些預覽版，當然只有為數不多的幾本，因為還沒有正式印刷出版。這一版算是“限量版”啦，哈哈哈。

那麼在過去的這些年裡面，我遇到了什麼？我在這個行業裡做過很多角色，從普通工程師到架構師，從專案經理到部門負責人。

從小作坊式的軟體生產，到大規模的瀑布軟體開發方法。感覺做軟體總是這麼累，反反覆覆總是不流暢。

直到2002年發現了《解析極限程式設計》，覺得其中的開發方法有些不可思議，但覺得應該能有一些效果。

後來有機會在自己的團隊中使用其中一些實踐，當然根據自己的判斷進行了所謂的定製（現在看來是不恰當的做法），得到一些收益，但並沒有想象的那麼大。

直到 2007 年加入思特沃克公司（ThoughtWorks）以後，尤其是與Jez Humble（他是 DevOps 領域的世界級領軍人物）一起負責一款軟體產品開發以後，才真正體會到這種軟體開發模式的魅力。持續交付這種開發方式的確可以讓軟體交付變得非常快。

然而，當時IT行業的絕大多陣列織並不相信這一點，所以我就開始了我的佈道之旅。

我在過去十年裡也遇到過困難，走過一些彎路，今天就為大家分享其中的幾個“陷阱”。提醒大家一點，這條路不太好走。

1. DevOps 運動誕生的必然與發展

---

在不同的時期，軟體交付面臨不同的困難，而行業中各種新名詞的出現，總是想解決軟體生命週期中的某個具體問題。

上個世紀60年代未出現第一次“軟體危機”，所以我們從建築行業借用了“工程”的概念，併產生了“軟體工程”學科，並隨之出現了瀑布模型，它是期望通過嚴格的重文件重流程的瀑布模式來解決業務需求多與軟體人員能力及人員供給不足所導致的軟體專案交付成功率低下問題。

然而，軟體工程並未像建築工程那樣發揮相同的作用，軟體專案成功率仍舊不高。

在90年代出現了很多輕量級的軟體開發方法，更強調迭代與增量，與瀑布模式形成鮮明對比。

到了2001年，這些方法都被統稱為“敏捷開發方法”。當然，強調迭代的同時，瀑布模型仍舊存在，很多團隊在每個迭代的粒度內，還仍舊使用瀑布模型。軟體團隊經過幾個迭代的開發以後，再把軟體釋出到生產環境上。

2010年《持續交付》一書釋出，並描述了這樣一種交付方式，即“持續交付”。讓軟體隨時處於可釋出狀態，可以按需釋出到生產環境。

這個時候，瀑布模型仍舊沒有消失，只是它在一個更小的粒度上發揮作用，即單一需求的粒度。

下面這個環就是一個軟體的交付環。

我們可以看到，在過去這麼長時間，持續整合（CI）和敏捷軟體開發方法（Agile）中的很多實踐聚焦於解決從需求到構建出軟體這一環節中各角色的合作。

而網際網路業務的崛起，使得如何讓構建完成的軟體快速上線成為決勝的關鍵因素。而這也是“DevOps“這個名詞出現的巨大動力之一。

因為，此時傳統運維的工作方式成了“瓶頸”，必須改變原來研發部門與運維部門之間的協作方式，才能讓這一過程更加平滑流暢。

DevOps 強調的是軟體開發團隊和運維團隊的敏捷協作，讓軟體更加平滑、快速進入到生產環境上，從而發揮軟體價值。早在 2011 QCON 大會上，我有一個主題演講，題目就是《 DevOps，讓持續交付成為可能》。

其中，最後一個關鍵點就是：讓運維人員參與到軟體開發過程中，組建全功能團隊，建立信任關係，改變原有的工作方式，從而提升軟體的交付速度。

持續整合和敏捷打破了產品開發和測試之間的一個部門牆，讓他們更加快速的能夠迭代起來。

那麼，迭代完之後呢，我們需要快速部署，儘早發揮軟體價值。此時就有了DevOps。

DevOps 讓我們的軟體交付團隊和軟體運維部署監控團隊能夠合作起來。而持續交付1.0 需要將敏捷和 DevOps 結合在一起，才能從前到後貫穿。

持續交付並不僅僅指運維團隊每天多次從產品庫中取出二進位制軟體包進行自動化部署。這一點應該是大家想清楚的。

DevOps 到底是什麼呢？由四位 DevOps 運動領軍人物共同出品的《 DevOps 實踐指南 》一書中，也沒有對 DevOps 完整定義。事實上，它沒有行業上統一的定義。

從我自己的理解的話，敏捷本身是一場運動，它旨在尋找一系列的方法和實踐，以提升軟體交付的質量和效率。

我把“質量”放在前面，是因為只有在確定質量水平的前提下，提升軟體交付效率才更有意義。

那麼，DevOps 是什麼呢？DevOps 也可以說是一場運動，它的目標與敏捷一致，如上圖所示。

DevOps 已經成長近10年，行業內有很多很多的做法。上圖是我在網上找到的一張截圖，在這張圖裡面可以看到很多工具，並且都被稱為 DevOps 工具。然而，這些工具已經存在很久了，比如Git（一種分散式程式碼版本管理工具）。難道企業使用了這些工具，就說明企業 DevOps 了？

很多企業說：“我要做 DevOps 了，我要僱傭 DevOps 工程師！”現在好像DevOps 工程師的招聘薪資也的確比較高。但是並不是使用了一些工具，僱了一些 DevOps 的工程師，你的 DevOps 就可以做得很好。

很多的企業想：“我要做敏捷，我要做 DevOps 。做了之後，軟體交付速度就從一個月變成了兩個星期，進而兩天，甚至一天，或者更高。

然而，現實中的企業歷程通常是下圖藍色曲線這樣的。您可能已經注意到，曲線的後半部分是虛線。 為什麼是虛線呢？因為只有很少的企業可能跨過鴻溝，持續提升。

1 鴻溝產生的原因？

---

當某個組織說：“我們要 DevOps 了”以後，會馬上找來一批工具，再找一些DevOps 工程師，將它的現有流程做成一系列的自動化步驟（比如自動提測，發通知郵件等）。

此時，我們會得到一些收益。當流程優化到一定階段以後，我們會開始關注“測試提速”這個問題。於是，就會開始做一些自動化測試。

在做自動化測試時，遇到的第一個問題就是測試環境準備的自動化。解決這個問題之後，我們也會得到一些收益，這個收益的大小決定於原來這個環境準備工作到底有多“痛苦”！

當這一步準備好以後，測試人員可能就會開足馬力寫一些自動化測試了。最初的兩個月裡，大家覺得這個效果也還不錯。然而，很快就會到達上圖中的第一個拐點。

此時很多人還沒有意識到，所以仍舊會按照現有的方式，由測試人員增加更多的自動化測試用例。

一段時間以後，就會覺察到，效果不像早期那樣明顯提升了。這個時候，常見的選擇有兩種，一是繼續堅持這樣做下去，很可能收益會下降。 另外一種做法是保持當前這種現狀。也就是說，大部分企業會停留在該曲線上那段平臺期的某一點上。

此時，DevOps 的實施策略是“摘取伸手可得的蘋果”。也就是：

（1）別讓變動太多，太大；（2）先找容易的事情做。如下圖所示。

為什麼這個曲線最開始有一個提升期？是因為流程自動化等工作減少了每個交付迭代中的事務性成本。

從最終客戶（使用者）的視角來看，每個軟體交付迭代包括兩類活動，一是增值活動，另一類是非增值活動，也可以叫做事務性成本。

這部分事務性成本是什麼呢？例如，測試活動、迭代計劃會議、站會等等。我們希望在保證交付質量水準的前提下，將這些事務性成本變得更低，從而增加更多的增值活動時間。

當這些事務性成本降低後，我們的原有交付週期中增值活動的時間就會變多。此時可以將迭代交付週期進一步縮短，從而讓使用者更快地得到軟體。

但縮短到一定程度以後，你很可能會發現，每一個短迭代週期中的增值活動和事務性活動時間的比例會再次恢復到原來水平，如下圖所示。這會讓團隊非常惱火，無論從上到下都非常得惱火。

為什麼會這樣呢？舉個例子，持續交付模式需要較多的自動化測試用例。而測試工作通常是由測試部門承擔的。測試部門有人力投入到自動化測試編寫之上。而最初寫的自動化測試都是端到端測試。

隨著端到端測試數量的增加，你會發現，維護這些測試用例需要很多的成本，很容易形成頭重腳輕的情況，如下圖所示。

這個時候就會有人跳出來，挑戰道：“你投入這麼多自動化測試的成本，收益是什麼？投入產出比值得麼？” 這種場景通常會發生在平臺期。這就是很難再走下去的原因之一。

端到端的自動化測試執行成本高，維護成本高，診斷成本也高。而很多組織的測試人員並不具備編寫低層自動化測試用例的能力。即使具備更細粒度的下層自動化測試用例的編寫能力，由於協作流程與組織文化等原因，也無法及時獲得必要的寫作變更資訊，這一樣會導致這些下層細粒度測試用例的編寫質量，以及用例變更的及時性。

那麼，如何跨越這個鴻溝呢？

2 實施 DevOps 的兩個關鍵思考？

第一：正確認識“度量”

怎麼強排程量都不過分。通常度量項有三種屬性。包括它的可觀察性、可行動性與時間性。時間性又分為引導性和滯後性，如下圖所示。

有一些指標是可直接觀察獲得的，但是無法對它直接採取行動。例如千行程式碼缺陷數量，它是可以直接統計並觀察到的，但它也有滯後性，因為當你得到這個資料之時，它已經成為事實結果。

與此同時，它也不具備可行動性，因為你無法採取哪些行動，直接降低這個指標。

相反，你可能使用一些引導性指標來指引團隊的行為，從而可能達成想要的結果，例如程式碼review的數量、程式碼規範檢查標準等。

另一個例子是：從提測到上線前發現的缺陷數量，這個指標也是滯後性指標，因為得到這個指標的資料時，它已經是一個結果。與之相比，自測的測試用例數量可能就是一個引導性的指標，而且是一個可行動指標。

我們假設：自測的用例數量增高後，提測後的缺陷會減少，但這兩個指標之間的因果關係只是我們的推測，還有很多因素的影響。

軟體工程中的一大難題就是“研發效率度量”。總會有人問，這個軟體開發效率到底如何度量？我也一直沒有發現一個非常有效的且業內可以達成完全一致的研發效率度量體系。

但我認為，在眾多的指標中，每一個度量指標都是意義的，但它對於你所在組織是否有效，就不一定了。這取決於組織能力、產品形態與人員技能水平。

上圖中，越靠近右側的指標具有更多的過程引導性，而越靠近左側的指標相對來說，就更多的是滯後性結果指標。兩個指標之間的距離越大，離得越遠，那麼它們之間的直接相關性就越弱。而且，其中多個指標之間也會互相影響。

因此，在設計改進方案時，必須想清楚這些目標中，你到底要選擇哪一組指標。當某一個指標發生變化以後，是否會引起其他指標的變化，預計這個影響有多大？這個影響預計需要多長時間才能夠體現出來？

另外，引導性指標通常會有延遲效應，它的作用需要一段時間之後才可能傳導至對應的滯後性指標，甚至因為距離太遠而無法被覺察過。

這些年積累的經驗，我覺得可以從以下幾個方面進行著手。

獲取度量資料，需要一定的成本。假如當前沒有任何準備的話，想要持續獲得全面性資料，前期投入一定不小。

因此，初期可以採用抽樣法以較小成本獲得一定量可信資料，以展開改進行動。但這種方式可能會有偏差，有一定的風險性。

另外，我還想提及另一個突破性關鍵點。即“尋求第二序改變”。有一本名為《改變》的書，該書中講到了“問題的形成和解決的原則”。

給我留下比較深刻印象的是，“第二序改變”可以引起更大的差異性結果。所謂第一序改變，就是指以系統本身結構不變為前提，對現狀進行改變，通常這種改變並不會引起“質”的變化。要想帶來“質”的變化，必須尋求第二序變化，即：通過對系統本身結構的改變而帶來變化。

第二：尋求系統本身結構的變化

例如，改變自動化測試用例的使用者。在沒有改變之前，自動化測試用例的使用者通常為測試人員。如果我們將它的使用者改為開發人員，此時，看待測試用例的視角，以及對測試用例的要求可能就完全不同。

通常為了讓開發人員能夠高效地利用這些自動化測試用例，改善開發人員的工作效率，這些自動化測試用例就必須符合四個原則，即：快、捷、信、時。

“快”是指每一個自動化測試用例的執行速度必須非常快。“捷”是指：一定要保證開發人員能夠非常便捷地一鍵執行其指定的測試用例集。“信”是指在測試執行完成之後，其結果是可信的。“時”是指用例準備的及時性。即當開發人員想要測試自己剛剛開發完成的功能時，最好自動化測試用例就已經準備好了。

如果所有的測試用例僅僅是針對那些非常穩定的功能特性進行測試，那麼它對當前開發任務的作用就沒有那麼明顯了。

自動化測試用例的使用者從測試人員改變為開發人員，這就是一個“第二序改變”。為了完成這種改變，就必須改變原有的思考和工作模式。

為了達到這些要求，我們可能需要將一些測試用例的層次從最上層的端到端測試下移到系統整合測試、元件測試，甚至單元測試，如下圖所示。

這很可能會導致團隊角色與職責的變化。因為這種變化打破了原有的工作流程與結構，就很可能帶來新的改變。

這種改變可能就會改善我們的自動化測試用例數量的狀態，並向著良性的正三角形發展。

到目前為止，我們討論的都是“軟體交付領域”的內容，也就是《持續交付 2.0》中所說的提升“快速驗證環”的努力，即如何快速交付那些已經準備好的需求。

然而，從產品的角度考慮，這個閉環並不是一個完整的閉環，因為準備好的需求並不是問題的起點。那麼問題的起點在哪裡呢？當然是在業務領域。

我們開發軟體，是為了解決某些業務問題。因此，如果我們從更完整的視角看待問題，那麼軟體價值的交付應該是兩個環的閉環模型，如下圖所示。

從“提問”開始，為什麼要開發軟體功能？做了它以後，我們期望對哪些指標產生怎樣的影響，為什麼我們認為會產生這種影響，這就是“錨定”。

有多少種不同方法可以達成我們期望的改變，這就是“共創”。到底哪個方案是我們認為最有可能達成我們目標的方式，這就是“精煉”。

然後才是“快速驗證環”這才是一個真正的、完整的價值交付的環，從提問開始，真到問題是否得到解答為止。

3 DevOps 走向哪裡？

最後，讓我們暢想一下。在 DevOps 運動的催化下，未來的組織可能是什麼樣的？DevOps 強調通過使用共同的語言，讓不同角色能夠更緊密地協作，從而提升交付效率。而相同的目標更容易產生共同的語言。

對企業來說，更有意義的目標是業務目標。目前，很多 IT 組織並非以業務目標建立組織結構，而是以職能目標建立組織部門。

為了能夠更好地完成業務目標，企業就需要考慮如何圍繞業務目標來組織資源。並沒有哪一種組織結構是完美的，但圍繞業務目標來組織團隊通常都是適合的。

“組織牆”總會存在的，當我們打破不同職能部門之間的“牆”，同時也會建立“業務單元牆”。只要保證這種“牆”是容易打破並重建的，那麼組織就是健康的。

只有這樣，我們才能建立一個靈活而又強大的彈性組織，它由一系列小的業務單元組成，以應對市場的發展變化。

需要強調的是，不僅僅那些直接服務於外部客戶的組織是業務單元，服務於組織內業務單元的團隊（例如基礎設施服務）也應該按其服務的業務或內部客戶不同而作為業務單元來對待。如何定義“業務單元”是一個複雜話題，因為其與企業內外部環境強相關。

當我們有眾多業務單元時，這些小的業務單元之間要做到 “對齊”是一個巨大的挑戰，尤其當業務單元之間存在協作時。現在業內經常提到的“中臺”架構，似乎是對“小業務單元”相左。然而，事實上，這個“中臺”也應該是由多個小業務單元構成，並要高度“對齊”的。

雖然，單一個體的效率最高（因為決策與行動一體化）。但是，個體的能量是有限的，所以我們仍舊需要高效溝通，以便“對齊”。

就像技術架構中的微服務架構一樣，需要將很多的小業務單元高效地串聯起來，才能真正發揮這種多個小團隊協作的優勢。如果沒有協調好這些業務單元，那麼可能提升了單一業務單元的內部效率，但整體的價值產出並沒有增速。

那麼，如何”高效對齊“呢？一種可能的方式（並不是唯一的方式）是參考”阿米巴經營“。日本京瓷公司是生產陶瓷製品的公司，是典型的生產製造行業。它由稻盛和夫先生創辦，並在經營過程中總結出了“阿米巴管理經營方式”。

在2009年，稻盛和夫再次出山，成功運用這一管理工具，帶領日航走出困境。日航是一家提供航空運輸的服務性企業。

他將由生產製造行業中總結的“阿米巴管理”也成功運用於服務性企業，將日航30000 多名員工分成 10 人左右為一個最小經營單位的眾多阿米巴，並讓每個阿米巴作為獨立經營核算，啟用所有員工，讓他們自己組織起來，為自己的目標工作。

要想完成這樣的轉變，必須從以下三個方面著手。一是軟體架構，二是組織機制，三是協作基礎設施，如上圖所示。

由於時間關係，我就不再展開討論。在《 持續交付 2.0 》一書中完整地講述了三個實踐案例。

根據組織規模、業務目標、產品形態的不同，這三個案例選擇了不同的實現路徑。如果你對它們感興趣，可以參考《 持續交付 2.0》的最後三章。

4 小結

在不改變系統結構的前提下，優化是容易進行的。但是，優化到一定程度以後，可能就需要尋找第二序改變，才能夠”涅槃重生“，達到更上一層樓。

本文根據 DevOps 國際峰會（DOIS）2018 · 深圳站喬樑老師分享整理而成，經喬樑老師審定授權釋出。