\

本文要點

\

• 作為最流行的敏捷框架，Scrum的發展早于DevOps；正因如此，Scrum（及其他敏捷框架）實踐過度專注于廣義上被定義為軟件交付的開發方面，而忽視了運維方面。 \
• 混合了DevOps方法就需要圍繞團隊、待辦事項、如何編寫用戶故事等做些反思。例如，待辦事項應該包含可擴展性、可部署性、監控，等等。 \
• 沖刺計劃應該包含DevOps的某些方面，那樣，你就可以既討論產品功能，也討論運維特性。 \
• 傳統的Scrum管理員可能不完全適合這種混合方法——該角色更多的是一名敏捷教練。 \
• 從雇傭團隊成員的那一刻起我們就需要考慮DevOps，從產品規劃和構建到最終退役。

\

如果你構建了一款超級炫酷、功能超級強大、客戶也感覺超棒的產品，但卻無法部署、運維及在它正式上線后提供技術支持，那么它是沒有意義的。\

在敏捷的世界里，為了確保能夠在合理的預算內按時交付客戶期望的產品，我們已經付出了巨大的努力。我們還不遺余力地幫助客戶確定優先級最高的特性，那樣，我們就可以專注于交付高業務價值。我們盡量提前并經常交付，以便定期獲得相關的反饋。我們使用“用戶故事”幫助我們從用戶的角度進行思考，我們每次提交時都會測試代碼，從而確保我們不會破壞自己的代碼庫。\

這很好，但是所有那些聰明的技巧和技術呢？那些設計用來確保我們可以交付可部署、可擴展的高性能產品的技術，讓產品可以實時升級，自構建完成那一刻起就可以監控，日常管理不需要一個團隊的支持工程師。\

敏捷借用（并不斷發展）了源自汽車行業、神經科學、古代哲學、軍事和數學等領域的偉大思想（如精益生產、認知偏差、仆人式領導、規劃和相對大小）。現在，是時候借用DevOps場景的一些思想來確保敏捷仍然是最合適、最成功的產品交付原則和實踐。\

對于大多數產品而言，推出之后的支持和運維（Bug修復、特性發布和增強）占據了其生命周期的絕大部分時間。管理這些工作（滾動發布“在線”服務的變更、在“準運行環境”中測試等等）的可行方法以及如何擴展產品提升性能被視為“運維特性（Operational Features）”，這些內容在產品待辦事項中通常找不到。\

根據ZDNet最近的報道，咨詢公司CEB調查發現，“57%的預算會流向維護和必須的合規性活動，較2011年的63%有所下降”，而根據Gartner 2006年的報告，這一數值是80%。\

DevOps告訴我們，運維特性或“可操作性（Operability）”真得是一等公民，應該和其他產品特性一樣同等對待。為此，最好的方法是培養一種在開發團隊和運維團隊之間開展合作的強大文化。的確，如何實現這種合作是另外一個問題，“DevOps”模型差別很大，從Amazon的“誰構建，誰運行”方法（開發和運維活動存在于同一個產品團隊）到部分谷歌團隊采用的“DevOps即平臺”方法。\

DevOps的必要性

\

現在，敏捷和DevOps已經共存了多年，對于兩者之間的關系，已經有許多討論。\

有人將DevOps看作是敏捷的子集，有人將DevOps視為“正確踐行敏捷（agile done right）”，還有人將DevOps看作一套有關自動化的做法，與敏捷總體上關系不大。這完全取決于你對DevOps的定義。但是，不管你如何看待DevOps，交付可工作的軟件——可以輕松管理、維護、擴展、獲得支持及升級——這一宗旨是軟件交付世界急需的。\

自從敏捷框架被發明出來以后，軟件的運行和運維方式發生了巨大的變化。Scrum始于1993年，XP著作于1999年出版，DSDM于1994年推出。那時，我們編寫MSI安裝程序，燒錄到磁盤，然后寄給人們！\

通常，大多數軟件開發人員都不以任何方式參與軟件的運行、維護、操作。\

