DevOps是敏捷在軟件開發團隊的另外一應用。那麼相比之下，哪一個更勝一籌？編程
一邊，有業界承認的scrum master，它的朋友極限編程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。安全
另外一邊，有精益文化機器，用代碼持續交付其基礎架構，它的名字左邊是開發，右邊是運維，合起來就是DevOps。markdown
雖然我已盡我所能在普及這兩個概念，但人們關於敏捷和DevOps的爭論依然讓它們聽起來徹底不一樣。更糟糕的是，儘管他們都已經有了各自的行業術語和口號，但二者的概念仍是沒辦法準肯定義。鑑於敏捷誕生早於DevOps ，因此它的定義也相對清晰一些，但DevOps五花八門的定義仍然讓不少人都很困惑。而正是由於兩者都缺少準確的定義，因此致使人們常常會有一些誤解。架構
不少人認爲敏捷等於scrum，DevOps等於持續交付。過分簡化的理解讓敏捷和DevOps之間造成了沒必要要的對峙，但最終你會驚訝地發現兩者實際上是很是好的朋友！運維
毫無疑問DevOps和敏捷之間的聯繫由來已久。在2008敏捷大會上，Patrick DuBois和Andrew Clay Schafer嘗試創建兩者之間的關係並提出「敏捷架構」這一律念，這時，敏捷與DevOps之間的關係就已初現端倪。儘管Patrick後來提出了「DevOps」一詞，但敏捷大會依然被追溯爲DevOps的起點。因此咱們不妨透過Scrum和持續交付的表面，深刻了解兩者的歷史，來思考一下敏捷和DevOps之間還存在哪些關聯。工具
1、敏捷毫不僅僅是Scrum
某些團隊中，scrum讓團隊工做介於一成不變、苦苦掙扎和量產、高回報之間。還有一些團隊，scrum用客觀和聚焦代替主觀和過分承諾。咱們也能夠把它視爲一種教條。當業務收到限制或工做自己須要作出改變的時候，敏捷團隊將利用scrum的基本原則，審視自身的工做並作出更有效的調整。尤爲是當scrum應用於軟件開發環境以外的業務時，這點尤其重要。性能
提早規劃計劃外的工做
在DevOps社區，有敏捷經驗的人都以爲scrum可以有效追蹤計劃中的工做。一些正在運行中的工做能夠被計劃：如發佈一個重大系統變動、切換數據中心或系統升級等。但在運行中大多數事情是沒辦法計劃的：如性能到達峯值、系統中斷或安全問題等。這些突發事件都須要快速作出反應。沒時間等到把這些事項在backlog中肯定優先級後再作或放到下個sprint規劃會議中處理。正因如此，不少團隊開始慢慢接受DevOps思想，Scrum以外再引入Kanban。這樣使得團隊能夠同時追蹤兩種類型的工做，幫助他們理解二者之間的聯繫。或者，他們採起了一種綜合方法，叫作Scrumban 或 Kanplan （也就是有backlog的看板）。學習
在很大程度上，scrum得以普遍應用的關鍵可能在於它不對技術方法設限。Scrum做爲輕量級管理方法，每每能爲團隊帶來巨大變化。以前，可能會有來自多個master的優先事項互相競爭，但在scrum中，backlog中只會存在一組優先事項。以前，團隊中可能會存在同時推動不少工做的狀況，而如今取而代之的是一個在限定時間內能夠完成的工做計劃。綜合來看，這些均可以將團隊的生產率帶到一個新的水平。然而，團隊可能會因技術實踐的缺少而受到限制，如代碼審查、自動化驗收測試、持續集成。測試
其餘敏捷方法如極限編程，也對技術如何使團隊保持可持續交付節奏並向管理層和利益相關者提供透明度和可見性提出了明確要求。一些Scrum團隊傾向於將研發任務放在backlog中。雖然這在scrum的指導下適應得很好，但很快就會遇到Product Owner對產品功能的偏向性問題。除非Product Owner的技術能力很強，不然TA可能沒法評估技術的成本或收益。尤爲是當技術任務延伸到運維、可靠性支持、性能、安全性等方面時，對Product Owner來講更加困難。設計
Product Owner 和Service Owner
在Worktile，咱們認識到，爲咱們運營的產品設置兩個不一樣角色頗有必要。Product Owner善於理解用戶的功能性需求，但可能並不擅長權衡產品功能與性能、可靠性和安全性等非功能性功能之間的優先級。所以，一些SaaS產品也配備了Service Owner角色，負責肯定前述非功能性功能的優先級。儘管兩個角色常常須要討價還價，但大部分狀況下，獨立的團隊均可以自行完成這兩個角色的任務。雖然這並非「強化反饋」的惟一方法，但確實可以克服Product Owner對產品功能中比較常見的偏見問題。但設置‘兩個Owner’並不是實現DevOps的惟一途徑。重要的是將非功能性特徵理解爲「功能」，並將它們像功能性的用戶故事同樣，進行規劃和優先級排序。
在DevOps成爲主流前，不能肯定scrum天然發展的結果必定是DevOps。
敏捷方法中，Scrum有一個內在的「過程改進」機制，叫作回顧會議。所以，咱們有理由相信一些scrum團隊會想用DevOps做爲靈感來源，用scrum回顧會議做爲向DevOps方向調整的契機。然而，事實讓咱們意識到大多數團隊須要注入外部思想。在DevOps成爲主流前（哪怕成爲學校必學內容），咱們不能肯定scrum天然發展的結果必定是DevOps。團隊究竟是有敏捷教練仍是DevOps教練參與並不重要，只要他能給團隊帶來在構建、測試、部署等方面的自動化經驗便可。
2、DevOps也不只限於持續交付
若是應用得當，持續交付的規則能夠有效限制在製品數量，而部署的自動化有助於打破工做侷限。經過這樣的方式，持續交付讓軟件開發團隊頻繁交付更高質量的產品，而沒必要在兩者之間抉擇。然而，正如僅專一於scrum的團隊可能會忽視更普遍的敏捷環境那樣，僅專一於持續交付的團隊也會錯過更普遍的DevOps環境。
持續交付實踐並不能直接解決業務部門和開發團隊之間的溝通問題。若是業務部門設定了一個爲期一年的預算驅動計劃，那麼產品交付團隊每次交付產品後都須要等待數月才能獲得業務部門給的反饋。而這些反饋一般都是一些影響後續工做的步驟性功能，像取消項目或者更糟糕的是須要擴充項目團隊（由於大量涌入新人會影響團隊已有的穩定性）。
敏捷流暢度模型將「價值聚焦」視爲流暢度的第一層級，即團隊須要注重透明度和一致性。若是價值不聚焦，持續交付很容易陷入技術改進的無限死循環而沒法向業務交付可觀的價值。團隊可能擅長快速高質量的交付，但就產品自己而言，可能對終端用戶或者企業來講幾乎沒有價值。即便不少用戶給出了較好的評價，但從較大的業務組合層面來看可能就會評估爲低價值。所以，沒有價值聚焦這一重要流暢度，團隊很難在技術和功能之間權衡取捨。
這點對於有遺留代碼庫的團隊來講尤其重要，由於遺留代碼庫可能沒有自動化測試或適合頻繁部署的設計。在一個遺留環境中，持續交付轉換可能須要數年的時間。所以，證實產品的商業價值就顯得尤其重要。
三種方法
DevOps不只僅是自動化部署流水線。換句話說，DevOps方法要求「運維人員（Ops）可以像開發人員（Devs）那樣思考，而開發人員（Devs）也要像運維人員（Ops）那樣思考。」 如下是這一觀點的進一步闡述以及可做爲DevOps原則的三種方法：
第一種：系統思惟
強調整個系統的性能，而不是特定的工做孤島或部門的性能——這個系統能夠大到涵蓋整個業務部門，小到僅包括單個工做項。
第二種：擴大反饋循環
建立全流程的反饋循環。幾乎全部過程改進計劃的目的都是爲了縮短並強化反饋循環，以確保能夠不斷進行必要的修正。
第三種：不斷實踐和學習的文化
塑造一種聚焦在這兩件事上的文化：不斷實踐、敢於冒險並從失敗中學習經驗；要明白重複和實踐是熟練掌握的先決條件。
持續交付側重於第一種方法： 即實現從開發到運維的自動化流程。自動化在加快系統部署上的做用很是明顯，但系統思惟毫不止於自動化。
第二種方法的突出特色是實踐， 即「開發人員也要隨身攜帶傳呼機」。雖然開發人員不必定真的要隨身攜帶傳呼機作到隨叫隨到，但他們也須要積極參與到運維工做中。這樣能讓開發人員瞭解到他們開發過程當中所作選擇帶來的後續影響。例如，這樣作能讓開發人員將本身的日誌消息存放到更好的位置讓它們發揮更大的做用。開發人員不只僅要了解運維工做，還要結合本身對系統的理解作一些故障排除的工做，這樣能夠更快地找到並實施解決方案。
第三種方法強調在整個系統中進行增量實驗，而不只僅是應用程序在流水線中移動的變化。 換句話說，看出自動化所需的時間並用日益強大的基礎設施來不斷改進它相對來講是比較容易的。而要清楚的知道角色或企業之間的交接如何致使延期是比較困難的。這意味着團隊要「檢查和調整」整個交付工做流，尋找能夠提高人員協做效率的點。對於這個問題，持續交付要求團隊養成不斷適應和改進的習慣。若是團隊歷來不去思考如何變得更高效，並付諸行動去調整和改善，那麼持續交付也沒法持續發展和完善。團隊要相信本身有能力解決本身的問題。
在scrum中，每次回顧會議都是一次改進實踐和工具的機會。但若是團隊沒有抓住這些機會解決短時間和長期的技術問題，他們就無異於坐等Product Owner將持續交付任務放到他們的backlog中，而事實上，Product Owner永遠不會這麼作。
DevOps是敏捷在軟件開發團隊以外的應用
Scrum主要遵循「欣然面對需求變化，哪怕變動出如今開發後期。敏捷過程正是利用變化來幫助客戶取得競爭優點」這一敏捷原則。
而持續交付遵循的敏捷原則是：「咱們的首要任務是經過儘早、持續地交付有價值的軟件，來知足客戶的需求」。
這意味着敏捷更強調輸入和輸出的變化，而不是每日站會和sprint規劃會等儀式。事實上，《敏捷宣言》中還有另外10條原則。咱們應該將它們視爲一個總體，而不是從中選擇某些原則。由於這些原則合起來表明的是敏捷和DevOps對變動的態度。
DevOps旨在將敏捷關於變動的態度應用到新的領域：IT運維。
這些人一直在運行對於企業來講很是重要但同時又很是脆弱的系統。也正是由於它的重要性，因此也最迫切須要得以改進。所以，這裏敏捷強調的變化並非「爲了改變而改變」。是爲了讓開發對其變動質量負責，同時提升總體交付商業價值。而這種對商業價值的關注是敏捷和DevOps的另外一個共通點。
最後，敏捷和DevOps自己並非業務指標。它們都是能夠激勵組織用更好的方法實現目標的企業文化。將敏捷和DevOps結合起來使用能取得更好的效果。而避免這兩種文化發生衝突的訣竅就是要理解構成它們的更深層次的價值觀和原則。武斷而狹隘的定義會禁錮思惟。相信看完本文，你已經知道敏捷不只限於scrum，而DevOps也不只限於持續交付。那麼接下來，你就能夠嘗試強大的Agile + DevOps組合了。
文章來源：Worktile敏捷博客