DevOps與敏捷異同 - DZone DevOps

什麼是DevOps？什麼是敏捷？
在我們開始研究DevOps和Agile之間的關係之前，首先要對這些術語的含義有一個共同的理解是很重要的。雖然有許多定義，但它們可以從根本上理解為一套原則，從中可以推匯出工程文化和實踐。
敏捷，其存在時間比DevOps長，可以說是更為成熟，其定義於2001年2月的敏捷宣言中。該宣言規定了以下價值：

• 個人和流程與工具之間的互動
• 透過綜合文件工作軟體
• 合同談判中的客戶協作
• 響應遵循計劃的變更

DevOps專注於持續整合，自動化一切，持續測試和持續交付。

Gardiner說，“DevOps是一種完全圍繞在牆上部署軟體過程中移除孤島的運動或哲學”。這是關於建立一個負責開發，部署和生產程式碼的跨職能團隊。“
雖然沒有單一的定義，但Gene Kim，Kevin Behr和George Spafford在他們的開創性小說“鳳凰計劃 ”中引入了DevOps的“三種方式”的概念。這三種方式是許多DevOps實踐的核心。
Kim後來在DevOps手冊中對這些進行了擴充套件，他與Jez Humble和Patrick Debois合著。
這三種方式包括：

• 系統思考：強調整個系統的效能，而不是特定工作或部門孤島的表現 - 這可以像分工一樣大，也可以像個人貢獻者一樣小。
• 放大反饋迴圈：建立右到左反饋迴圈。幾乎所有過程改進計劃的目標都是縮短和放大反饋迴路，以便不斷進行必要的修正。
• 持續實驗和學習的文化：創造一種培養兩種東西的文化：持續的實驗，冒險和從失敗中學習; 並且理解重複和練習是掌握的先決條件。

歷史
追溯到20世紀90年代，敏捷已存在的時間比DevOps長得多，後者在將近20年後生根。然而，這兩套原則都源於精益製造，其歷史可以追溯到20世紀40年代。難怪我們今天看到這兩者的相似之處。雖然DevOps的流行度持續增長，但Agile已經並且仍然比DevOps更廣為人知。谷歌趨勢表示“敏捷”一詞的搜尋量大約是“DevOps”一詞的三倍。
敏捷的根源可以追溯到20世紀40年代的精益流程，其中包括Kanban，一種視覺化豐田生產系統一部分工作流程的方法。約束理論也是後來發展起來的。然而，敏捷的軟體開發方法在20世紀90年代真正起步，當時一群軟體開發人員對瀑布式開發方法中涉及的高度嚴格的流程感到沮喪。這些通常導致軟體專案花費了數月甚至數年才導致失敗。在20世紀80年代和90年代，建立了幾種迭代軟體開發方法作為瀑布方法的替代方法，包括極限程式設計（XP）和看板。1995年，引入了敏捷開發的Scrum實踐。然後，在2001年Snowbird Mountain Retreat舉行的著名會議上，一群思想領袖齊聚一堂，共同開發敏捷宣言。敏捷在今天持續發展和發展，其中許多不同的變化和實踐都是從最初的宣言（包括現代敏捷）發展而來。雖然敏捷制定了整體原則，但有許多常見的方法來實踐敏捷原則，Scrum和看板是最受歡迎的兩種。
DevOps是一套更新的原則，它源於精益製造中的一些相同概念。“DevOps”一詞於2009年首次推出，當時Patrick Debois在比利時Ghen舉辦了“Devopsdays”活動。這個概念佔據了第一年美國Devopsdays的第一年。2013年，領導人Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰寫了他們的書“鳳凰計劃：關於IT，DevOps和幫助您贏得業務的小說”，  其中提出了許多基礎概念今天組成DevOps。DevOps繼續增長，2014年，我們看到DevOps越來越多地擴充套件到以DevOps企業峰會為標誌的企業環境中。今天，DevOps繼續與敏捷一起成長和發展。

