敏捷與 DevOps：是敵是友？

DevOps 是敏捷應(yīng)用于軟件團(tuán)隊(duì)的成果。但真正的問題是，在一場比賽中，哪一方會獲勝？

在角斗場的一頭，我們有經(jīng)過認(rèn)證的敏捷教練，他的朋友們都知道他是一個(gè)極限程序員，而在他的孩子們眼里則是不那么安全的父親。他就是＂敏捷＂！

而在另一頭，我們有一個(gè)精益文化機(jī)器，他不斷地將他的架構(gòu)以代碼形式傳遞出來，他的左臂就是開發(fā)，他的右臂是就運(yùn)維。他就是＂DevOps＂ !

盡管我已經(jīng)把雙方都視為已經(jīng)被炒作得天花亂墜的概念，但關(guān)于敏捷和 DevOps 的聲音讓它們聽起來像是非常不同的想法。更復(fù)雜的是，即使兩個(gè)概念有自己的行話和口號，但它們的定義依然含糊不清。作為歷史更悠久的一方，敏捷可能不那么模糊，但人們對 DevOps 的眾多定義感到迷茫無助是很常見的。缺乏精準(zhǔn)的定義導(dǎo)致了他們之間產(chǎn)生一些共同關(guān)聯(lián)點(diǎn)。

許多人認(rèn)為敏捷意味著 Scrum，DevOps 意味著持續(xù)交付。這種過度簡化在敏捷和 DevOps 之間造成了不必要的緊張局勢，所以當(dāng)你發(fā)現(xiàn)他們是最佳拍檔時(shí)，你會感到驚訝無比！

不可否認(rèn)，DevOps 與敏捷之間的歷史是有千絲萬縷的聯(lián)系。當(dāng) Patrick DuBois 和 Andrew Clay Schafer 試圖在 Agile 2008 大會上討論“敏捷架構(gòu)”時(shí)，與 DevOps 的聯(lián)系就誕生了。盡管 Patrick 后來才創(chuàng)造了“DevOps”這個(gè)詞，但在 DevOps 的發(fā)展歷程中仍然用敏捷大會來紀(jì)念這一起點(diǎn)。當(dāng)我們深入到 Scrum 和持續(xù)交付的表面之下時(shí)，我們深入研究一下歷史，就會發(fā)現(xiàn)敏捷和 DevOps 之間的實(shí)際聯(lián)系。

「CODING 企業(yè)版」作為企業(yè)級軟件研發(fā)管理系統(tǒng)，助力團(tuán)隊(duì)敏捷開發(fā)轉(zhuǎn)型升級。

敏捷不僅僅是 Scrum

在一些團(tuán)隊(duì)中，Scrum 是兩種協(xié)作之間的區(qū)別，一種是持續(xù)令人沮喪的斗爭，另一種富有成效、回報(bào)頗豐。在另一些情況下，Scrum 以客觀和專注取代了辦公室政治和過度承諾，它也可以視為信條教理。當(dāng)由于業(yè)務(wù)或工作本身的約束要尋求變化或者做出改變時(shí)，敏捷團(tuán)隊(duì)將祭出 Scrum 基本原則的利劍，檢查他們的實(shí)踐行為，以逐漸變得更加高效。當(dāng) Scrum 應(yīng)用于軟件開發(fā)的環(huán)境之外時(shí)，這一點(diǎn)尤為重要。

預(yù)先對計(jì)劃以外的工作做規(guī)劃

在 DevOps 社區(qū)中，那些有敏捷經(jīng)驗(yàn)的人同意 Scrum 對于跟蹤計(jì)劃中的工作是有用的。一些運(yùn)維中的工作可以被計(jì)劃：比如發(fā)布一個(gè)大的系統(tǒng)變更，在數(shù)據(jù)中心之間遷移，或者執(zhí)行系統(tǒng)升級。但是大部分的運(yùn)維工作都是無法計(jì)劃的：性能達(dá)到峰值上線、系統(tǒng)中斷和安全問題。這些事件需要立即做出反應(yīng)，沒有時(shí)間等待其加入待辦事項(xiàng)列表再按優(yōu)先級排列，也不可能在下一個(gè)沖刺周期中再列入計(jì)劃。出于這個(gè)原因，許多已經(jīng)開始擁抱 DevOps 思想的團(tuán)隊(duì)，從 Scrum 跳躍到了“看板”。這有助于他們跟蹤這兩種工作，并幫助他們理解之間的相互作用。另一種方法是采用一種混合方法，通常稱為 Scrumban 或 Kanplan（帶有計(jì)劃的看板）。

