作者/分享人：喬梁，20年IT老兵，騰訊公司高級管理顧問，敏捷和精益開發專家，持續交付領域先行者。曾就職於百度，國內多個知名互聯網公司的企業教練。 歷年QCon技術大會的講師和專題出品人。

這是一個新概念風起雲勇的時代。 就讓我們從雲端抓它幾個名詞下來，一起玩耍吧！！！ “敏捷軟件開發”，“增長黑客”，“持續集成”，“DevOps”，“精益創業”，“持續交付”，“大數據”... ...

OK，就這四個啦：

“敏捷軟件開發”，“持續集成”，“DevOps”，“持續交付”。

先讓我們在Wikipedia上驗明正身。

在Wikipedia上的定義

敏捷軟件開發

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

持續集成

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

持續交付

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.

DevOps

DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.

我的解讀

1. 敏捷軟件開發方法

從來就沒有一種方法，叫做“敏捷軟件開發方法”。因為，IT行業中的“敏捷（Agile）”一詞，從2001年它的誕生之日起，就是個軟件開發方法集合，當時這個集合中的方法，都遵從敏捷宣言和相同的工作原則（十二原則），它的締造者是十七位軟件工程師（請查敏捷，雪鳥會議）。目前，在這面大旗下，又增加了很多種方法，當然也有很多方法走出了人們的視線。

在國內比較活躍的幾種方法：極限編程XP（2009年以前），Scrum及其進化品（2006年至今），精益軟件開發方法（2009年至今），看板方法（2012年至今）。當然，現在好象也不再特意強調“敏捷宣言”和“十二原則”了，只在培訓課堂上還能聽到。

2. 持續集成

早在1999年KentBack的《解析極限編程》一書中，對“持續集成”這一概念就有提及，它是極限編程XP方法中的十二最佳實踐之一。在2004年，Martin Fowler發表的一篇博文上，給“持續集成”下了一個定義，並一直沿用至今。即：“持續集成是一個軟件開發實踐， 是指團隊成員頻繁地集成他們的工作成果，通常每天每個人至少集成一次， 這樣在團隊內每天都會有多次代碼集成，每次集成都有通過自動化的構建（包括測試）盡可能快地發現集成問題。” 這個概念已被軟件研發團隊廣泛接受，但是其中提到做法，並未能全部落實，太困難了。 這是正常的，來自極限編程方法的實踐，都是有挑戰的，否則就不叫“極限”二字了。

3. DevOps

在2008年的一次敏捷大會上，運維相關人員就“敏捷基礎設施（Agile Infrastructure）”展開討論，並在2009年以後逐步發展成為一場大規模“運動”，它是期望改變開發團隊和運維團隊之間協作關系的一場運動。強調開發團隊與運維團隊的溝通與協作，同時將軟件的交付與基礎設施變更過程都能夠自動化。近年基礎設施及工具鏈的發展，也讓DevOps多了一些發力點。

4. 持續交付

Jez Humble和David Farley在2010年《持續交付》一書中正式提出這個概念，它在書中被定義為：一系列的原則與實踐的集合；通過這個集合，團隊能夠在低成本、短時間及低風險的狀態下以增量方式將軟件變更交到用戶手上。Jez認為，持續交付有三個支柱，它們分別是持續集成、自動化測試和部署流水線（Deployment Pipeline）。

它們的關系

1. 空間與時間維度

根據以上的信息，我認為它們在空間和時間維度的關系是這樣的：

上面這個圖是從實踐或環境的角度來看它們之間的關系。那麽，如果我們換一個角度呢？

2. 人或組織維度

我的微信簽名是“別提概念，只解決問題！”。所以我更願意從解決問題的角度看這些概念。一談到問題，就有一個經典的話浮現在我腦海裏：“所有的問題，都是人的問題”。所以，這個角度看到的才是本質。那麽，它們的關系是什麽呢？

持續集成，有助於打破開發人員和測試人員之間的“墻”。

敏捷開發，有助於打破研發團隊（開發+測試）與業務（產品）人員之間的“墻”。

DevOps，有助於打破開發團隊與運維團隊之間的“墻”。

