使用DevOps強化敏捷（下）

做者 | Christopher Lee&Sean D. Mack

若是您曾經對敏捷或DevOps的歷史、結構、原則或共性有過疑問，那麼您將在這篇文裏找到答案，本文被拆分兩篇，上篇《使用DevOps強化敏捷（上）》主要介紹敏捷和DevOps的歷史、差別和好處，本篇主要介紹敏捷和DevOps的幾個共性。

敏捷和DevOps的目標是一致的，所以在實踐過程當中會發現它們有所重疊。在許多方面，DevOps和敏捷的交叉關係到協做文化以及從這種文化中產生的現代技術實踐和過程。

協做文化

敏捷和DevOps之間的核心共性之一是他們都強調打造協做文化。這兩種方法都着眼於打破壁壘，增長成員共同責任感。經過打破隔離，DevOps和Agile減小了交接，提升了向客戶交付的速度。DevOps將這種協做概念擴展到了運維團隊中，而敏捷關注QA是否包含在內。

在敏捷中，咱們看到協做文化直接融入到了敏捷宣言的核心原則中。第一個定義「我的和交互重於流程和工具」明顯地表達了合做的須要。此外，第三個原則，「客戶協做重於合同談判」，強調須要將這種協做擴展到開發團隊以外，也擴展到客戶當中。

敏捷教練Susan McIntosh在她的文章《敏捷心態究竟是什麼》中提到，「敏捷心態是一種支持敏捷工做環境的態度。其中包括尊重、協做、改進和學習反饋、對歸屬的自豪感、專一於提供價值以及適應變化的能力。這種心態對於培養高績效團隊是必要的，而這些團隊反過來又爲客戶帶來了驚人的價值。」

在敏捷中有許多協做的例子，諸如結對編程、Mob編程和Swarming等實踐都容許更大的團隊合做開發軟件，雖然這與開發的原概念相悖（開發本來是指由一個單獨的程序員單獨完成的任務）。此外，敏捷工做還將QA無縫連接到流程中，做爲團隊任務的一部分。RonLichty表示：「我將經過Scrum中的產品全部者角色將產品管理集成到團隊中。PdMs向開發人員「越過牆」拋出需求的歷史由來已久，這與開發人員向測試人員「越過牆」拋出代碼的歷史沒有太大不一樣！」RonJeffries寫了他在極限編程中處理故事的方法。Atlassian建議經過使用單頁儀表板縮小PRD（產品需求文檔）來保持需求的精簡。

DevOps的許多基本概念也是圍繞協做的概念構建的。事實上，這個能夠追溯到早先反對將開發、運維和QA分割之時。DevOps運動的基礎之一，正是人們認識到開發、運維和QA彼此獨立會致使利益衝突、增長交接成本。

Thoughtworks的首席科學家Martin Fowler指出協做在DevOps中扮演重要角色，他認爲，「DevOps文化的主要特徵是增長了開發和運維角色之間的協做……開發和運維之間不該該存在壁壘。」和從一開始就一塊兒工做解決問題相比，切換週期和文檔是一個糟糕的替代品。調整資源結構，使運維人員可以儘早參與到團隊中來是頗有幫助的。

另外，創建協做文化的一個關鍵方法是在全部參與交付的團隊之間制定共同的目標。使開發、運維和QA之間在明確的目標上保持一致，並將重點放在客戶需求和最終交付上。

DevOps鼓勵協做的另外一種方式是將運維活動集成到Sprint中。這能夠經過在Sprint中加入運維團隊成員來實現，甚至更好的方法是，將運維職責分給全部Sprint團隊成員。

除了交付特性和「功能」以外，在高性能的DevOps組織中，一般還向交付產品的團隊提供維護這些產品的職責。一旦系統的穩定性獲得證實，它就會移交給另外一個團隊進行維護。其餘公司包括開發團隊，做爲操做問題的尋呼機輪換的一部分。這就產生了共同的責任，並增強了共同的目標和責任。

固然，DevOps不是一份工做，它不是一個角色，也不是任何一我的或團隊的責任。DevOps的核心是協做，這與敏捷宣言中的原則保持一致。

小批量、短週期