后來，情況發生了重大轉變，轉向了SaaS和PaaS，生產環境隨手可得。開發人員現在可以主動參與其系統的運維和支持，但是，我們仍然遵循與我們的工作方式變化不相適應的框架。\

持續交付來救援，差點

\

持續交付需要部署自動化。這是朝著正確方向邁出的一步，但即使這樣做了，在部分組織中，仍會不經意間創造出持續交付工程師這樣一個衍生職位（這通常會創建出另外一個筒倉）。隨著基礎設施管理日益重要，持續交付工程師逐漸變成了持續交付團隊，最終成了“平臺團隊”。在許多情況下，持續交付的這個方面分離出來變成單獨的團隊似乎很自然，這讓許多敏捷團隊回歸了他們感覺最舒服的方式——開發軟件，而不是交付。\

遺憾的是，這非常符合Scrum框架——開發團隊專注于設計、開發和測試軟件，持續交付團隊專注于管理他們部署的系統和底層的基礎設施。\

不用說，這種方式的問題是割裂了構建和部署自動化工作以及基礎設施管理任務，從敏捷團隊的角度出發，我們必定會將那些工作視為“其他人的問題”，而“可操作性”再次消失在后臺。\

許多團隊確實使用“正確地方式”實施了持續交付，這使他們能夠采用“我們構建，我們運行”的方式進行軟件交付（結果，他們獲得了更強烈的歸屬感和更高的產品質量），但并不是每個人都這樣。顯然，在特定的敏捷框架中引入新的做法會遇到相當大的阻力，即使本質上講，這些做法本身也是“敏捷的”。現在，我們面臨的事情和DevOps一樣了。\

DevOps反模式

\

DevOps的重點是消除Dev和Ops之間的鴻溝，減少讓人痛苦的工作交接，加強合作，以便類似“可部署性”、可擴展性、監控和技術支持這樣的工作不會被簡單地視為計劃外的東西。\

不過，我們已經開始看到DevOps場景中出現了強大的反模式，比如，Dev團隊和DevOps團隊的隔離，導致另一個筒倉的產生，而沒有做多少工作來加強合作。\

\

問題是，從實踐角度講，關于如何將這種新的DevOps方法融入敏捷開發團隊的信息極少。\

我們需要采用什么做法？我們需要停止什么做法？我們如何開始？我們的團隊應該配備什么角色？在很大程度上，這些問題仍然懸而未決。因此，團隊只是“追加”了DevOps，而沒有將其完全整合到他們的軟件開發流程。\

\

在這個典型的DevOps反模式中，我們完成了所有的敏捷儀式以及許多常規的DevOps實踐，但是，最終的結果沒有比以前更好——可操作性仍然是后期問題，產品針對開發優化，而不是交付和運維。這都是因為他們只是“追加”了關鍵的DevOps實踐，而沒有從一開始就合并進來。\

不用說，解決方案就是從一開始就將這些好的DevOps實踐合并進來，把它們吸收到我們日常的敏捷流程和實踐中——這需要我們對敏捷框架做些調整。\

升級敏捷實踐

\

那么，我們可以做些什么來保證我們正在用敏捷的方式開發軟件，同時又讓產品和服務的交付與維護符合DevOps部分最新最棒的最佳實踐？好，很簡單——只要左移一下！\

好吧，那聽上去比做起來要簡單許多，但思想是相當明確的。為了強調這一點，我們將與可操作性相關的任務/故事添加到待辦事項列表中，和用戶故事放在一起。我們的待辦事項列表很快就變成了所有產品成功交付所需的一整套史詩、故事和任務，然后是上線后的維護（而不只是從最終用戶角度出發的一系列功能特性）。\

從表面上看，這可能聽上去很簡單，但是有多個方面需要考慮，如：\

• 誰將負責這些可操作性故事/任務？ \
• 如果沒有最終用戶，如何編寫可操作性故事？ \
• 這些所謂的DevOps最佳實踐是什么？ \
• 希望產品經理如何應對這種情況？