持續交付，則是希望從端到端的角度，考慮如何解決問題。

為什麽從“人”開始

在我多年的持續交付踐行及咨詢工作中，總結的經驗是：如果希望在最短的時間和成本內，取得最大的收獲，那麽在一開始，與“人”相比，技術實踐並不需要太在意，即：最好還是先從“人”的角度看問題。真正去解決問題時，上面說的種種概念並不是那麽重要。它們都是你用來解決問題的工具，而且其中的每一個工具（概念）都包含了很多個小工具（原則和實踐）。而且，在解決問題時，你也不必整套選擇這些工具。

從哪裏找問題

從參與者的問題陳述中找問題。比如：

老板：

• “項目經常延期” “做東西太慢”

產品：

• “老板的想法總變”

• “事情太多，忙成狗”

• “開發說這個實現不了”

開發：

• “需求總變”

• “UI方案給的太晚”

• “活兒太多”

測試：

• “需求變了沒提前通知”

• “測試時間總被壓縮，還要背鍋”

• “重復測試太多遍”

運維：

• “每天這麽多版本上線，活幹不完，出事兒第一個背鍋。”

每句話的背後都有很多含義。開挖吧～～

提問題的人是問題的創造者，也是接盤俠～

從哪裏找解決方案

在《持續交付》一書的第十五章，提到一個“持續交付成熟度評估模型”。在這個模型中，包含如下六個維度：

• 構建管理和持續集成

• 環境與部署

• 發布管理和和符合性

• 測試

• 數據管理

• 配置管理

通過實際工作的驗證，我發現，這裏面缺失了一些東西。所以，增加了一些維度，並重組了一下，如下圖所示：

我也沒有稱其為成熟度模型，而是“持續交付七巧板”。

是的，中國的傳統玩具“七巧板”，這個兒時的玩具可以拼出各種各樣的圖形。也就是說，每個團隊、企業都有不同的環境上下文（人也是環境的一部分），解決方案也不必一樣，關鍵是你想解決什麽（想拼成什麽圖形）。

找正確的問題去解決

上面的諸多概念並不是你的問題或目標，而只是你的工具（手段）。千萬不要把手段當成你的目標來實現。很多人問：

• 怎麽做持續交付？

• 怎麽做持續集成？

• 怎麽做敏捷？

• 怎麽做DevOps？

我猜測你是想問：是否有捷徑做XXX。當然有，多種途徑裏，一定有相對來說的捷徑，但不一定是你期望的那種“捷徑”。

• 我們做的是敏捷嗎？

• 我們這麽做持續交付，對嗎？

我猜測你是想問：（某個人或部門）這麽搞，是不是靠譜啊？

• 你這不是敏捷？

• 你這不是DevOps？

• 你這不是持續交付？

• 你這不是持續集成？

我想說：無所謂，因為我的在微信上的簽名是：別提概念，只解決問題。我們還是先討論清楚問題吧～

再炒一炒冷飯

2011年，我在InfoQ上發表了一篇案例文章《DevOps，不是一個傳說！》，其中有兩個評論比較有意思：

1. 怎麽感覺就是一個從瀑布模型到Scrum/CI的變化？
正如我們上面第二張圖所示，這個項目的前期工作，的確主要是在敏捷開發的範疇，但文中還是提到一小部分Ops方面的東西，可能評論者沒有註意到吧。或者沒有看到他想找的內容。

2. 標題黨啊
好吧，我承認在那個很少有人提及“DevOps”的年代，我就做標題黨吧。

這個案例就混合了上面所有的概念，但在項目裏，誰還在意概念呢，達成結果最重要。

一、了解環境背景

當任何人想要對組織進行改變時（無論改變的大小，你叫它改進、轉型或者變革都可以），一定先要了解組織的歷史，感受組織的文化，因為組織的歷史決定了問題的來源，定義了問題的範圍。

幾年前的百度，工程管理相對固化，敏捷還在“小步快跑，越變越美”的倡導期（從瀑布到叠代，強調項目管理中的叠代概念）。一個從Google跳槽加盟百度的技術經理在自己的部門裏倡導“主幹開發（Single Branch mode）”，但由於原有的基因特別強大，進展艱難。 而這個項目是在最有百度特質的大搜索團隊，試驗田是一個10人左右的工程架構團隊。