合作文化
敏捷與DevOps之間的核心共性之一是強調建立協作文化。這兩種方法都在尋找打破孤島和增加共同責任的方法。透過打破孤島，DevOps和Agile減少了切換，以提高交付給客戶的速度。敏捷主要關注質量保證的包含，而DevOps則採用這種協作概念並將其擴充套件到運營團隊。
在敏捷中，我們將合作文化視為敏捷宣言的核心原則。第一個是“個人和流程與工具之間的互動”，明顯表示需要共同合作，而不是為交接建立定義的術語或流程。此外，第三個原則“客戶在合同談判中的合作”強調需要將這種合作擴充套件到開發團隊之外以及客戶之外。
敏捷教練Susan McIntosh在她的文章“敏捷心態究竟是什麼？”中強調了敏捷的協作思維方式，他說：“敏捷的心態是支援敏捷工作環境的一系列態度。這些包括尊重，協作，改進和學習週期，所有權的自豪感，專注於提供價值，以及適應變化的能力。這種思維方式對於培養高績效團隊是必要的，這些團隊反過來為他們的客戶帶來了驚人的價值。“
在Agile中實現協作有很多實踐。對程式設計，圍攻和群集等實踐都允許更大的團隊一起開發軟體。它們脫離了發展的概念，作為一個單獨的程式設計師單獨完成的任務。此外，Agile致力於將QA無縫整合到流程中，作為負責每次迭代交付工作程式碼的團隊的一個組成部分。
DevOps的許多基礎概念也是圍繞協作理念構建的。事實上，這個基礎可以追溯到對發展，運營和質量保證分離的反應。認識到這些獨立的孤島引起了相互衝突的利益，增加了交接和價值損失，這是DevOps運動的基礎之一。
Thoughtworks首席科學家Martin Fowler指出，協作在DevOps中扮演著至關重要的角色，“DevOps文化的主要特徵是開發和運營角色之間的協作增加......開發和運營之間應該沒有孤島。切換期和文件不能替代從一開始就在解決方案上合作。調整資源結構有助於操作人員儘早參與團隊。讓開發人員和運營人員在同一地點將幫助他們一起工作。“
在DevOps中可以透過多種方式實現此協作，並將其擴充套件到開發和QA流程之外。構建協作文化的關鍵方法之一是在所有參與向客戶交付價值的團隊之間制定共同目標。透過設計開發，運營和質量保證之間共享的目標，您可以使公司明確目標，並將重點放在客戶需求和最終交付上。
DevOps鼓勵合作的另一種方式是將操作活動整合到sprint中。這可以透過在sprint中包含運營團隊成員來實現，或者甚至更好地確保所有sprint團隊成員共享運營責任。將操作任務作為積壓的一部分包括在內也是有益的。透過這種方式，您可以為與操作應用程式相關的許多工提供共享焦點，這些任務在以功能為中的團隊中經常被忽略。這些操作任務通常被稱為“功能”，可能包括可維護性，可伸縮性和安全性等。透過共同構建和執行應用程式和服務，DevOps推動團隊之間的協作，以提供更安全和穩定的應用程式。
除了提供功能和“功能”之外，高效能DevOps組織的常見做法是為負責維護這些產品的產品提供團隊。一旦系統穩定性得到證實，它就會移交給另一個團隊進行維護。其他公司包括開發團隊，作為操作問題的尋呼機輪換的一部分。這創造了共同的責任，並加強了共同的目標和責任。
最終，DevOps不是一份工作。它不是一個角色，也不是任何一個人或團隊的責任。DevOps的核心是協作，並以這種方式與敏捷宣言中編纂的原則保持一致。

