Scrum是一種敏捷方法，旨在指導團隊進行產品的迭代和增量交付。通常被稱為“敏捷項目管理框架”，其重點是使用經驗過程，使團隊能夠快速，有效，有效地做出改變。傳統的項目管理方法確定了需求，以控制時間和成本;?另一方面，Scrum修復了控制需求的時間和成本。這是使用時間框，協作儀式，優先產品積壓和頻繁的反饋周期來完成的。整個項目中業務的參與至關重要，因為Scrum在很大程度上依賴于團隊與客戶或客戶代表之間的協作，以精益 (Lean) 方式創建合適的產品。

什么是Scrum？

我們首先應該清楚Scrum不是什么。有一種常見的誤解，認為敏捷就是?Scrum。雖然Scrum確實很敏捷，但它并不是實現敏捷原則的唯一方法。Scrum只是產品開發的眾多敏捷方法之一。其他方法包括極限編程（XP），晶體，特征驅動開發，DSDM Atern等。所有這些方法都遵循敏捷宣言及其相關原則。一個有用的比喻是認為敏捷是冰淇淋 (ice Cream)，而Scrum，XP，水晶 (Crystal) 等，都是不同的口味，如巧克力，草莓，香草。它們都很敏捷，它們都很好，很多都可以組合使用。

簡而言之，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 Process Canvas

該項目始于企業提供的清晰愿景，以及按重要性排列的一系列產品功能。這些功能是產品待辦事項的一部分，由客戶或客戶代表（稱為產品負責人）維護。通常稱為迭代或沖刺的時間框是團隊必須完成所選功能的設定時間量。短跑的長度通常為一到四周，并且在整個項目的整個生命周期中保持這個長度以便建立節奏。團隊從產品待辦事項中選擇它認為可以在sprint中完成的項目，并在sprint規劃會議中創建包含功能和任務的sprint backlog。

一旦團隊致力于sprint積壓，任務工作就開始了。在sprint的這段時間內，團隊可以免受中斷，并且可以專注于滿足sprint目標。不允許更改sprint backlog;?但是，可以更改產品積壓以準備下一個sprint。

在沖刺 (Sprint) 期間，團隊每天以15分鐘的會議（稱為scrum Standup）的形式互相討論和溝通。團隊圍成一圈，每個成員都說明了他們昨天做了什么，他們打算今天做什么，以及他們的方式是什么。

在sprint結束時，團隊將他們完成的工作演示給利益相關者，并收集反饋，這將影響他們在下一個sprint中的工作。他們還舉辦了一次回顧展，以了解如何改進。這次會議至關重要，因為它的重點是Scrum的三大支柱：透明度，檢查和適應性。

角色和責任

Scrum中只有三個角色：ScrumMaster，產品負責人 (Prodcut Owner) 和開發團隊 (Development Team)。

ScrumMaster是流程的守護者，團隊的倡導者和團隊的保護者。他們消除障礙，促進團隊溝通，調解團隊內部的討論，并與團隊外部人員進行協商。最重要的是，它們存在于團隊服務中。

產品負責人 (Prodcut Owner) 代表客戶的聲音，并有權決定產品。此人擁有產品待辦事項，負責將愿景傳達給團隊，并定義積壓項目并確定其優先級。產品負責人每天與團隊合作，回答問題并提供產品指導。

該開發團 (Development Team)隊由七個正負兩個人組成，他們共同負責產品的交付。他們擁有估算，做出任務承諾，并在每日Scrum中相互報告每日狀態。它們是自組織的，意味著結構在沒有外界明確干預的情況下出現。換句話說，團隊擁有如何選擇構建產??品功能 - 團隊擁有“如何”，而產品所有者擁有“什么”。

Scrum的應用

Scrum通過一系列儀式 (Scrum Ceremonies) 或會議 (Meetings) 來應用。必要的Scrum儀式包括sprint計劃會議 (Sprint Planning)，每日scrum (Daily Standup)，sprint審查 (Sprint Review) 和sprint回顧 (Sprint Retrospective)。還需要使用稱為沖刺的時間框。發布計劃會議是可選的，允許規劃和預測沖刺組。

Sprint計劃會議

沖刺計劃會議在每個沖刺的第一天舉行。ScrumMaster，產品負責人和團隊都出席了會議。產品負責人提供他或她希望在sprint中完成的功能集（“什么”），然后團隊確定實現這些功能所需的任務（“如何”）。將審核工作估算，以確定團隊是否有時間完成sprint中請求的所有功能。如果是這樣，團隊承諾沖刺。如果沒有，優先級較低的功能將返回到產品待辦事項中，直到sprint的工作負載小到足以獲得團隊的承諾。

跟蹤進度

一旦沖刺計劃 (Sprint Planning) 會議完成并且團隊做出了承諾，團隊就會開始使用高度可見的信息輻射器跟蹤其進度。這些散熱器包括燃盡圖和任務板。

團隊使用任務板跟蹤每個功能的任務進度。使用的最小列是“待辦事宜”，“執行”和“完成”。團隊將在任務委員會舉行每日Scrum會議，并在陳述他們昨天做了什么，他們打算今天做什么以及他們正在努力解決的障礙時，全面移動項目。有關軟件開發項目的示例任務板，請參見圖2。

圖表2. Scrum任務板示例

燃盡圖顯示了沖刺中剩余工作量的趨勢線。x軸是sprint中的天數，y軸是sprint規劃會議中定義的所有任務的小時數。在沖刺期間，指示剩余工作量的線應該在沖刺的最后一天趨勢下降到零。有關sprint burndown圖表示例，請參閱圖表3。

圖表3. Sprint Burndown圖表示例

使用燃盡圖表，任務板和每日Scrum跟蹤Sprint進度。結合起來，這三件事可以清楚地描述正在進行的工作，已完成的工作，仍有待完成的工作，是否能夠及時完成，以及可能阻止團隊滿足其沖刺和/或發布目標。

Sprint評論 (Sprint Review)

在sprint結束時，團隊邀請利益相關者參加sprint評審會議，在會議中演示sprint中完成的功能并請求反饋。產品負責人會跟蹤反饋并根據需要將其合并到產品待辦事項中。

一旦審查完成，團隊（沒有利益相關者）進行回顧，以確定他們希望繼續做什么，他們掙扎的是什么，以及他們對未來的改變有什么建議。創建一個行動計劃，這些項目將在下一個sprint的過程中實施，并在下一個sprint回顧中進行審查。

發布計劃 (Release Plan)

發布計劃也是Scrum的一部分，是一種對包含多個sprint的時間框進行長期規劃的方法。這通常是按季度完成的，本季度的結果不一定是向客戶發布的，但可能只是內部版本以確認系統集成和驗證。圖表4顯示了發布計劃如何適應Scrum框架的其余部分。

整個團隊參加發布計劃會議，產品負責人在會議中展示他/她希望在本季度完成的功能。然而，該團隊并未對這些功能進行任務，而是提供總體水平估算，以確定在什么樣的沖刺中可以完成哪些功能，以及在本季度末可以完成多少這些功能。發布計劃可以是功能驅動的（完成這組功能需要多少沖刺？），時間驅動（我們期望在截止日期前完成多少功能？）或成本驅動（考慮到這個預算，我們的日程安排是什么樣的，我們在沒錢之前會做些什么？）

?

圖表4. Scrum中的發布計劃

?

總結

以上是生活随笔為你收集整理的使用Scrum进行敏捷项目管理的全部內容，希望文章能夠幫你解決所遇到的問題。

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