小批量和短週期是敏捷化的關鍵。經過減小對系統的更改，敏捷能夠更快地爲客戶帶來價值。這種快速部署能帶來快速反饋，客戶或用戶能夠快速查看已開發的內容，團隊能在必要時快速調整路線。這與瀑布式方法造成了鮮明的對比，在瀑布式方法中，客戶可能要等上幾個月甚至幾年才能看到交付成果，只有到那時才能肯定產品是他們所想的仍是所要的。DevOps採用小批量的概念，並經過持續集成和持續部署（CI/CD）對其進行擴展。CI/CD提供的工具鏈加速團隊對客戶的價值，將週期從幾周縮短到幾天甚至幾小時。

小批量是精益的關鍵。起源於20世紀30年代的精益爲敏捷和開發人員提供了一些核心基礎，它專一於消除浪費和減小批量，減小正在處理的工做量，從而減小等待下一個階段處理的庫存量。

這一律念與敏捷的核心原則相呼應，敏捷的核心原則規定「常常交付產品，從幾周到幾個月，優先選擇較短的時間段。」小批量和較短的週期時間有不少好處。根據DonReinersen的說法，爲了讓產品開發增長價值，結果必然會有不肯定性。咱們不該該試圖最小化失敗，而應該接受可變性。咱們能夠經過有效地學習和高效地生成信息來減小不肯定性。VirtualCTO官諾亞•坎特（Noah Cantor）強調了短反饋循環的影響，「有不少學術研究和行業研究代表，反饋週期越長，人們從中學習的知識就越少。反之亦然——反饋週期越短，人們能夠從中學習的越多。」

有不少方法能夠確保你在敏捷中擁有小批量和較短的週期時間。最基本的方法之一是將用戶故事分割成適合迭代的片斷。減小故事的規模不少，好比將功能拆分爲單個用戶故事或任務等。

當劃分和拆分用戶故事時，重要的是確保您不建立合成型團隊，而是堅持使用功能團隊。垂直而不是水平地拆分用戶故事。也就是說，觀察端到端的特性，而不是應用程序的特定層。

小批量和短週期也是DevOps的關鍵。DevOps的重點是從左到右增長產品流。經過使用精益的工具（如價值流圖），能夠識別瓶頸並消除它們，從而增長對客戶的價值流。

此外，較短的循環時間是DevOps第二和第三種方法的關鍵。與敏捷同樣，更短的週期意味着價值能更快地傳遞給客戶，所以團隊能夠更快地得到反饋，以便能快速向客戶發佈特性或更改，並根據反饋快速調整。

DevOps中縮短循環時間和I迭代週期的關鍵之一是持續集成（CI）和持續部署（CD）。經過持續的集成，一些更改會不斷地被合併和驗證，從而使整個產品始終具備潛在的可交付性。而持續部署會確保產品始終處於可部署狀態，容許隨時向客戶交付價值。這兩個實踐採用了敏捷方法中最初引入的快速開發和交付，並將其週期進一步減小到天天甚至每小時。

工做可視化

可視化是DevOps和敏捷中的另外一個關鍵元素。對於像Scrum和看板這樣的敏捷實踐，一般採用板的形式來共享信息。DevOps利用並進一步擴展了這些方法，來共享系統在某一特定時間內的執行狀況，這能夠經過大型可視儀表盤和共享儀表盤的形式等展示。

雖然敏捷宣言並無規定工做可視化的必要性，可是概念是實踐的基礎。宣言強調「我的和交互重於流程和工具」和「客戶協做重於合同談判」以及「響應變化重於遵循計劃」，這三個方面都能經過工做可視化而獲得增強。

敏捷促成了「信息輻射源」概念的發展，這是一種位於敏捷開發團隊附近的大型圖表，能顯示整個開發週期的工做進展。Alistair Cockburn在2000年創造了「信息輻射源」這個術語，並在他2001年出版的《敏捷軟件開發》一書中作了介紹。

工做可視化能直接暴露出時間的缺漏，以優化工做和流程。經過爲團隊提供可視化工做的方法，使團隊可以一塊兒工做更加方便，這些板還幫助快速識別瓶頸。

DevOps的第二種方法集中於加強反饋和共享操做信息，這是一種很好的方法。這能夠包括Scrum板，也能夠包括關於系統性能、用戶體驗以及代碼和基礎結構性能的實時數據。這些信息圖表就像在整個建築的戰略位置張貼的大型監視器。