小批次和短週期時間​​​​​​​
小批次和短週期時間是敏捷的關鍵。透過減少對系統的更改大小，Agile可以更快地為客戶創造價值。這種快速部署還允許快速反饋，允許客戶或使用者快速檢視已開發的內容，並允許團隊在必要時快速調整課程。這與瀑布式方法形成鮮明對比，客戶可能需要等待數月甚至數年才能看到可交付成果，然後才能確定它是否是他們想要或需要的。DevOps採用小批次大小的概念，並透過持續整合和持續部署（CI / CD）進行擴充套件。CI / CD提供了一個工具鏈，允許團隊加快價值，讓客戶將週期從幾周甚至幾小時縮短。
小批次是精益的關鍵，它起源於20世紀30年代，為敏捷和DevOps提供了一些核心基礎。精益專注於消除浪費和減少批次大小來實現這一目標。這減少了正在進行的工作量，因此減少了等待下一個處理階段的庫存量。
這一概念在敏捷的核心原則中得到了回應，該原則指出“經常提供工作軟體，從幾周到幾個月，優先考慮更短的時間尺度。”小批次和縮短週期時間有許多好處。小批次，減少佇列，降低交易成本和快速反饋迴圈可以使可變性成為資產而非負債。根據Don Reinertsen的說法，為了使產品開發增加價值，結果將不可避免地存在不確定性。我們不應該儘量減少失敗，而應該接受可變性。我們可以透過有效學習和低效地生成資訊來減少不確定性（透過這樣做，我們最大化結果的可變性）。虛擬技術長Noah Cantor強調了較短反饋迴圈的影響，稱“有” 許多學術研究和行業研究表明，反饋週期越長，人們就越少從中學習。相反的情況也是如此 - 反饋週期越短，人們就越能從中吸取教訓。“
有許多方法可以確保您在Agile中擁有較小的批次大小和較短的週期時間。最基本的方法之一是將使用者故事分成適合迭代的片段。有許多方法可以減少故事大小，如下圖所示。減少故事大小的一個關鍵方法是將功能拆分為單個使用者故事或任務。
切片和拆分使用者故事時，確保不建立與元件相關的團隊非常重要，而是堅持以功能特徵為主的團隊。垂直切片使用者故事而不是水平切片。也就是說，檢視端到端功能而不是應用程式的特定層。
小批次和短週期時間也是DevOps的關鍵。Gene Kim，Jez Humble和Patrick Debois在“DevOps手冊”中花了很多時間。DevOps的第一種方式清楚地說明了這一概念，其重點是從左到右增加產品流量。透過使用精益工具（例如價值流對映），可以識別瓶頸並將其移除以增加對客戶的價值流。
此外，這些較短的迴圈時間是DevOps第二和第三種方式的關鍵。與敏捷一樣，縮短週期時間意味著價值更快地傳遞給客戶，因此團隊可以獲得更快的反饋。這使實驗成為可能，允許團隊快速釋出客戶的功能或變更，並根據反饋快速適應。
在DevOps中縮短週期時間和縮小批次週期的關鍵之一是持續整合（CI）和連續部署（CD）管道。這是CI / CD是DevOps的關鍵元素的原因之一。透過持續整合，不斷對變更進行合併和驗證，從而使整個產品始終具有可交付性。持續部署可確保產品始終處於可部署狀態，從而可隨時將價值交付給客戶。這兩種實踐採用了最初在Scrum和兩週釋出週期等敏捷方法中引入的快速開發和交付，並將其進一步降低到每天甚至每小時。在2009年的Velocity，John Alspaw和Paul Hammond發表了他們的演講，“每天10+部署：Flickr的開發和運營合作” 這啟動了現在嵌入在DevOps中的許多CI / CD概念。如今，Netflix，谷歌，亞馬遜等公司每天都要部署數千次。