團隊間接管理者

• 項目交付不太可控：

• 我們一直在做計劃，但計劃性非常差。

• 經常有各種各樣的情況發生，總會讓項目改期。

團隊直接管理者

• 我非常希望能夠快速交付，但我們對這類架構變動類的項目不知道怎麽能做到。

• 這個項目中，有一部份需求必須在XXX時間點完成。

團隊Lead

• 估算不準確、臨時插入事情多、項目計劃很難做（這裏省略一千字）。

• 我不知道怎麽改進，因為我周圍的團隊也是這樣，而且一直這樣工作。

開發人員

• 領導說試一下，就試一下吧。

測試人員

• 工作經常被打斷。

• 提測質量不高，經常浪費精力。

• 出了Bug，影響太大。

• （這裏省略一千字）。

二、找到正確的問題來解決（目標）

三個月內：

（１）該項目交付時間可預期。

（２）建立新的軟件開發協作方式。

（３）建立必要的基礎設施，以支持後續的持續發布模式。

三個月後：

（１）需求的周期時間縮短，可以短周期上線。

（２）生產環境的質量不降低。

（３）測試人力總投入降低。

在少於30人的團隊（61個人也可以～哈哈～那62個人呢～～～）

1. 通常行為的改變，需要一個半月的時間；

2. 帶來強烈可感知的收益需要三個月的時間。

三、承諾是必須的

上面的問題（目標）找到了，也要一並承諾。

要想讓團隊和你走，你必須站在前面。

四、培訓及過程指導

需要解決團隊提出的任何疑問，如果當時不知道如何解決，也要承認。

啟蒙培訓（1小時）

對於這種能夠直接認識團隊每個人的小團隊，一開始就別花費太長時間講大道理，以解決具體問題的方式來啟蒙。

重新定義工作流程

• 新的項目工作流程

• 新的叠代工作流程

• 新的需求工作流程

• 新的代碼工作流程

解決新流程中的障礙

• 團隊溝通和協作的方式。

• 編譯環境的準備。

• 編譯時間的縮短。

• 自動化測試策略的制定，比如：我們放棄了原教旨主義的單元測試。

  

• 自動化測試運行的環境的準備。

• 自動化測試編寫時機與自動化的利用。

• 自動化測試用例代碼管理。

我和運維人員的對話（真實的場景再現）

我：我們團隊想每兩周就部署一次服務

運維：不行

我：為啥？

運維：線上需要穩定

我：每兩周部署一次，就不穩定了嗎？

運維：原來的質量太差，每次上線總是出問題

我：現在質量很好

運維：怎麽可能？

我：我們改變了工作方法，質量優先，你可以參加我們的站會。你有什麽要求，我們都可以滿足

運維：那也不行

我：為啥

運維：我沒有那麽多時間。一次部署要涉及370多臺機器。原來三個月上線一次，每次前前後後要折騰兩天。現在每兩周上線一次，我還哪裏有時間去幹其它業務線的活啊？

怎麽解決？

改變部署方式，讓他的工作生活美好起來吧～～～～～

• 部署流水線的建立，要求一鍵部署

• 運維人員負責編寫部署腳本，並做版本管理。

• 開發人員在開發自測時使用同樣的腳本。

• 測試人員在測試環境上使用同樣的腳本。

• 運維人員在生產環境上也使用同樣的腳本。

如果想了解更多，我的“持續交付”微信公眾號上對這個案例進行連載分析。感興趣就來我的Chat交流吧。

善意的提醒

強烈建議大家仔細研讀《持續交付》，盡管這是一個大部頭著作，而沒有代碼，少量插圖，也沒有什麽工具使用說明。

我正在寫一本關於持續交付案例解讀相關的書，希望能幫助大家。書中很多內容是我在實際工作裏如何運用書中的理論和原則，做出我認為適當的選擇（比如上例中的不做單元測試），幫助團隊解決實際問題。

原文地址：《持續交付和DevOps的前世今生》

[轉載]持續交付和DevOps的前世今生