Scrum是一種敏捷方法，旨在指導團隊進行產品的迭代和增量交付。通常被稱為“敏捷項目管理框架”，其重點是使用經驗過程，使團隊能夠快速，有效，有效地做出改變。傳統的項目管理方法確定了需求，以控制時間和成本; 另一方面，Scrum修復了控制需求的時間和成本。這是使用時間框，協作儀式，優先產品積壓和頻繁的反饋週期來完成的。整個項目中業務的參與至關重要，因為Scrum在很大程度上依賴於團隊與客戶或客戶代表之間的協作，以精益的方式創建合適的產品。
什麼是Scrum？
我們首先應該清楚Scrum不是什麼。有一種常見的誤解，認為敏捷就是 Scrum。雖然Scrum確實很敏捷，但它並不是實現敏捷原則的唯一方法。Scrum只是產品開發的眾多敏捷方法之一。其他方法包括極限編程（XP），晶體，特徵驅動開發，DSDM Atern等。所有這些方法都遵循敏捷宣言及其相關原則。一個有用的比喻是認為敏捷是冰淇淋，而Scrum，XP，水晶等都是不同的口味，如巧克力，草莓，香草。它們都很敏捷，它們都很好，很多都可以組合使用。
簡而言之，Scrum是一種靈活的迭代和增量產品交付方法，它使用頻繁的反饋和協作決策。
歷史
Scrum基於1986年由Hirotaka Takeuchi和Ikujiro Nonaka撰寫的題為“新產品開發遊戲” 的哈佛商業評論的論文。在本文中，作者使用橄欖球運動作為隱喻來描述自我的好處。組織創新產品開發和交付團隊。Jeff Sutherland，Ken Schwaber和Mike Beedle從本文中提取了這些想法，包括隱喻，並將其應用於他們的軟件開發領域。在橄欖球術語之後，他們稱他們的新方法Scrum，這個術語描述了球隊如何形成一個圓圈並且讓球再次重新發揮作用。他們首先在1993年在Easel公司應用了這種方法.Schwaber和Beedle在他們的書“ 敏捷軟件開發與Scrum”一書中寫下了他們的經歷。2002年，Schwaber 在2004年與Scrum一起出版了敏捷項目管理書，其中包括Schwaber與Primavera合作完成的工作。
Scrum框架
Schwaber將Scrum稱為框架而非方法論。這主要是由於“方法論”這個詞的內涵，許多人認為這些內容具有說明性。相比之下，Scrum只提供了一個交付結構，但沒有告訴您如何進行特定的實踐，而是將其留給團隊來確定。圖1顯示了基本的Scrum框架。
圖表1.原始Scrum框架
該項目始於企業提供的清晰願景，以及按重要性排列的一系列產品功能。這些功能是產品待辦事項的一部分，由客戶或客戶代表（稱為產品負責人）維護。通常稱為迭代或衝刺的時間框是團隊必須完成所選功能的設定時間量。短跑的長度通常為一到四周，並且在項目的整個生命週期內保持這個長度以便建立節奏。團隊從產品待辦事項中選擇它認為可以在sprint中完成的項目，並在sprint規劃會議中創建包含功能和任務的sprint backlog。
一旦團隊致力於sprint積壓，任務工作就開始了。在sprint的這段時間內，團隊可以免受中斷，並且可以專注於滿足sprint目標。不允許更改sprint backlog; 但是，可以更改產品待辦事項以準備下一個sprint。
在衝刺期間，團隊每天以15分鐘的會議形式（稱為scrum）進行互相檢查。團隊圍成一圈，每個成員都說明了他們昨天做了什麼，他們打算今天做什麼，以及他們的方式是什麼。
在sprint結束時，團隊將他們完成的工作演示給利益相關者，並收集影響他們在下一個sprint中工作的反饋。他們還舉辦回顧會，學習如何改進。這次會議至關重要，因為它的重點是Scrum的三大支柱：透明度，檢查和適應性。
角色和責任
Scrum中只有三個角色：ScrumMaster，產品負責人 (Product Owner) 和團隊 (Development Team):
Scrum Master是流程的守護者，團隊的倡導者和團隊的保護者。他們消除障礙，促進團隊溝通，調解團隊內部的討論，並與團隊外部人員進行協商。最重要的是，它們存在於團隊服務中。
產品負責人代表客戶的聲音，並有權決定產品。此人擁有產品待辦事項，負責將願景傳達給團隊，並定義積壓項目並確定其優先級。產品負責人每天與團隊合作，回答問題並提供產品指導。
該團隊由七個正負兩個人組成，他們共同負責產品的交付。他們擁有估算，做出任務承諾，並在每日Scrum中相互報告每日狀態。它們是自組織的，意味著結構在沒有外部明確干預的情況下出現。換句話說，團隊擁有如何選擇構建產品功能 - 團隊擁有“如何”，而產品負責人擁有“什麼”。
Scrum的應用
Scrum通過一系列儀式或會議來應用。必要的Scrum儀式包括sprint計劃會議，每日scrum，sprint審查和sprint回顧。還需要使用稱為衝刺的時間框。發布計劃會議是可選的，允許規劃和預測衝刺組。
Sprint計劃會議
衝刺計劃會議在每個衝刺的第一天舉行。ScrumMaster，產品負責人和團隊都出席了會議。產品負責人提供他或她希望在sprint中完成的功能集（“什麼”），然後團隊確定實現這些功能所需的任務（“如何”）。將審核工作估算，以確定團隊是否有時間完成sprint中請求的所有功能。如果是這樣，團隊承諾衝刺。如果沒有，優先級較低的功能將返回到產品待辦事項中，直到sprint的工作負載小到足以獲得團隊的承諾。
跟踪進度
一旦衝刺計劃會議完成並且團隊做出承諾，團隊就會開始使用高度可見的信息輻射器跟踪其進度。這些散熱器包括燃盡圖和任務板。
團隊使用任務板跟踪每個功能的任務進度。使用的最小列是“待辦事宜”，“執行”和“完成”。團隊將在任務委員會舉行他們的日常scrum會議，並在陳述他們昨天做了什麼，他們打算今天做什麼以及他們正在努力解決的障礙時，全面移動項目。有關軟件開發項目的示例任務板，請參見圖2。
圖表2. Scrum Task Board 任務板示例（圖片由Visual Paradigm 提供）
燃盡圖顯示了衝刺中剩餘工作量的趨勢線。x軸是sprint中的天數，y軸是sprint規劃會議中定義的所有任務的小時數。在衝刺期間，指示剩餘工作量的線應該在衝刺的最後一天趨勢降至零。有關sprint burndown圖表示例，請參閱圖表3。
圖表3. Sprint Burndown圖表示例
使用燃盡圖表，任務板和每日Scrum跟踪Sprint進度。結合起來，這三件事可以清晰地描述正在進行的工作，已完成的工作，仍有待完成的工作，是否能夠及時完成，以及可能阻止團隊滿足其衝刺和/或發布目標。
Sprint評論 (Sprint Review)
在sprint結束時，團隊邀請利益相關者參加sprint評審會議，在會議中演示sprint中完成的功能並請求反饋。產品負責人會跟踪反饋並根據需要將其合併到產品待辦事項中。
審核完成後，團隊（沒有利益相關者）會進行回顧，以確定他們希望繼續做什麼，他們掙扎的是什麼，以及他們對未來的改變提出了什麼建議。創建一個行動計劃，這些項目將在下一個sprint的過程中實施，並在下一個sprint回顧中進行審查。
發布計劃 (Release Planning)
發布計劃也是Scrum的一部分，是一種對包含多個sprint的時間框進行長期規劃的方法。這通常是每季度完成一次，本季度的結果不一定是向客戶發布的，但可能只是內部版本以確認系統集成和驗證。圖表4顯示了發布計劃如何適應Scrum框架的其餘部分。
整個團隊參加發布計劃會議，產品負責人在會議中展示他/她希望在本季度完成的功能。然而，該團隊並未對這些功能進行任務，而是提供總體水平估算，以確定在什麼樣的衝刺中可以完成哪些功能，以及在本季度末可以完成多少這些功能。發布計劃可以是功能驅動的（完成這組功能需要多少衝刺？），時間驅動（我們期望在截止日期前完成多少功能？）或成本驅動（考慮到這個預算，我們的日程安排是什麼樣的，在我們沒錢之前我們會做些什麼？）
圖表4. Scrum中的發布計劃 (Illustrated by Visual Paradigm - Implementation Plan Diagram)
