devops是敏捷在軟體開發團隊的另一應用。那麼相比之下，哪個更勝一籌？
一邊，有業界認可的scrum master，它的朋友極限程式設計者，以及由其衍生的 less、safe、dad等，是敏捷。
另一邊，有精益文化機器，用**持續交付其基礎架構，它的名字左邊是開發，右邊是運維，合起來就是devops。
雖然我已盡我所能在普及這兩個概念，但人們關於敏捷和devops的爭論依然讓它們聽起來完全不同。更糟糕的是，儘管他們都已經有了各自的行業術語和口號，但兩者的概念還是沒辦法準確定義。鑑於敏捷誕生早於devops ，所以它的定義也相對清晰一些，但devops五花八門的定義仍然讓很多人都很困惑。而正是因為二者都缺乏準確的定義，所以導致人們經常會有一些誤解。
很多人認為敏捷等於scrum，devops等於持續交付。過度簡化的理解讓敏捷和devops之間形成了不必要的對峙，但最終你會驚訝地發現二者其實是非常好的朋友！毫無疑問devops和敏捷之間的聯絡由來已久。在2008敏捷大會上，patrick dubois和andrew clay schafer嘗試建立二者之間的關係並提出「敏捷架構」這一概念，這時，敏捷與devops之間的關係就已初現端倪。儘管patrick後來提出了「devops」一詞，但敏捷大會依然被追溯為devops的起點。所以我們不妨透過scrum和持續交付的表面，深入了解二者的歷史，來思考一下敏捷和devops之間還存在哪些關聯。
某些團隊中，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教練參與並不重要，只要他能給團隊帶來在構建、測試、部署等方面的自動化經驗即可。
如果應用得當，持續交付的規則可以有效限制在製品數量，而部署的自動化有助於打破工作侷限。通過這樣的方式，持續交付讓軟體開發團隊頻繁交付更高質量的產品，而不必在二者之間抉擇。然而，正如僅專注於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官網：www.worktile.com
內容整理：worktile
devops未來 DevOps的未來是掌握多雲環境
devops未來 devops是一套實踐，可以使軟體開發和it團隊之間的流程自動化，以便他們可以更快，更可靠地構建，測試和發布軟體。devops的概念建立在建立it和業務團隊之間協作文化的基礎上，這些團隊在過去一直在相對孤島中發揮作用。承諾的好處包括增加信任度，更快的軟體發布以及快速解決關鍵問題的能...
什麼是敏捷？
scrum中文網 什麼是敏捷？敏捷是一種通過創造變化和響應變化在不確定和混亂的環境中取得成功的能力。什麼敏捷軟體開發？敏捷軟體開發是基於敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱。自組織 跨職能團隊運用適合他們自身環境的實踐進行演進得出解決方案。敏捷開發簡史？這些方 強調了開發團隊和業務干係...
DevOps第一講 什麼是DevOps
devops第一講 什麼是devops devops概念早先公升溫於2009年的歐洲，因傳統模式的運維之痛而生。devops是為了填補開發端和運維端之間的資訊鴻溝，改善團隊之間的協作關係。不過devops其實包含了四個部分 產品 開發 測試和運維。devops希望做到的是軟體產品交付過程中it工具鏈...