在DevOps手冊中，做者還用了整整一章的篇幅來討論遙測的問題。他們在他們的「建立遙測技術以發現和解決問題」一章中寫道，「咱們的目標是將這些信息輻射到組織的其餘部門，確保任何想要咱們正在運行的任何服務的信息的人都能得到這些信息……使價值流中的每一個人均可以實時共享信息和提出觀點。」

Etsy是一家以DevOps思想領導能力聞名的工藝電子商務公司，在工做可視化的領域也作了不少工做。「若是Etsy的工程有宗教信仰，那就是圖形教會。」Patrick McDonnell在DevOps手冊中談到了監控部署數據的好處，他說：「經過這樣作，咱們能夠更快地看到任何意外的部署反作用。咱們甚至開始在辦公室周圍安裝電視屏幕，以便每一個人都能看到咱們的服務表現。」

持續學習

敏捷和開發人員的核心原則中都有持續學習。在敏捷中，這個概念是敏捷宣言的一部分，在DevOps中，它是DevOps的第三種方法的一部分。

敏捷宣言強調「響應變化而不是遵循計劃」，所以，它構建了一個強調適應需求的原則。在這種適應性中，假設團隊不斷的反思和改進，在持續的敏捷短週期中，團隊便可以審查事情的進展狀況，並對他們交付的產品和交付過程進行快速調整。此外，「客戶協做重於合同談判」的宣言宗旨意味着嚴格的反饋循環、傾聽和從客戶反饋中學習。在敏捷中，產品團隊能夠快速地向客戶交付功能，並快速地從實際反饋中學習和快速調整。

DevOps也強調持續學習，其第三種方法便聚焦於此。在IT革命網站上，Kim寫道：「DevOps第三種方法是創造一種能促進兩件事的文化：一是持續實踐、冒險和從失敗中學習；二是理解重複和實踐是精通某件事的先決條件。」

同時，敏捷和DevOps都把不斷學習和不斷實驗的精神付諸實踐。在Scrum中，有被置於流程中的回顧會，用以確保團隊花時間對每一次迭代進行反思、從錯誤中學習並總結成功的經驗。回顧會是團隊對前一次迭代進行反思並尋找改進的會議，小組成員會討論哪些進展順利，哪些進展不順利，並列舉須要改進的方面。

Sprint演示是敏捷流程中持續學習的另外一個很好的例子。許多敏捷團隊會在每次迭代結束時對Sprint可交付成果進行演示，這樣可讓團隊成員互相學習，更好地理解產品的全部部分。Sprint演示中還能加入項目涉衆的快速反饋，爲團隊提供了一個互提意見和互相學習的機會，幫助你們繼續成長。

在DevOps中，不斷學習和不斷實驗的精神經過事故過後分析等行爲獲得了強調。JohnAllspaw幫助推出了過後無指責概念，以後這成爲了如今DevOps實踐的一個共識。他在博客中寫道：「過後總結最重要的事情不是一系列能夠採起的行動，而是組織學習。」

在Etsy，員工不只毫無責備地看待事件，甚至還慶祝失敗。慶祝失敗的緣由之一是犯錯誤的人其實是最好的工程師，這些人是那些爲企業作出最大改變和推進創新的人。所以，重要的不只僅是限制責備，實際上還灌輸了一種文化習慣，這種習慣將慶祝失敗視爲學習的機會。Etsy的CTO每一年會頒發一個頗有聲望的獎項，以慶祝今年最大的失敗。DevOps經過灌輸諸如無指責過後分析和失敗慶祝等習慣來鼓勵一種開放討論失敗並不斷學習和成長的文化。

『因爲篇幅緣由，本文被拆分兩篇，上篇主要介紹敏捷和DevOps的歷史、差別和好處，點擊藍字便可閱讀《使用DevOps強化敏捷（上）》。』

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源多雲技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

Choerodon豬齒魚已開通官方微信交流羣，歡迎你們添加Choerodon豬齒魚微信(ID:choerodon-c7n)入羣

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：choerodon.io
• 論壇：forum.choerodon.io
• Github：github.com/choerodon
• 碼雲：gitee.com/choerodon