作者 | 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)入羣
大家也可以通過以下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：