所有這些問題的答案是：“需要改進的東西”。\

團隊

\

我們共事過的大部分敏捷團隊都不包含Ops、技術支持或基礎設施專家。你可能會反駁說，并不是每個敏捷團隊都有配備此類專家的強烈需求，你可能是對的，但不要忘了，對于測試人員、架構師、數據庫工程師、UX等，人們的說法也是完全一樣的。\

如果那種交付、支持、升級、擴展和維護產品的方式是重要的，你的團隊就需要這些技能。\

這意味著你要打破杰夫·貝索斯“兩個披薩團隊”的原則嗎？也許吧。但是，如果你的那份披薩對你特別重要，那么就不斷提高自己的技能吧！?（那實際上沒有聽上去那么難——我們越趨向X即服務的世界，我們所需要的核心系統管理知識就越少。取而代之，我們都需要對云函數及相關服務有一個很好的了解。）\

待辦事項列表

\

如果我們有跨職能團隊，那么我們就會需要跨職能的待辦事項列表。\

忘掉傳統的產品待辦事項列表——是時候采用一種包括服務操作性方面的全新方法了。我們有意使用了“服務”一詞，因為現如今我們傾向于構建的實際上是服務，而不是用收縮塑料薄膜包裝的產品。服務是需要部署、擴展、維護、監控和支持的產品，而我們的待辦事項列表需要反映出來。\

我們看到的大多數Scrum產品待辦事項列表，90%的內容是傳統特性，這些特性可以描述為一個最終用戶期望特性的集合。剩下的10%往往是與性能相關的東西，或者是與準備工作相關的東西（配置開發環境、準備數據庫等）。很明顯，這樣的列表側重于最終用戶功能/產品特性。我不能確定，這是Scrum框架本身造成的，還是產品經理對最終用戶存在偏見導致的（或者完全是另外一回事）。\

因此，新式的服務待辦事項列表（除了用戶功能外）應該描述如下內容：\

• 產品/服務的可擴展性（向上、向下、向內、向外——以及何時） \
• 可部署性（需要在線部署而不停機嗎？） \
• 服務監控（哪些方面需要監控？每次變更后如何升級監控？） \
• 日志（日志應該記錄什么信息？采用什么格式？） \
• 報警（誰？何時？如何？為什么？） \
• 服務的可測試性 \
• 安全和法規遵從性方面，如加密模型、數據保護、PCI法規遵從性、數據法規，等等 \
• 操作性能

Skelton說：“為了避免在開始時‘使用舊的構建方式’，我們需要將相當一部分產品預算（和團隊時間）用在運維方面。我發現，一般來說，將大約30%的產品預算用在運維方面就會產生不錯的結果，我們由此就可以獲得可維護、可部署、可診斷、多年以后仍然可以有效運行的系統。”\

需要注意的是，這些操作性和安全方面的需求會不斷地變化，會隨產品/服務演化，因此，我們不能只是在發布初期把所有那些工作完成，然后就轉向傳統的產品特性。例如，在系統取得商業成功之前實現系統自動擴展方案可能并不劃算。又或者，為了符合新的安全規范，你需要修改加密模型。同樣地，當在新的地方上線時，你可能需要修改那個部署模型。此外，當應用程序的功能發生任何大的變更時，監控通常都需要升級。\

用戶故事

\

從獲得預期結果的角度看，用戶故事是一種獲產品需求的好方法。用戶故事已經幫助許多開發人員（包括我們自己）從最終用戶的角度出發考慮問題，專注于問題的解決方案，而不是簡單地執行命令。不用說，我所說的用戶故事側重的是“什么”而不是“如何”（一個好的用戶故事描述問題，而將解決方案留給開發人員）。\

用戶故事通常使用下面的格式編寫：\

\

“作為……\

我希望……\

以便……”

\

這促使我們從用戶的角度出發編寫用戶故事（雖然不一定是最終用戶）。\