在許多方面，Scrum 被廣泛采用的關(guān)鍵點(diǎn)可能是它沒有預(yù)先設(shè)定任何技術(shù)實(shí)踐。Scrum 的輕量級管理實(shí)踐常常對團(tuán)隊(duì)產(chǎn)生很大的影響。在過去，多個(gè)管理者會提出不同高優(yōu)先級的事項(xiàng)，在現(xiàn)在，只有一組定好了優(yōu)先級的待辦事項(xiàng)。過去有太多的工作同時(shí)在進(jìn)行中，現(xiàn)在都按一個(gè)被時(shí)間約束、被討論驗(yàn)證過的計(jì)劃來執(zhí)行。綜合起來，這可以讓一個(gè)團(tuán)隊(duì)達(dá)到新的生產(chǎn)力水平。然而，團(tuán)隊(duì)可能會發(fā)現(xiàn)自己受到缺乏技術(shù)實(shí)踐的限制，比如代碼評審、自動驗(yàn)收測試和持續(xù)集成。

其他像極限編程（Extreme Programming）這樣的敏捷過程，對于技術(shù)實(shí)踐如何支持團(tuán)隊(duì)保持速度、并為管理人員和利益相關(guān)者提供透明度和可見性，有很有力的觀點(diǎn)。一些 Scrum 團(tuán)隊(duì)將技術(shù)任務(wù)放在待辦事項(xiàng)列表中，雖然這很符合 Scrum 的指導(dǎo)原則，但它很快就遇到了實(shí)際問題——產(chǎn)品負(fù)責(zé)人對功能特性的偏見。除非產(chǎn)品負(fù)責(zé)人非常懂技術(shù)，否則她或他可能沒有能力評估技術(shù)實(shí)踐的性價(jià)比(成本/效益)。當(dāng)技術(shù)任務(wù)延伸到運(yùn)維工作以支持可靠性、性能和安全性時(shí)，對于產(chǎn)品負(fù)責(zé)人來說，這就變得更加困難了。

「CODING 企業(yè)版」作為企業(yè)級軟件研發(fā)管理系統(tǒng)，任務(wù)看板功能實(shí)現(xiàn)了 Epic ?user stories ?Sprint 等敏捷概念落地。

產(chǎn)品負(fù)責(zé)人和服務(wù)負(fù)責(zé)人

在 Atlassian，我們已經(jīng)認(rèn)識到在產(chǎn)品中有兩個(gè)不同的角色是有幫助的。我們的產(chǎn)品負(fù)責(zé)人很擅長理解用戶需要的特性，但是他們不太擅長將這些特性與性能、可靠性和安全性等非業(yè)務(wù)性功能進(jìn)行權(quán)衡。因此，Atlassian 的一些 SaaS 產(chǎn)品也有相應(yīng)的服務(wù)負(fù)責(zé)人，負(fù)責(zé)對這些非業(yè)務(wù)性功能進(jìn)行優(yōu)先級排序。從時(shí)間上看，這兩個(gè)負(fù)責(zé)人可能不得不進(jìn)行一些“激烈的討價(jià)還價(jià)”，但大多數(shù)情況下，這些都可以由獨(dú)立的團(tuán)隊(duì)來完成。這可能不是從運(yùn)維工作中“放大反饋”的唯一方法，但它確實(shí)有助于克服產(chǎn)品負(fù)責(zé)人對功能特性的普遍偏見。這種“兩個(gè)負(fù)責(zé)人”的方法并不是唯一的 DevOps 方法，重要的是要理解這些作為“特性”的非業(yè)務(wù)性功能，并且能夠像任何其他功能一樣對它們進(jìn)行計(jì)劃和排序。

在 DevOps 成為主流之前，它不會是 Scrum 的自然結(jié)果。

最終，這些對 Scrum 的批評都不是 Scrum 本身固有的。與所有敏捷方法一樣，Scrum 有一個(gè)內(nèi)置的“過程改進(jìn)”機(jī)制，稱為回顧。因此我們有理由相信，一些 Scrum 團(tuán)隊(duì)將利用 DevOps 作為靈感的來源，并將 Scrum 回顧對 DevOps 進(jìn)行調(diào)整。然而，要意識到大多數(shù)團(tuán)隊(duì)需要外部力量來推進(jìn)，這是很實(shí)際的。直到 DevOps 成為主流（甚至在學(xué)校里開始教過）之前，DevOps 也不會是 Scrum 的自然結(jié)果。無論團(tuán)隊(duì)引入的是敏捷教練還是 DevOps 教練，這都可能是無關(guān)緊要的，只要這個(gè)人能夠在構(gòu)建、測試和部署軟件的過程中帶來自動化的經(jīng)驗(yàn)。

