作者 | Christopher Lee & Sean D. Mack

譯者 | 溫馨

如果您曾經對敏捷或DevOps的歷史、結構、原則或好處有過疑問，那麼您將在這篇文裡找到答案，本文被拆分兩篇，上篇主要介紹敏捷和DevOps的歷史、差異和好處。

敏捷和DevOps從表面上看可能是不同的，但如果關注他們的目標，會發現它們其實非常相似。兩者的目標都是更快地為客戶創造價值並更快地改變市場需求。DevOps採用敏捷中介紹的原則，並將其擴充套件使用到程式碼以外的部署和運維操作中。

敏捷和DevOps的目標是一致的，因此在實踐過程中會發現它們有所重疊。在許多方面，DevOps和敏捷的交叉關係到協作文化以及從這種文化中產生的現代技術實踐和過程。連續測試和小批量生產等過程中更容易看到了這一點，在使工作儘量可見化的過程中，公開工作流和系統遙測，有助於確保向客戶快速交付工作產品，能加速向客戶傳遞價值。

敏捷和DevOps專注於提供客戶價值，這不是為了提供更多功能，而是為了儘可能快速有效地向最終客戶提供正確的增值功能。DevOps使用敏捷的概念並對其進行了擴充套件延伸，因此您可以通過實現DevOps實踐來增強敏捷性。

什麼是DevOps？什麼是敏捷？

在開始研究DevOps和敏捷之間的關係之前，首先要對這些術語的含義有一個共同的理解。雖然有許多定義，但它們可以從根本上理解為一套原則，從中可以衍生出工程師文化和實踐。

敏捷的存在時間比DevOps長，定義也更為成熟。首次定義於2001年2月的《敏捷宣言》，該宣言包含了以下幾條定義：

• 個人和互動重於流程和工具
• 工作軟體重於公共文件
• 與客戶協作重於合同談判
• 響應變化勝過遵循計劃

儘管已經有了對DevOps宣言的嘗試，但還沒有哪一個宣言能夠獲得敏捷宣言所具有的那種廣泛接受度。作為一個一般概念，DevOps重視協作，特別關注開發和運營團隊之間的交叉功能以及這兩個方面的責任。敏捷教練Anthony Gardiner說，“我測試，我編碼，我部署，我在週末起床並修復錯誤——我讓我的程式碼更好，所以我不必在週末起床。”DevOps可以被認為是一種為客戶提供價值的方法，專注於協作和小批量，聚焦持續整合，自動化，持續測試和持續交付。

雖然沒有單一的定義，Gene Kim、Kevin Behr和George Spafford在他們的開創性書籍《鳳凰計劃》中介紹了DevOps的“三種方法”。這三種方法是許多DevOps實踐的核心。

Kim後來在《DevOps Handbook》中對這些方法進行了擴充套件，他與Jez Humble和Patrick Debois合著了這本手冊。

這三種方法包括：

歷史

追溯到20世紀90年代，敏捷已存在的時間比DevOps長得多，後者在將近20年後才出現。然而，這兩套原則都源於精益製造，其歷史可以追溯到20世紀40年代。雖然DevOps的流行度持續增長，但敏捷仍然比DevOps更廣為人知。谷歌趨勢表示“敏捷”一詞的搜尋量大約是“DevOps”一詞的三倍。

敏捷的根源可以追溯到20世紀40年代的精益流程，其中包括看板，一種視覺化豐田生產系統一部分工作流程的方法。限制理論也是後來發展起來的。然而，敏捷的軟體開發方法在20世紀90年代真正起步，當時一群軟體開發人員常受到瀑布式開發方法中涉及的高度嚴格的流程的困擾。這些常導致軟體專案花費了數月甚至數年才導致失敗。在20世紀80年代和90年代，誕生了幾種軟體迭代開發方法作為瀑布方法的替代，包括極限程式設計（XP）和看板。1995年，引入了敏捷開發的Scrum實踐。然後，在2001年Snowbird山度假村的著名會議上，一群思想領袖齊聚一堂，共同編寫敏捷宣言。敏捷發展至今，其中許多變化和實踐都是從最初的宣言演變而來的，包括現代敏捷。雖然敏捷制定了總體原則，但實踐敏捷原則的方法有很多，Scrum和看板是最受歡迎的兩種（關於它們的區別，可閱讀《Kanban VS Scrum：哪個是最好的敏捷專案管理框架》）。

DevOps是一套更為新的原則，它源於精益製造中的一些相同概念。“DevOps”一詞於2009年首次推出，當時Patrick Debois在比利時舉辦了“Devopsdays”活動。2013年，Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰寫了他們的書《鳳凰計劃》，其中提出的許多內容構成了DevOps的基礎概念。2014年，隨著DevOps企業峰會的啟動，DevOps不斷擴充套件到企業環境中。今天，DevOps繼續與敏捷一起成長和發展。

關鍵差異

雖然敏捷和DevOps具有很多一致性，但需要注意的是它們的側重點不同。敏捷主要關注應用程式的構建，而DevOps則將這一重點擴充套件到構建和運營應用程式。DevOps採用了敏捷的許多概念，並將這些概念擴充套件到構建過程之外並帶入生產。正是這個擴充套件導致了真正的差異。

如果說存在不同，那麼主要在於聚焦點的不同。敏捷教練Martin Corbett表示，“敏捷專注於分解工作，以儘快為客戶提供更多價值，而DevOps專注於將程式碼從構建擴充套件到部署的專案，例如持續部署。”此外，敏捷專注於構建工作軟體以及開發和QA之間的協作，而DevOps則專注於開發、QA和運營之間的協作。