但是，這些年來，我發現，使用這種格式編寫操作故事并未真正帶來同等的改善效果。這可能是因為“用戶角度”沒有影響解決方案的技術實現方式。不管怎樣，如果你是自己實現解決方案，那么寫上“作為一名系統管理員”或者“作為一名開發人員”就感覺有點多余。\

在編寫待辦事項列表中的“技術待辦事項”時，不使用“作為……我希望……以便……”這種格式的情況并不少見，類似地，我不推薦使用這種格式編寫操作特性。取而代之，我更喜歡使用“什么和為什么”格式，只是簡單地列出需要做什么以及為什么做（提供上線文）。\

\

沖刺

\

感覺為期兩周的沖刺正好可以開發新特性、測試\u0026amp;部署，然后向相關人員展示。再長一點就很難保持注意力，而反饋循環的數量會增長到一個讓人稍微有點不適的數量。再短一點，比如一個周，那么臨時會議和其他儀式在實際沖刺時間中的占比就會過高，就是說，你可以完成的工作就會很少。因此，對許多人來說，兩個周剛好。這么長一段時間剛好可以讓你鋪下身子，專心完成你承諾的工作。\

如果你在開發一款新產品，這很好，但如果你是在進行一些改進迭代或者開發產品的下一個版本呢？\

誰將負責生產平臺上不斷出現的所有問題？\

如果你相當頻繁地被這類事情打斷（或者遭遇不同程度的此類干擾），那么你就會知道，這會嚴重地妨礙你兌現沖刺承諾。從幫助人們專注于現實目標來看，為期兩周的沖刺似乎帶來了很大的價值，但在一個不可預測的環境里，很難準確地確定你可以在多大程度上完成待辦事項列列表上的內容。很難，但并不是不可能。\

如果可以度量出待辦事項列表上的工作我們平均能夠完成多少，以及生產平臺的問題平均打斷我們多少次，那么我們大致上可以推導出兩個速度。\

待辦事項速度是指我們可以以什么樣的速度完成產品/服務待辦事項列表上“計劃好”的工作，而“計劃外”速度是沖刺期間意外產生的工作量。跟蹤這兩個速度，我們可以做出有效的計劃。\

當然，看板也是一種選擇，可以兼顧計劃好的和計劃外的工作，不太清楚一周后要做什么的團隊通常會選擇這個框架。該框架還可以非常高效地交付周期較長的項目/版本，但需要很強的紀律性來確保可以動態、恰當地調整待辦事項的優先級。\

沖刺計劃

\

如果你在做沖刺，就需要做沖刺計劃。將DevOps引入沖刺計劃，需要做以下工作：\

• 邀請運維/基礎設施/支持人員參加計劃會議 \
• 不僅要討論產品功能，還要討論操作特性 \
• 把它們加入接下來的沖刺 \
• 把“打斷”可能占用的時間\u0026amp;精力考慮進來——就是來自產品平臺的計劃外工作，如Bug修復、升級等（這個值就是“計劃外速度”，它會顯著降低待辦事項速度。計劃外速度越高，待辦事項速度就越低）

完工定義

\

一個流行的完工定義是“通過UAT”，這基本上就是“業務人員已經對功能進行簽字確認”的另一種說法。但是，在很大程度上，這忽視了操作性、安全性、性能等等。一個故事需要已經做好上線準備才能視為“已完工”（或者最好是已經在生產環境中）。也就是說，它需要可擴展、性能好、可監控、安全性好，并且明顯可部署！如果故事沒有滿足所有這些條件，就沒有完工。\

Scrum管理員

\

請記住，我們需要改變或破壞一些已有的Scrum規則（參見上面的例子），這給Scrum管理員帶來了問題。即使你想要維護一個非常像Scrum的流程，但事實是，那不是Scrum；那是Scrum和DevOps的混合。\

Scrum管理員角色的某些職責仍然完全有效——比如清除障礙，但是，Scrum管理員現在不僅要清除軟件開發的障礙，還需要清除軟件交付及維護的障礙。\