使工作可見
可見性是DevOps和Agile中的另一個關鍵因素。對於Scrum和Kanban等敏捷實踐，這通常採用董事會的形式來共享資訊。DevOps利用這些實踐，但也擴充套件它們以共享有關係統在任何給定時間的執行情況的資訊。這可以採用資訊散熱器，大型可見儀表板和共享儀表板的形式。
雖然敏捷宣言沒有規定讓工作可見的必要性，但這些概念的基礎是這些概念的基礎。“宣言”強調“個人與互動”和“客戶合作而不是合同談判”和“響應變革而不是遵循計劃”，所有這三項都透過使工作可見而得到加強。
敏捷開發了“資訊散熱器”的概念，這是位於敏捷開發團隊附近的大型圖表，顯示了整個開發週期的工作進度。Alistair Cockburn在2000年創造了“資訊散熱器”一詞，並在他2001年出版的“ 敏捷軟體開發”一書中介紹了它。
多明尼加·德格蘭迪斯在她的著作“ 讓工作可見：揭露時間盜竊以最佳化工作和流動”中談到了這一點  。她清楚地說明了如何透過使工作可見，我們可以輕鬆識別瓶頸並改善整個系統的工作流程。
Scrum和Kanban的做法利用了公共板來顯示工作進度，這些進度流經一系列步驟，這些步驟被定義為公共板頂部的列。透過為團隊提供視覺化工作的方法，他們使團隊能夠一起工作。這些板還有助於快速識別瓶頸。
這個概念明確地符合Gene Kim的第一個DevOps原則，即啟用流程。DevOps團隊經常使用Scrum和Kanban板來使他們的工作可見。協同工作，開發和操作可以使用這些來確保跟蹤所有工作。此外，透過在敏捷團隊中整合操作和安全實踐，他們可以確保將工作票包含在非功能性工作中。這種非功能性工作可能包括使系統更易於維護，安全或穩定的工作，這些要求經常被功能集中的團隊忽視。
DevOps專注於放大反饋迴路和廣播運營資訊的第二種方式是一種很好的方法。這可以包括Scrum板，但它還可以包括有關係統效能，使用者體驗以及效能基礎的程式碼和基礎架構效能的實時資料。這些散熱器可以包括在整個建築物的戰略位置張貼的大型監視器。
DevOps手冊專門用於遙測的主題。在他們的章節“建立遙測以實現檢視和解決問題”中，他們寫道：“我們的目標是將這些資訊傳播給組織的其他人，確保任何想要了解我們正在執行的任何服務的資訊的人都能得到它......透過快速，易於獲取和充分集中化遙測，價值流中的每個人都可以分享現實的共同觀點。“
Pearson Education是一家專注於線上教育的出版公司，實施了一項名為“Monitors Everywhere”的計劃。在該計劃中，每個團隊都有一個共享監視器，他們的任務是顯示與團隊相關的關鍵資料。這些資料的範圍從程式碼提交頻率到資料庫鎖，以及根據團隊對客戶服務檯的呼叫次數。
Etsy是一家以其DevOps思想領導力而聞名的工藝電子商務公司，在工作可見的空間中也做了大量工作。在他著名的部落格文章“衡量一切，衡量一切”伊恩馬爾帕斯寫道，“如果Etsy的工程學有宗教信仰，那就是圖形教會。如果它移動，我們會跟蹤它。“事實上，當Etsy搬進他們新的環保辦公室時，他們甚至有一個感測器並報告了建築物屋頂雨水蓄水池的水位。這產生了許多好處，並有助於實現Etsy所倡導的持續部署方法。Patrick McDonnell談到了在DevOps手冊中監控部署資料的好處說，“透過這樣做，我們可以更快地看到任何意外的部署副作用。我們甚至開始在辦公室周圍放置電視螢幕，這樣每個人都可以看到我們的服務表現如何。“