DevOps 不僅僅是持續(xù)交付

如果執(zhí)行得好，持續(xù)交付（CD）的規(guī)程有助于規(guī)范正在進(jìn)行中的工作，而部署的自動化有助于提高約束。通過這種方式，持續(xù)交付可以幫助軟件團(tuán)隊(duì)更頻繁地交付，并保證更高的質(zhì)量，而不是在兩者之間做出妥協(xié)。然而，就像團(tuán)隊(duì)只關(guān)注 Scrum 一樣，可能會錯(cuò)過敏捷更廣泛的環(huán)境，所以專注于持續(xù)交付的團(tuán)隊(duì)也會錯(cuò)過 DevOps 更廣泛的背景。

持續(xù)交付的實(shí)踐并不能直接解決業(yè)務(wù)和軟件團(tuán)隊(duì)之間的溝通問題。如果業(yè)務(wù)團(tuán)隊(duì)有一年時(shí)間的計(jì)劃周期，那么軟件團(tuán)隊(duì)將每個(gè)代碼提交上線可能還需要等待幾個(gè)月才能得到反饋。通常這些反饋都是作為下一步的指示，比如取消項(xiàng)目，或者困擾項(xiàng)目團(tuán)隊(duì)的其他麻煩（通常大量新用戶的涌入對性能是破壞性的）。

敏捷流暢度模型表明，第一級的流暢性是“專注于價(jià)值”，而團(tuán)隊(duì)關(guān)注的是透明度和一致性。如果沒有這種流暢性，持續(xù)交付可能很容易地發(fā)展成一個(gè)無窮無盡的技術(shù)改進(jìn)循環(huán)，對業(yè)務(wù)沒有任何價(jià)值。一個(gè)團(tuán)隊(duì)可能擅長于以高質(zhì)量的速度交付，但是對于最終用戶或業(yè)務(wù)來說這可能是一個(gè)價(jià)值較低的產(chǎn)品。即使有許多用戶說了這是好東西，但在更大的業(yè)務(wù)組合級別上，可能對這個(gè)產(chǎn)品的評估是低價(jià)值的。如果沒有這種重要的流暢性，就很難衡量技術(shù)實(shí)踐與功能特性的關(guān)系。對于具有遺留代碼庫的團(tuán)隊(duì)來說，這一點(diǎn)尤其重要，因?yàn)樗赡軟]有自動化測試或適合頻繁部署的設(shè)計(jì)。在遺留的環(huán)境中，持續(xù)交付轉(zhuǎn)換可能需要數(shù)年時(shí)間。因此，能夠證明商業(yè)利益是非常重要的。

三種方法

DevOps 不僅僅是自動化部署流水線。用 John Allspaw 的話說，DevOps 關(guān)乎“像開發(fā)者一樣思考的運(yùn)維，像運(yùn)維一樣思考的開發(fā)者”。在詳細(xì)闡述這一思想時(shí)，Gene Kim 介紹了作為 DevOps 原則的三種方法：

第一種方法：系統(tǒng)性思維 —— 強(qiáng)調(diào)整個(gè)系統(tǒng)的性能，而不是一個(gè)特定的工作或部門的性能。這個(gè)系統(tǒng)它可以像一個(gè)部門一樣大，也可以像單個(gè)貢獻(xiàn)者一樣小。
第二種方法：反饋放大回路 —— 創(chuàng)建從右往左的反饋循環(huán)。幾乎任何過程改進(jìn)計(jì)劃的目標(biāo)都是縮短和放大反饋循環(huán)，這樣就可以不斷地進(jìn)行必要的修正。
第三種方法：持續(xù)試驗(yàn)和學(xué)習(xí)的文化 —— 創(chuàng)造培養(yǎng)兩種東西的文化：不斷地試驗(yàn)、冒險(xiǎn)以及從失敗中學(xué)習(xí)；理解重復(fù)和練習(xí)是掌握的先決條件。