另一種選擇是轉變為敏捷教練角色，遵循敏捷的原則和價值觀，但是要用和新流程一致的方式，而不受Scrum框架的指定性規則所限制。你最不希望發生的事情是，Scrum管理員不理解DevOps的用途；那只會加大開發和運維雙方的分歧。\

產品經理

\

在敏捷和DevOps的混合環境中，產品經理應該比任何人都更了解可操作性的重要性。\

在SaaS、PaaS和無服務器環境中，許多價值是隱藏的——不在前端。該價值源于我們的服務如何工作。它可以帶來時間和成本的節省、性能的提升、風險的降低、可靠性的提高及其他“隱藏的”價值。產品經理現在就需要有這個認識，因為他們最終會負責管理優先級。\

持續集成（CI）和持續交付（CD）

\

有人建議，將CI和CD工具分開，這大概是因為CI更側重于開發，而CD有一個更全面的視圖。\

不管你怎么看，CI和CD都不只是工具，它們是實際的工作方式。有CI系統和做持續集成有很大的差別。持續交付同樣如此。\

在DevOps/敏捷的混合環境中，重要的是，我們不僅使用CD作為交付機制，還是作為一組指導原則和實踐方法。這很重要，因為持續交付把開發和運維納入了同一個框架。一個好的CD管道就下面這個那樣，可以可視化軟件定期交付的所有重要步驟——你可以自己看下，可用的測試基礎設施、可靠的測試框架、良好的監控和部署自動化是多么重要。\

\

請記住Dave Farley總結的持續交付的八大原則和四大實踐，特別注意下其中一些關鍵的實踐，比如，“只構建一次二進制文件”，“部署到每個環境時，都使用完全相同的機制”，“如何任何地方失敗了，就停止這個過程！”，但特別需要注意的是，“每個人都對發布過程負有責任”。\

小結

\

Scrum是最流行的敏捷框架，設計它的時候，團隊通常不需要考慮運維問題，如可擴展性、可部署性、監控和維護。\

因此，Scrum（及其他敏捷框架）的實踐過度專注于廣義上被定義為軟件交付的開發方面，而忽視了運維方面。\

DevOps有助于糾正這種不平衡，但對開發階段本身的實踐影響很小。有關DevOps的定義以及規范框架的缺失意味著有關如何將DevOps思維融入敏捷軟件開發過程的信息很少或完全沒有。\

為了最大化敏捷和DevOps的價值，你必須在開發過程開始之初就實現其中一些DevOps原則，因為最后加入一點部署自動化不會幫助你構建更可擴展、部署和管理的解決方案。\

我們應該從雇傭團隊成員的那一刻起就考慮DevOps，貫穿產品的規劃和構建，一直到它們最終退役。\

這就是說，我們必須以全新的眼光看待一些公認的敏捷概念，如技能集和產品團隊里的角色、產品待辦事項本身以及我們如何計劃和執行迭代。\

許多團隊已經成功采用了敏捷實踐，變得更符合DevOps，但是沒有一種解決方案是通用的，有的只是一組很好的模式。\

關于作者

\

James Betteley具有開發、運維背景，這對他目前在DevOps領域的工作非常有幫助。近年來， 他深入DevOps轉型領域，幫助眾多企業組織使用敏捷和DevOps原則更快地交付了更好的軟件。

\

Matthew Skelton從1998年開始一直從事商業軟件系統的構建、部署和運維。他是Skelton Thatcher咨詢公司的聯合創始人兼首席咨詢師，致力于幫助組織實施和維持軟件系統構建和運維的良好實踐：持續交付、DevOps、ITIL的方方面面和軟件操作性。Matthew創立了著名的DevOps團隊拓撲模式 。他還是《Database Lifecycle Management (Redgate)》和《Continuous Delivery with Windows and .NET 》（O’Reilly）兩書的合著者。他的推特賬號：@matthewpskelton。

\

查看英文原文：Merging Agile and DevOps

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的敏捷与DevOps整合之道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。