敏捷與 DevOps：是敵是友？

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? 編譯者：程景天。