雖然許多人都在尋找敏捷與DevOps之間的差異，但實際情況是，這兩種方法具有非常相似的目標和基礎原則，並且最終具有比差異更多的相似性。

DevOps是敏捷的延伸

在許多方面，DevOps可以被視為敏捷的延伸，甚至是敏捷的自然演變。在瀑布開發流程中，有一個明確的交接（它是強制執行的過程）。敏捷作為一個持續的過程，需要一種新的方法，DevOps有助於實現這種方法。

為了實現精益和敏捷最佳實踐的核心小批量釋出，在DevOps中普及的全棧工程師的概念是這種需求的最佳答案。為了減少交接，工程師必須悉知系統的所有部分，以便團隊中的任何成員都能理解操作要求，而無需交付給其他團隊。同樣，跨職能團隊必須成為常態，以便小型，獨立的團隊可以提供功能齊全的產品，而無需向運營團隊進行額外的交接。

此外，敏捷的持續流程需要一定程度的構建和部署自動化。其中大部分都是在DevOps的CI / CD實踐和工具中提供的。CI / CD需要快速部署經過全面測試並且功能齊全的程式碼給客戶。因此，很容易看出CI /CD是敏捷實踐所必需的自然演化。這些做法持續發展，使釋出週期時間進一步縮短，從數週到數天甚至數小時。

從另一個角度考慮，如果您有一個只有在開發完成後才能開始的為期兩週的QA週期，那麼在一兩週內就很難將程式碼推出。同樣，諸如變更審批、釋放資源、硬體購買和安裝等需要耗費時間的事情，都會影響你按時推出程式碼。更不用說，您可能還有很多的交接工作，或者有一個週期長又繁重的釋出過程。如何進行為期兩週的迭代並進行為期兩個月的釋出過程？對此的明顯答案是DevOps。

這並不是說沒有DevOps就無法實現敏捷。敏捷在DevOps之前很久就存在，並且肯定有敏捷團隊不遵循許多DevOps實踐。正如Noah Cantor所說，“你可以做敏捷實踐和DevOps實踐，但你不能採用敏捷原則或DevOps原則，因為它們太相似而不能分開。”並不是說它們不可分割，只是敏捷作為DevOps的前身，同時激發了DevOps的影響力。

好處

精益一直是DevOps的核心，就像敏捷是從精益中生長出來的一樣。DevOps也是如此，所以這兩者有很大的共同點並不奇怪。DevOps採用Agile中的概念，並將其擴充套件到程式碼部署之外。DevOps採用這些概念並將其應用於應用程式和服務的管理。它利用並優化了敏捷的原則，並且沿用了敏捷組織早已意識到的長處。

並不是說為DevOps而做DevOps，或者說為敏捷而做DevOps。2017年DevOps狀態報告顯示，高效能DevOps團隊的部署速度提高了46倍，交付時間縮短了44倍，更改失敗率降低了5倍，平均恢復時間縮短了96倍（MTTR）。在具有成熟DevOps實踐的組織中，這些數字顯然被低估了。

當我們檢視敏捷和DevOps重疊的每個區域時，DevOps放大了敏捷實踐，我們希望您能夠採取一些具體措施來推動組織的發展。構建協作的最關鍵步驟之一是制定共同目標。有了共同的目標，您可以確保開發，運營，QA都一致朝著同一目標努力。

小批量交付為推動DevOps實踐加速組織提供了另一個絕佳機會。在Scrum或看板等流程中，要將操作任務和操作思想整合到工作中。如果您正在使用Scrum，您也可以考慮使用看板，它更容易適應操作流程。

無論使用哪種方法進行小批量交付，您都可能希望確保使用相同的系統來跟蹤整個團隊的工作。通過統一跟蹤系統，您可以確保不積壓工作，並真實反應所有計劃內和計劃外工作，讓您更容易地使工作可見。作為敏捷的一個關鍵原則，我們還可以擴充套件使工作可見的概念，以顯示運營工作、系統操作和架構支援等工作。組織還可以通過資訊輻射體（比如看板）跨團隊分享這些資訊。

當您著眼於構建更具協作性的文化時，要把每一次失敗都當作組織學習的機會。在這個文化中建立一些儀式，比如無可指責的事後反思、黑客馬拉松和失敗獎勵等。

對於本文中討論的重疊，存在組織上的含義。在敏捷和DevOps中包含QA意味著我們必須開始構建跨職能團隊，並培養具有廣泛知識技能的人員。這種重疊是隨著“全堆疊工程師”的概念而發展起來的。雖然每個人都知道一切可能不現實，但我們當然可以努力確保團隊中的每個人都有共同的責任和目標，包括質量和運營，如果他們樂於負責和學習的話。

有許多方式可以採用敏捷原則並使用DevOps強化它們，但最重要的是組織文化的一致性。如果團隊在目標上沒有保持一致，那麼敏捷中規定的團隊方法將不能擴充套件到部署以外的操作中使用。如果所有技術交付團隊都遵循相同的目標，即可立即開始打破這些組織之間的孤島。如果我們可以通過敏捷開始打破組織孤島並通過DevOps強化這項工作，我們將擁有真正的高效能組織。

『由於篇幅原因，本文被拆分兩篇，下一篇主要將介紹DevOps和敏捷之間的幾個共性，歡迎大家持續關注。』