DevOps 是敏捷應用於軟體團隊的成果。但真正的問題是，在一場比賽中，哪一方會獲勝？
在角鬥場的一頭，我們有經過認證的敏捷教練，他的朋友們都知道他是一個極限程式設計師，而在他的孩子們眼裡則是不那麼安全的父親。他就是＂敏捷＂！
而在另一頭，我們有一個精益文化機器，他不斷地將他的架構以程式碼形式傳遞出來，他的左臂就是開發，他的右臂是就運維。他就是＂DevOps＂ !
儘管我已經把雙方都視為已經被炒作得天花亂墜的概念，但關於敏捷和 DevOps 的聲音讓它們聽起來像是非常不同的想法。更復雜的是，即使兩個概念有自己的行話和口號，但它們的定義依然含糊不清。作為歷史更悠久的一方，敏捷可能不那麼模糊，但人們對 DevOps 的眾多定義感到迷茫無助是很常見的。缺乏精準的定義導致了他們之間產生一些共同關聯點。
許多人認為敏捷意味著 Scrum，DevOps 意味著持續交付。這種過度簡化在敏捷和 DevOps 之間造成了不必要的緊張局勢，所以當你發現他們是最佳拍檔時，你會感到驚訝無比！
不可否認，DevOps 與敏捷之間的歷史是有千絲萬縷的聯絡。當 Patrick DuBois 和 Andrew Clay Schafer 試圖在 Agile 2008 大會上討論“敏捷架構”時，與 DevOps 的聯絡就誕生了。儘管 Patrick 後來才創造了“DevOps”這個詞，但在 DevOps 的發展歷程中仍然用敏捷大會來紀念這一起點。當我們深入到 Scrum 和持續交付的表面之下時，我們深入研究一下歷史，就會發現敏捷和 DevOps 之間的實際聯絡。
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
敏捷不僅僅是 Scrum
在一些團隊中，Scrum 是兩種協作之間的區別，一種是持續令人沮喪的鬥爭，另一種富有成效、回報頗豐。在另一些情況下，Scrum 以客觀和專注取代了辦公室政治和過度承諾，它也可以視為信條教理。當由於業務或工作本身的約束要尋求變化或者做出改變時，敏捷團隊將祭出 Scrum 基本原則的利劍，檢查他們的實踐行為，以逐漸變得更加高效。當 Scrum 應用於軟體開發的環境之外時，這一點尤為重要。
預先對計劃以外的工作做規劃
在 DevOps 社群中，那些有敏捷經驗的人同意 Scrum 對於跟蹤計劃中的工作是有用的。一些運維中的工作可以被計劃：比如釋出一個大的系統變更，在資料中心之間遷移，或者執行系統升級。但是大部分的運維工作都是無法計劃的：效能達到峰值上線、系統中斷和安全問題。這些事件需要立即做出反應，沒有時間等待其加入待辦事項列表再按優先順序排列，也不可能在下一個衝刺週期中再列入計劃。出於這個原因，許多已經開始擁抱 DevOps 思想的團隊，從 Scrum 跳躍到了“看板”。這有助於他們跟蹤這兩種工作，並幫助他們理解之間的相互作用。另一種方法是採用一種混合方法，通常稱為 Scrumban 或 Kanplan（帶有計劃的看板）。
在許多方面，Scrum 被廣泛採用的關鍵點可能是它沒有預先設定任何技術實踐。Scrum 的輕量級管理實踐常常對團隊產生很大的影響。在過去，多個管理者會提出不同高優先順序的事項，在現在，只有一組定好了優先順序的待辦事項。過去有太多的工作同時在進行中，現在都按一個被時間約束、被討論驗證過的計劃來執行。綜合起來，這可以讓一個團隊達到新的生產力水平。然而，團隊可能會發現自己受到缺乏技術實踐的限制，比如程式碼評審、自動驗收測試和持續整合。
其他像極限程式設計（Extreme Programming）這樣的敏捷過程，對於技術實踐如何支援團隊保持速度、併為管理人員和利益相關者提供透明度和可見性，有很有力的觀點。一些 Scrum 團隊將技術任務放在待辦事項列表中，雖然這很符合 Scrum 的指導原則，但它很快就遇到了實際問題——產品負責人對功能特性的偏見。除非產品負責人非常懂技術，否則她或他可能沒有能力評估技術實踐的價效比(成本/效益)。當技術任務延伸到運維工作以支援可靠性、效能和安全性時，對於產品負責人來說，這就變得更加困難了。
「CODING 企業版」作為企業級軟體研發管理系統，任務看板功能實現了 Epic \ user stories \ Sprint 等敏捷概念落地。
產品負責人和服務負責人
在 Atlassian，我們已經認識到在產品中有兩個不同的角色是有幫助的。我們的產品負責人很擅長理解使用者需要的特性，但是他們不太擅長將這些特性與效能、可靠性和安全性等非業務性功能進行權衡。因此，Atlassian 的一些 SaaS 產品也有相應的服務負責人，負責對這些非業務性功能進行優先順序排序。從時間上看，這兩個負責人可能不得不進行一些“激烈的討價還價”，但大多數情況下，這些都可以由獨立的團隊來完成。這可能不是從運維工作中“放大反饋”的唯一方法，但它確實有助於克服產品負責人對功能特性的普遍偏見。這種“兩個負責人”的方法並不是唯一的 DevOps 方法，重要的是要理解這些作為“特性”的非業務性功能，並且能夠像任何其他功能一樣對它們進行計劃和排序。
在 DevOps 成為主流之前，它不會是 Scrum 的自然結果。
最終，這些對 Scrum 的批評都不是 Scrum 本身固有的。與所有敏捷方法一樣，Scrum 有一個內建的“過程改進”機制，稱為回顧。因此我們有理由相信，一些 Scrum 團隊將利用 DevOps 作為靈感的來源，並將 Scrum 回顧對 DevOps 進行調整。然而，要意識到大多數團隊需要外部力量來推進，這是很實際的。直到 DevOps 成為主流（甚至在學校裡開始教過）之前，DevOps 也不會是 Scrum 的自然結果。無論團隊引入的是敏捷教練還是 DevOps 教練，這都可能是無關緊要的，只要這個人能夠在構建、測試和部署軟體的過程中帶來自動化的經驗。
DevOps 不僅僅是持續交付
如果執行得好，持續交付（CD）的規程有助於規範正在進行中的工作，而部署的自動化有助於提高約束。通過這種方式，持續交付可以幫助軟體團隊更頻繁地交付，並保證更高的質量，而不是在兩者之間做出妥協。然而，就像團隊只關注 Scrum 一樣，可能會錯過敏捷更廣泛的環境，所以專注於持續交付的團隊也會錯過 DevOps 更廣泛的背景。
持續交付的實踐並不能直接解決業務和軟體團隊之間的溝通問題。如果業務團隊有一年時間的計劃週期，那麼軟體團隊將每個程式碼提交上線可能還需要等待幾個月才能得到反饋。通常這些反饋都是作為下一步的指示，比如取消專案，或者困擾專案團隊的其他麻煩（通常大量新使用者的湧入對效能是破壞性的）。
敏捷流暢度模型表明，第一級的流暢性是“專注於價值”，而團隊關注的是透明度和一致性。如果沒有這種流暢性，持續交付可能很容易地發展成一個無窮無盡的技術改進迴圈，對業務沒有任何價值。一個團隊可能擅長於以高質量的速度交付，但是對於終端使用者或業務來說這可能是一個價值較低的產品。即使有許多使用者說了這是好東西，但在更大的業務組合級別上，可能對這個產品的評估是低價值的。如果沒有這種重要的流暢性，就很難衡量技術實踐與功能特性的關係。對於具有遺留程式碼庫的團隊來說，這一點尤其重要，因為它可能沒有自動化測試或適合頻繁部署的設計。在遺留的環境中，持續交付轉換可能需要數年時間。因此，能夠證明商業利益是非常重要的。
三種方法
DevOps 不僅僅是自動化部署流水線。用 John Allspaw 的話說，DevOps 關乎“像開發者一樣思考的運維，像運維一樣思考的開發者”。在詳細闡述這一思想時，Gene Kim 介紹了作為 DevOps 原則的三種方法：
第一種方法：系統性思維 —— 強調整個系統的效能，而不是一個特定的工作或部門的效能。這個系統它可以像一個部門一樣大，也可以像單個貢獻者一樣小。 第二種方法：反饋放大回路 —— 建立從右往左的反饋迴圈。幾乎任何過程改進計劃的目標都是縮短和放大反饋迴圈，這樣就可以不斷地進行必要的修正。 第三種方法：持續試驗和學習的文化 —— 創造培養兩種東西的文化：不斷地試驗、冒險以及從失敗中學習；理解重複和練習是掌握的先決條件。
持續交付（CD）關注的是第一個方法：將從開發到運維的流程自動化。自動化在幫助加速部署系統方面起著明顯的作用。但是，系統思考不僅僅是自動化。 第二種方法的特點是，開發者也要戴著尋呼機。 儘管使用尋呼機這樣的描述可能是不必要的，但這意味著將開發人員拖入運維工作。這有助於開發人員瞭解他們的開發選擇的後果。例如，這可以激勵開發人員把日誌資訊放在更好的地方，並使這些訊息更有意義。這不僅僅是關於意識的問題。開發人員還將他們對系統的內部理解引入故障排除工作，因此可以更快地找到問題並提出解決方案。 第三種方法是在整個系統中進行增量式的試驗，而不僅僅是應用程式在流水線中移動的變化。 換句話說，自動化相對容易看出需要多長時間，並使用日益強大的基礎設施來不斷改進它。比較難理解的是角色或組織之間的交接是如何導致延遲的。這意味著團隊在整個交付工作流程中進行“檢查和適應”，尋找改善人與人之間協作的機會。就此而言，持續整合需要保持適應和改進的習慣。如果團隊沒有思考如何變得更有效率，並在任何事情上積極適應和調整它的行為，那麼持續整合也不會成長和繁榮。團隊需要有能力解決自己的問題。
在 Scrum 中，每個回顧都是一個改進實踐和工具的機會。但是，如果團隊沒有利用這些機會來解決短期和長期的技術問題，那麼他們就會等待產品負責人把持續整合任務放到待辦事項列表中，這是永遠不會發生的。
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
DevOps 是敏捷應用於軟體團隊之外的成果
Scrum 主要對映到的敏捷原則是，“歡迎不斷變化的需求，甚至於在開發後期。敏捷過程利用變化來保證對於客戶的競爭優勢。”
持續交付主要對映到的敏捷原則是，“我們的首要任務是通過早期和持續交付有價值的軟體來滿足客戶。”
這意味著敏捷更多的是擁抱即將到來的以及外部的變化，而不是像在會議站著或衝刺週期計劃這樣的儀式。實際上，敏捷宣言中還有其他 10 個原則。與其試圖在這些原則中做出選擇，不如把它們視為一個整體。這些原則共同代表了一種對敏捷和 DevOps 的態度：改變是很常見的。
DevOps 試圖將它作為敏捷的態度傳遞給新的受眾：IT 運維。
這些人一直在試圖保脆弱系統的執行，而這些系統對企業來說也是最重要的。因為它們對企業來說是最重要的，所以它們也是最迫切需要改變的地方。因此，這種擁抱變化的敏捷理念並不是“為了改變而改變”。它關乎讓開發對其變更的質量負責，同時提高交付業務價值的整體能力。這種對業務價值的關注是敏捷和 DevOps 相通的另一個方面。
最後，無論是敏捷還是 DevOps 都不是他們自己的商業目標。兩者都是文化運動，都是用更好的方式來激勵你的組織，以實現你的目標。敏捷和 DevOps 在組合中比對手更有效。避免這兩種想法之間的衝突的訣竅是理解它們所形成的更深層次的價值觀和原則。快速但狹隘的定義導致了“豎井式思維”。現在你已經知道，敏捷比 Scrum 更重要，而且 DevOps 比持續整合更重要，你已經準備好嘗試強大的敏捷+ DevOps 組合了！
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
本文中文翻譯自原文：Agile and DevOps: Friends or Foes? 編譯者：程景天。