團隊轉型，Scrum與DevOps要如何取捨？

本文摘自 。

團隊在踐行敏捷的過程中，會有多種選擇：Scrum、XP、Kanban、Crystal、精益生產、規模化敏捷等，其中最流行的敏捷開發方法當屬Scrum。正因如此，大部分人對其產生了刻板印象：  認為敏捷就是Scrum，實施敏捷就是套用Scrum方法。

而產生在敏捷之後的DevOps集文化理念、實踐和工具於一身，可以提高組織高速交付應用程式和服務的能力，與傳統的軟體開發和基礎設施管理流程相比，能夠幫助組織更快地發展和改進產品，也逐漸成為銜接開發團隊和運維團隊的膠合劑。在這種情況下，大家反而會常常限制在一個  思維困境中：  團隊轉型，是選擇Scrum還是DevOps？

在這裡，有必要糾正一下人們的思維誤區。首先，敏捷並非等於Scrum，敏捷作為一種軟體開發運動，其發起人試圖以一種更為敏捷的新方式來思考軟體開發、方法論以及組織架構，從而幫助行業中的人們。Scrum作為一種方法論，並不是詳細的操作規範，而是一套行為框架，在此框架基礎上，各團隊根據自己團隊實際情況制定合適的迭代任務。

而DevOps關注的不只是開發階段的內容，它關注的是整個系統，以促進端到端的價值流動為目的。從客戶提出需求，到進入開發階段，再到交付客戶成果，價值的流動並非侷限於某一階段中。整套系統中各個單元都相輔相成，因此某一部分的改變會影響其他部分，為了使價值順利地流動出去，需要系統中各個單元的相互配合。

因此，當人們對Scrum和DevOps並不瞭解時，常常會陷入二選一的誤區。實際上，Scrum與DevOps並不衝突，從性質上來講，  Sc  rum偏向於基礎框架，DevOps偏向於文化理念；  從另一個角度來講，Scrum與DevOps是區域性與整體的關係：Scrum更注重每一sprint結束後的成果交付，DevOps則注重構建、開發、運維等階段的整體執行、前後的銜接與持續交付。

在Scrum團隊中，除卻原Scrum團隊中的開發人員，還包括架構人員、分析人員、銷售人員等，團隊下一步要考慮的問題是如何將將各職能成員聯絡在一起。部分已經意識到此問題的團隊為了解決單一的Scrum方法論僅注重開發階段這一弊端，開始尋求DevOps的支援。

1.持續交付

在Scrum中引入DevOps的持續交付概念，強調每個sprint的完成應以產品增量為目標。

• 首先，在sprint期間，Scrum Master不會制定詳實的sprint計劃，而是  僅制定sprint中前幾日的計劃，之後便隨著衝刺期間的工作改進、調整靈活變動計劃內容；
• 其次，  每日召開Scrum會議，同步團隊中成員計劃，提高成員之間的協作效率；
• 最後，在sprint結束後，  團隊需要召開回顧會議來彙總這一階段所做的工作，反思這次衝刺中的不足之處及應該注意的事項，以便在下次sprint中調整團隊的整體方向。

在sprint階段裡，Scrum團隊不斷地進行學習、獲取反饋，努力提高改進、產出速度，使產品儘可能多地釋出到交付環境中。隨後Scrum Master 透過這一期的目標完成情況決定下一期的sprint目標，在這一期間仍要注意的是，儘量減少過程中的人為干預，從而減少釋出過程的週期。

2.擴大反饋

Scrum團隊透過驗收會議、回顧會議以及每日Scrum同步團隊成員的任務進度，以及時獲取上一sprint成果的反饋。與單一的Scrum不同，應用DevOps的Scrum驗收已經處於生產環境中的sprint成果，驗收標準也不再是單一的效能測試，而是圍繞產品本身、部署架構、市場等方面進行多方位評審，從而制定下一期sprint計劃。

擴大反饋的方式有很多，總的來說首要步驟就是如何提高生產效率。有以下幾種方法：  可以利用結對程式設計來增加工作效率，使產品儘可能多地交付到環境中。  也可以統一程式碼規範，減少額外成本的增加：當團隊擁有良好且統一的程式碼規範時，會有效規避因某個成員的缺席造成團隊工作停滯的風險，也能夠提升程式碼的可讀性，從而提高工作效率、擴大反饋。

Scrum的儀式感常常表現在  迭代計劃會議、  每日站立會議、  回顧會議等方面。而DevOps更注重在整個價值流中快速並持續交付價值，這種價值的快速流動需要產品釋出過程中每個人的參與；同時，透過自動化“軟體交付”和“架構變更”的流程，逐漸消除人為干預，使得構建、測試、釋出軟體更加地快捷、頻繁和可靠。

DevOps文化倡導  “共同責任”，也就是在產品釋出全流程中，所有成員透過協作確保產品有價值，因此，在Scrum框架基礎上應用DevOps能夠幫助Scrum團隊更好地進行知識學習和創新。