持續學習
敏捷和DevOps都在其核心原則中有持續學習，在敏捷中，這個概念是敏捷宣言的一部分，並且在諸如回顧之類的關鍵實踐中很明顯。在DevOps中，它是在諸如無可指責的事件事後死亡之類的實踐中實施的第三種DevOps方式的一部分。
敏捷宣言強調“響應改變而不是遵循計劃”，因此，建立了一個強調適應需要的宗旨。在這種適應中，假設團隊正在反思和改進。隨著敏捷持續的短週期，團隊能夠審查事情的進展情況，並對他們提供的產品及其用於交付產品的流程進行快速調整。此外，“客戶協作超過合同談判”的宣言原則意味著緊密的反饋迴圈，傾聽和從客戶反饋中學習。在Agile中，產品團隊可以快速向客戶提供功能，並快速學習現實反饋和這些功能的使用，以便他們快速調整課程。
DevOps還強調持續學習。DevOps的第三種方式側重於持續學習。在IT革命網站上，Kim寫道，“第三種方式是創造一種培養兩種東西的文化：持續的實驗，冒險和從失敗中學習; 並且理解重複和練習是掌握的先決條件。“
敏捷和DevOps都有實踐，這些實踐編纂了持續學習和不斷實驗的精神。在Scrum中，回顧過程被納入流程中，以確保團隊花時間反思每一次迭代，從錯誤中吸取教訓並慶祝成功。回顧會是團隊反思上一次迭代並尋找改進領域的會議。小組討論什麼進展順利，哪些進展不順利，並列舉需要改進的領域。透過這種方式，回顧性實踐建立了持續學習和持續改進敏捷。
Sprint演示是敏捷過程中持續學習的另一個很好的例子。許多敏捷團隊在每次迭代結束時都會對sprint交付項進行演示。這些允許團隊成員相互學習，更好地瞭解產品的所有部分。Sprint演示還可以加入參與sprint演示的專案利益相關者的快速反饋。這種做法使團隊有機會反思成功，相互學習，並提供建設性的反饋，以繼續發展和學習。
在DevOps中，透過諸如事故後事件等實踐強調了持續實驗和持續學習的原則。John Allspaw幫助啟動了無可指責的事後概念，這是DevOps實踐的一個共同組成部分。在他撰寫的Etsy部落格，Code as Craft的部落格文章中，他寫道，“透過以一種關注失敗機制的情境方面和接近失敗的個人決策過程的方式調查錯誤，組織可以來如果它只是簡單地懲罰所涉及的行為者作為補救措施，那麼通常會更安全。“Allspaw強調，驗屍後最重要的事情不是可以採取的一系列行動，而是組織學習。
在Etsy他們不僅沒有責備事件，他們實際上是在慶祝失敗。慶祝失敗的原因之一是犯錯誤的人實際上是最好的工程師。這些人正在為業務做出最大的改變並推動創新。因此，重要的是不僅要限制責備，而且實際上要將慶祝失敗的文化習慣灌輸為學習的機會。Etsy憑藉他們的三個武裝毛衣獎來做到這一點。由CTO頒發的Etsy alum頒發的著名獎項旨在慶祝今年最大的失敗。透過灌輸諸如無可指責的故事和失敗的慶祝等習慣，DevOps可以鼓勵一種對討論失敗並不斷學習和成長的文化。

嵌入式運維的專業化與“全棧”工程師的興起
在許多方面，將QA嵌入到Agile方法的產品團隊中，與在DevOps中的開發團隊中嵌入運維的需求相似。
在瀑布式中，許多組織分為不同的開發和QA團隊。質量保證和開發團隊也經常受到競爭目標的驅動，質量保證團隊專注於軟體質量，開發團隊專注於功能交付的速度。這種劃分與開發和運營的組織劃分沒有什麼不同。在這些組織中，開發和運營也是由單獨的目標驅動的，運營側重於穩定性，而開發側重於特徵速度。隨著敏捷的發展和成熟，越來越明顯的是QA必須在整個開發過程中參與其中。除此之外，質量需要成為每個人工作的一部分。為了避免冗長的交接和單獨的QA週期，Agile將QA整合到團隊中。同樣，我們現在看到DevOps中的一個動作，即在整個開發生命週期中參與運營團隊或運營思維。
有許多不同的組織結構用於構建跨職能團隊。有些組織不再擁有單獨的QA團隊，而是將QA嵌入到每個團隊的職責範圍內。其他公司在每個團隊中都有專門的QA人員。其他公司擁有一個專門的質量保證團隊，作為標準持票人，確保質量保證實踐和工具在整個組織內保持一致。然而，它是有組織的，需要明確劃分職責，以便將質量保證真正納入每個團隊的交付週期的一部分。
同樣，我們看到運營中的專業化和整個堆疊工程師的崛起正在受到侵蝕。自2012年以來，對全棧工程師的需求一直在穩步增長，這體現在對全棧工程職位的要求越來越高。就像敏捷團隊認識到需要將QA整合到每個人的工作中一樣，我們現在看到越來越需要整合運營。對於小型的敏捷團隊，通常不可能擁有專門的網路工程師，資料庫工程師和儲存工程師，因此解決方案是找到對所有這些元件和應用程式有深入瞭解的人。
將質量保證整合到開發團隊和整合運營之間的相似之處使我們能夠從組織開發和QA團隊中汲取經驗教訓，以實現敏捷交付。最終，目標是透過消除專家團隊並將角色和職責納入主要團隊來減少交接。這導致了“你構建它，你執行它的心態”，你必須將質量和可維護性嵌入到軟體開發和工程中。