持續(xù)交付（CD）關(guān)注的是第一個(gè)方法：將從開發(fā)到運(yùn)維的流程自動化。自動化在幫助加速部署系統(tǒng)方面起著明顯的作用。但是，系統(tǒng)思考不僅僅是自動化。
第二種方法的特點(diǎn)是，開發(fā)者也要戴著尋呼機(jī)。 盡管使用尋呼機(jī)這樣的描述可能是不必要的，但這意味著將開發(fā)人員拖入運(yùn)維工作。這有助于開發(fā)人員了解他們的開發(fā)選擇的后果。例如，這可以激勵(lì)開發(fā)人員把日志信息放在更好的地方，并使這些消息更有意義。這不僅僅是關(guān)于意識的問題。開發(fā)人員還將他們對系統(tǒng)的內(nèi)部理解引入故障排除工作，因此可以更快地找到問題并提出解決方案。
第三種方法是在整個(gè)系統(tǒng)中進(jìn)行增量式的試驗(yàn)，而不僅僅是應(yīng)用程序在流水線中移動的變化。 換句話說，自動化相對容易看出需要多長時(shí)間，并使用日益強(qiáng)大的基礎(chǔ)設(shè)施來不斷改進(jìn)它。比較難理解的是角色或組織之間的交接是如何導(dǎo)致延遲的。這意味著團(tuán)隊(duì)在整個(gè)交付工作流程中進(jìn)行“檢查和適應(yīng)”，尋找改善人與人之間協(xié)作的機(jī)會。就此而言，持續(xù)集成需要保持適應(yīng)和改進(jìn)的習(xí)慣。如果團(tuán)隊(duì)沒有思考如何變得更有效率，并在任何事情上積極適應(yīng)和調(diào)整它的行為，那么持續(xù)集成也不會成長和繁榮。團(tuán)隊(duì)需要有能力解決自己的問題。

在 Scrum 中，每個(gè)回顧都是一個(gè)改進(jìn)實(shí)踐和工具的機(jī)會。但是，如果團(tuán)隊(duì)沒有利用這些機(jī)會來解決短期和長期的技術(shù)問題，那么他們就會等待產(chǎn)品負(fù)責(zé)人把持續(xù)集成任務(wù)放到待辦事項(xiàng)列表中，這是永遠(yuǎn)不會發(fā)生的。

「CODING 企業(yè)版」作為企業(yè)級軟件研發(fā)管理系統(tǒng)，助力團(tuán)隊(duì)敏捷開發(fā)轉(zhuǎn)型升級。

DevOps 是敏捷應(yīng)用于軟件團(tuán)隊(duì)之外的成果

Scrum 主要映射到的敏捷原則是，“歡迎不斷變化的需求，甚至于在開發(fā)后期。敏捷過程利用變化來保證對于客戶的競爭優(yōu)勢。”

持續(xù)交付主要映射到的敏捷原則是，“我們的首要任務(wù)是通過早期和持續(xù)交付有價(jià)值的軟件來滿足客戶。”

這意味著敏捷更多的是擁抱即將到來的以及外部的變化，而不是像在會議站著或沖刺周期計(jì)劃這樣的儀式。實(shí)際上，敏捷宣言中還有其他 10 個(gè)原則。與其試圖在這些原則中做出選擇，不如把它們視為一個(gè)整體。這些原則共同代表了一種對敏捷和 DevOps 的態(tài)度：改變是很常見的。

DevOps 試圖將它作為敏捷的態(tài)度傳遞給新的受眾：IT 運(yùn)維。

這些人一直在試圖保脆弱系統(tǒng)的運(yùn)行，而這些系統(tǒng)對企業(yè)來說也是最重要的。因?yàn)樗鼈儗ζ髽I(yè)來說是最重要的，所以它們也是最迫切需要改變的地方。因此，這種擁抱變化的敏捷理念并不是“為了改變而改變”。它關(guān)乎讓開發(fā)對其變更的質(zhì)量負(fù)責(zé)，同時(shí)提高交付業(yè)務(wù)價(jià)值的整體能力。這種對業(yè)務(wù)價(jià)值的關(guān)注是敏捷和 DevOps 相通的另一個(gè)方面。

最后，無論是敏捷還是 DevOps 都不是他們自己的商業(yè)目標(biāo)。兩者都是文化運(yùn)動，都是用更好的方式來激勵(lì)你的組織，以實(shí)現(xiàn)你的目標(biāo)。敏捷和 DevOps 在組合中比對手更有效。避免這兩種想法之間的沖突的訣竅是理解它們所形成的更深層次的價(jià)值觀和原則。快速但狹隘的定義導(dǎo)致了“豎井式思維”。現(xiàn)在你已經(jīng)知道，敏捷比 Scrum 更重要，而且 DevOps 比持續(xù)集成更重要，你已經(jīng)準(zhǔn)備好嘗試強(qiáng)大的敏捷+ DevOps 組合了！

「CODING 企業(yè)版」作為企業(yè)級軟件研發(fā)管理系統(tǒng)，助力團(tuán)隊(duì)敏捷開發(fā)轉(zhuǎn)型升級。

本文中文翻譯自原文：Agile and DevOps: Friends or Foes?
編譯者：程景天。

轉(zhuǎn)載于:https://www.cnblogs.com/chengjingtian/p/9682078.html

總結(jié)

以上是生活随笔為你收集整理的敏捷与 DevOps：是敌是友？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。