關鍵差異
雖然敏捷和DevOps具有重要的一致性，但重要的是要注意它們的重點不同。Agile主要關注應用程式的構建，而DevOps則將這一重點擴充套件到包括構建和運營應用程式。DevOps採用了敏捷的許多概念，並將這些概念擴充套件到構建過程之外並進入生產。正是這個擴充套件定義了真正的差異。
因此，如果存在差異，則主要是關注焦點。Agile Coach的Martin Corbett表示，“敏捷專注於打破工作，以儘快為客戶提供更多價值，而DevOps專注於將程式碼從構建到部署等專案，例如持續部署。”此外， Agile專注於構建工作軟體以及開發和QA之間的協作，而DevOps則專注於開發，QA和運營之間的協作。
雖然許多人都在尋找敏捷與DevOps之間的差異，但實際情況是，這兩種方法具有非常相似的目標和類似的基礎原則，並且最終具有比差異更多的相似性。

DevOps作為敏捷的延伸​​​​​​​
在許多方面，DevOps可以被視為敏捷的延伸，甚至是敏捷的自然演變。在瀑布中，有一個明確的交接（它由流程強制執行）。敏捷作為一個持續的過程，需要一種新的方法，DevOps有助於實現這種方法。
為了實現精益和敏捷最佳實踐的核心小批次釋出，您需要找到一種方法來減少切換並使釋出到生產中變得簡單無縫。出於這種必要性，自然會出現許多DevOps實踐。在DevOps中普及的全棧工程師的概念是這種需求的自然答案。為了減少切換，工程師必須意識到系統的所有部分，以便團隊中的任何成員都能理解和整合QA，安全性和操作要求，而無需交付給其他團隊。同樣，跨職能團隊必須成為常態，以便小型，獨立的團隊可以提供功能齊全的產品，而無需向運營團隊進行額外的交接。
此外，Agile的持續流程需要一定程度的構建和部署自動化。其中大部分都是在DevOps的CI / CD實踐和工具中提供的。CI / CD需要允許快速部署經過全面測試和功能齊全的程式碼給客戶。因此，再次很容易看出CI / CD是敏捷實踐所必需的自然演化。這些實踐繼續發展，使釋出週期時間進一步縮短，從數週到數天甚至數小時。
從另一個角度考慮這個問題，如果你有一個兩週的QA週期，只有在開發完成後才能開始，那麼在一週或兩週內完成程式碼是非常困難的。同樣，如果您需要等待一週的時間來獲取變更批准和釋出資源，或者在更糟糕的情況下等待數月的硬體購買和安裝，則很難在一兩週內將程式碼排除在門外。如果你有很多切換，那麼很難成為敏捷。如果你有一個漫長而繁瑣的變更管理流程，那麼很難成為敏捷。如果你有一個漫長的繁瑣的釋放過程，那麼很難成為敏捷。你怎麼能做兩週的迭代並有兩個月的釋出過程？對此的明顯答案是DevOps。
這並不是說沒有DevOps就無法實現敏捷。敏捷在DevOps之前很久就存在，並且肯定有敏捷團隊不遵循許多DevOps實踐。正如Noah Cantor所說，“你可以互相做敏捷實踐和DevOps實踐。你不能做的是採用敏捷原則或DevOps原則，因為它們太相似而不能分開。“並不是說它們是不可分割的，只是敏捷是一個自然的前身並激發對DevOps的影響。

結論
精益一直是DevOps的核心，就像敏捷從精益生長出來一樣，DevOps也是如此，所以這兩者有很大的共同點並不奇怪。在2015年的DevOps狀態中，作者表示，“當您將精益管理實踐應用於技術時 - 限制在製品（WIP）; 引入視覺顯示以監控質量，生產力和WIP; 並使用監控資料來幫助決策 - 您可以獲得結果。文化變得更具生成性和績效導向; 人們在工作場所的壓力減輕; 並且IT效能得到改善。“ 
DevOps採用Agile中建立的概念，並將其擴充套件到程式碼部署之外。DevOps採用這些概念並將其應用於應用程式和服務的管理。透過利用敏捷原則，DevOps可以擴大它們，增加使用Agile的組織已經認識到的好處。
並不是說為DevOps做DevOps，或者因為你正在做敏捷而做DevOps。已經證明DevOps實現可以產生結果。2017年DevOps狀態報告顯示，高效能DevOps團隊的部署速度提高了46倍，交付時間縮短了44倍，更改失敗率降低了5倍，平均恢復時間縮短了96倍（MTTR）。在具有成熟DevOps實踐的組織中，這些數字被低估了。
當我們檢視Agile和DevOps重疊的每個區域時，DevOps放大了敏捷實踐，我們希望您可以採取一些具體步驟來推動您的組織發展。構建協作的最關鍵步驟之一是共同目標的制定。透過共享目標，您可以確保開發，運營，質量保證都一致並朝著同一目標努力。
小批次規模為推動DevOps實踐加速組織提供了另一個絕佳機會。在Scrum或Kanban等流程中，我們希望將操作任務和操作思想整合到您的工作中。如果您正在使用Scrum，您可能還希望轉移到Kanban，這可以更容易地適應操作流程。
無論您使用哪種方法進行小批次交付，您都可能希望確保使用相同的系統來跟蹤整個團隊的工作。透過統一跟蹤系統，您可以確保不建立積壓工作，並且確實反映了所有計劃內和計劃外工作。這還可以讓您更輕鬆地使您的工作可見。作為敏捷的一個關鍵原則，我們可以擴充套件使工作可見的概念，以顯示操作工作以及系統操作和支援結構的工作。透過實施資訊散熱器以跨團隊分享這些資訊，組織可以大踏步前進。
當您著眼於構建更具協作性的文化時，您還可以確保在不斷學習和實驗的過程中灌輸最佳實踐。有一些優秀的開源工具，如Chaos Monkey，可以幫助您插入錯誤，以便您可以強制失敗，從中學習，並構建更具彈性的系統。作為其中的一部分，您還必須確保建立一種文化，將每一次失敗都視為組織學習的機會。在你的文化中建立儀式，例如無可指責的事後訓練，駭客馬拉松和失敗獎勵，可以成為灌輸學習和實驗文化的好方法。
我們在本文中討論的重疊有組織含義。在DevOps中將敏捷和操作中包含QA意味著我們必須開始構建跨職能團隊並培養具有廣泛知識的人員。這種重疊隨著“全棧工程師”的概念而發展。雖然每個人都知道一切的想法可能不太現實，但我們當然可以努力確保團隊中的每個人都分擔了涉及質量和操作的責任和目標，如果他們對這些事情負責，也在學習。
有許多方法可以採用敏捷原則並使用DevOps擴充套件它們，但最重要的一個方法是組織文化的一致性。如果團隊從根本上不符合目標，那麼在Agile中編寫的團隊方法將無法擴充套件到部署到運營之外。實現這一目標的最佳方法之一是確保目標和目標的一致性。如果所有技術交付團隊都遵循相同的願景，目標和目標，您將立即開始打破這些組織之間的孤島。如果我們可以透過敏捷開始打破組織孤島並透過DevOps擴充套件這項工作，我們將採取措施確保我們擁有真正高績效的組織。