(Source: What is Scrum?)

Scrum是一個專案管理框架，強調團隊合作，問責制和迭代進展，以實現明確的目標。該框架從一個簡單的前提開始：從可以看到或已知的東西開始。之後，跟蹤進度並根據需要進行調整。

Scrum的三大支柱

Scrum的基礎是經驗主義，它指出知識來自經驗，我們應該根據已知的事情做出決定。有三個支柱將Scrum結合在一起。

為什麼選擇Scrum？

Scrum一次提供功能，而瀑布只提供階段。典型的瀑布式開發是基於階段的順序過程，在專案結束之前不會給出價值。Scrum將這種模式轉變為每一週提供新功能，而不是專注於未來的大發布。

Scrum將複雜的工作劃分為簡單的部分，將大型組織劃分為小型團隊，將影響深遠的專案劃分為一系列短時間的稱為sprint的視野。

通過迭代和漸進式構建，公司能夠更快，更有效地為客戶提供他們真正需要的產品和服務。使用Scrum，您可以在每個小開發週期結束時接收並整合客戶反饋，這意味著您的結果將通過實際使用而非您的假設來塑造。這使得讓客戶和主要利益相關者密切參與和參與變得更加容易。

敏捷與Scrum

敏捷方法是一種有助於在SDLC過程中持續迭代開發和測試的實踐。敏捷將產品分解為更小的構建。Scrum只是眾多迭代和增量敏捷軟體開發過程中的一個，它使我們能夠專注於在最短的時間內提供業務價值。

Scrum框架通常處理的是需求可能會發生變化，或者大部分時間在專案開始時都不知道。Scrum的特點是：

• 輕量級
• 簡單易懂
• 很難精通

Scrum的好處

以下是scrum為組織，團隊，產品和個人提供的好處。

1. 更好的質量：存在實現願景或目標的專案。Scrum提供持續反饋和曝光的框架，以確保質量儘可能高。Scrum通過以下實踐幫助確保質量
2. 縮短產品上市時間：Scrum已被證明能夠為傳統方法提供比最終客戶快30％到40％的價值。
3. 提高投資回報率：縮短上市時間是Scrum專案實現更高投資回報率（ROI）的一個關鍵原因。由於收入和其他目標福利開始提前，早期積累意味著更高的總回報率。這是淨現值（NPV）計算的基本原則。
4. 士氣高階團隊：與喜歡工作的快樂人士一起工作可以令人滿意和有益。自我管理將通常由經理或組織做出的決策放入scrum團隊成員的手中。
5. 加強團隊協作：當Scrum團隊負責專案和產品時，他們可以產生很好的結果。Scrum團隊通過增強團隊參與和溝通來協作並掌握質量和專案績效。

Scrum框架

Scrum很簡單。它與大量交織的強制元件相反。Scrum不是一種方法論。Scrum實現了經驗主義的科學方法。Scrum用啟發式方法取代了程式化的演算法方法，尊重人和自組織，以處理不可預測性和解決複雜問題。下圖顯示了Ken Schwaber和Jeff Sutherland在他們的“30天軟體”一書中描述的Scrum in Action，它將我們從規劃到軟體交付。

Scrum流程的組成部分

Scrum框架本身非常簡單。它僅定義了一些通用指南，僅包含一些規則，角色，工件和事件。然而，這些元件中的每一個都很重要，用於特定目的，對於成功使用框架至關重要。

Scrum Framework的主要元件是：

• Scrum角色：Scrum Master，Scrum產品負責人和Scrum團隊
• 工件：Sprint積壓，產品積壓，燃盡圖，日誌等......
• Scrum活動：Sprint計劃，Sprint 評論，每日站立 (Daily Standuo) 等......
• 短跑 (Sprint)

下圖顯示了SCRUM框架的關鍵元素。該過程已由敏捷軟體工具Scrum Process Canvas應用。

Scrum角色

當一個組織決定接受Scrum時，首先要了解的是Scrum角色與傳統專案執行角色的不同之處。雖然Scrum中只有三個主要角色，但它們並不會自動與我們大多數人熟悉的標題保持一致。讓我們從每個的簡要定義開始：

產品擁有者 (Product Owner)

產品所有者是代表業務或使用者社群的人員的scrum開發角色，負責與使用者組合作以確定產品版本中的功能。產品負責人的主要職責是：

• 制定產品和服務的方向和戰略，包括短期和長期目標;
• 提供或獲取有關產品或服務的知識;
• 瞭解並解釋開發團隊的客戶需求;
• 收集，優先排序和管理產品或服務要求;
• 接管與產品或服務預算相關的任何責任，包括其盈利能力;
• 確定產品或服務功能的釋出日期;
• 每天與開發團隊一起回答問題並做出決定;
• 接受或拒絕與Sprint相關的已完成功能;
• 在每個Sprint的最後展示開發團隊的主要實現;
• 負責產品Backlog

Scrum大師 (Scrum Master)

Scrum master是敏捷開發團隊的推動者。Scrum是一種方法，允許團隊根據敏捷原則自我組織並快速進行更改。Scrum master管理資訊交換的過程。Scrum Master的主要職責是：

• 充當教練，幫助團隊遵循Scrum價值觀和實踐;
• 幫助消除障礙並保護團隊免受外部干擾;
• 促進團隊與利益相關者之間的良好合作;
• 促進團隊內部的常識;
• 保護團隊免受組織干擾;

Scrum開發團隊 (Scrum Development Team)

Scrum團隊（又名開發團隊）由3到9人組成，他們必須滿足提供產品或服務的所有技術需求。它們將由Scrum Master直接引導，但不會直接管理。他們必須是自我組織的，多才多藝的，並且負責任地完成所有必需的任務。

開發團隊負責從分析，設計，開發，測試到技術寫作等每個sprint提供潛在的可交付產品增量。對於Scrum團隊具有以下特徵非常重要：

• 團隊必須是自組織的。所有團隊元件必須管理自己的工作以完成已經給出的任務。在Agile Scrum中，沒有團隊負責人或直線經理的身影。每個人都必須做出足夠的承諾來開展自己的活動，併為團隊的成功做出貢獻。如果一個失敗，每個人都會失敗。
• 團隊必須是跨職能的。所有團隊成員必須擁有所有必需的知識和技能，以提供做得好並且隨時可用的服務或產品。專家可用於必要的案例，但僅作為教練將知識傳授給團隊以實現特定差距。
• 成為產品負責人需要企業願景。產品負責人代表客戶的聲音，需要將他們的需求轉化為Scrum Master和開發團隊。這通常是一份全職工作。
• Scrum Master不是直線經理。他們幫助向開發團隊提供所需的教練，並幫助消除團隊面臨的任何障礙。

Scrum工件

SCRUM工件用於幫助定義進入團隊並且當前正在團隊中工作的工作負載。還有更多的工件，例如，使用者故事，釋出積壓，燒錄圖表等。但我們將專注於核心三：

產品積壓 (Product Backlog)

產品待辦事項是使用者故事的集合，其呈現產品團隊所需/期望的功能。通常，產品所有者負責此列表。

Sprint積壓 (Spring Backlog)

Sprint積壓包含一系列可以包含在當前sprint中的故事。有關sprint積壓與將專案包含在sprint中之間關係的兩個要點需要注意。1）團隊決定新增到sprint的內容。因此，團隊負責交付這些物品的所有權和責任。2）在將專案從sprint backlog中刪除並新增到sprint之前，團隊必須確保他們擁有積壓中所需的所有資訊。通常，團隊定義在新增專案之前必須存在的專案清單。

產品Backlog與Sprint Backlog

在衝刺積壓是Scrum的衝刺過程中完成了由Scrum團隊確定的任務列表。在sprint計劃會議期間，團隊通常以使用者故事的形式選擇一些產品待辦事項，並確定完成每個使用者故事所需的任務，如下圖所示：

燒錄圖表 (Burndown Chart)

Burndown Chat 是剩餘工作與時間的圖形表示。突出的工作（或積壓工作）通常在垂直軸上，沿水平方向的時間。也就是說，這是一份傑出工作的執行圖表。它可用於預測何時完成所有工作。它通常用於敏捷軟體開發方法，如Scrum。但是，燒錄圖表可以應用於任何包含一段時間內可衡量進展的專案。傑出的工作可以用時間或故事點來表示。

Scrum活動

溝通是關鍵！SCRUM依賴於團隊的所有方面並且透明地工作（Scrum支柱＃1）。考慮到這種核心理念，該方法圍繞一系列關鍵事件構建，以確保其他兩個支柱：檢查和調整如下表所示：

注意：在執行每個sprint期間，Scrum中有五個主要會議，如下圖所示：

Sprint計劃

所有衝刺都從計劃開始。團隊需要確定並承諾將作為sprint的一部分交付哪些專案。可能的專案總是從Sprint Backlog中獲取，如下圖所示：

這是SCRUM主人可以發光的時間。產品所有者從業務/客戶的角度確定他們需要的方面，SCRUM團隊，確定他們認為可以提供哪些專案，以及SCRUM主人適應所有專案並確保滿足兩個方面的最佳要求。

每日Scrum會議 (Daily Scrum)

一旦團隊確定了他們承諾作為sprint的一部分交付的專案。該團隊將舉行每日站立會議。此次會議的核心目標是確保團隊中的每個人（以及可能的觀察員）完全瞭解正在完成的任務的狀態和進度：

• 他們做了什麼
• 他們今天要做什麼
• 什麼阻止他們

此每日更新向團隊提供例項反饋並提供。這些會議意味著簡短，每人不超過3分鐘。

注意：

觀察員在那裡觀察，SCRUM主人必須儘可能減輕外部干擾和團隊干擾。

Sprint評審會議 (Sprint Review)

在Sprint結束時舉行Sprint評審/演示會議以檢查增量。團隊根據完成定義演示增量，重點關注Sprint目標。產品負責人稽核並接受交付的增量。

Sprint回顧 (Sprint Retrospective)

衝刺回顧通常是衝刺中最後完成的事情。許多團隊將在衝刺審查後立即執行此操作。包括Scrum Master和產品所有者在內的整個團隊都應該參與其中。您可以安排scrum回顧展達一個小時，這通常是足夠的。回顧展讓團隊有機會確定3個關鍵方面：

1. 應該開始做什麼？
2. 什麼不順利（並再次停止做）？
3. 什麼進展順利（並且應該繼續做什麼？）？

這種方法的目的是不斷提高團隊效率。

積壓細化會議 (Product Backlog Refinement)

將積壓視為專案的路線圖。當團隊協作建立需要為專案完成構建或完成的所有事項的列表時，可以修改此列表並將其新增到整個專案中，以確保滿足專案的所有必要需求。

短跑 (Sprint)

在Scrum框架中，Scrum產品Backlog中實現條目所需的所有活動都在Sprint中執行（也稱為“Iterations”）。短跑總是很短：通常大約2-4周。每個Sprint都遵循一個定義的過程，如下所示：

如前所述，產品待辦事項中的專案按優先順序排序並選擇sprint backlog。一個sprint只包含幾個大專案，即使單個專案低估工作的影響也會對sprint產生深遠的影響。而且由於較大的專案往往難以估計和理解，因此短跑失敗的可能性會進一步增加。經驗豐富的Scrum團隊花費時間和精力將複雜和較大的專案（即使用者功能或史詩）分解為較小的使用者故事（或隨後分解為任務或子任務）。

Epic

Epic捕捉了大量的作品。它本質上是一個“大型使用者故事”，可以分解為許多小故事。完成史詩可能需要幾次衝刺。因此，當我們將epic用於開發時，它必須被分解為更小的使用者故事。

在專案週期的早期，我們提出了Epics。這些是非常高階的，幾乎以營銷為中心的功能性要點。

我們將大型故事稱為“史詩”，以傳達有關它們的資訊。我喜歡把這與電影有關。如果我告訴你一部特定的電影是一部“動作冒險電影”，它會告訴你有關電影的一些資訊。可能有一些汽車追逐，可能是一些射擊，等等。同樣，將一個故事稱為“史詩”有時可以傳達其他意義。

使用者故事 (User Story)

故事是產品要求或業務案例的簡要陳述。通常，故事用簡單的語言表達，以幫助讀者理解軟體應該完成的內容。產品所有者建立故事。然後，scrum使用者將故事分成一個或多個scrum任務。

使用者故事通常是終端使用者可見的功能。使用者故事遵循“我作為世界衛生組織想要做什麼”的格式，以便為什麼。使用者故事為客戶/使用者提供價值。這是客戶/使用者的產品要求。

例如“作為客戶，我希望能夠建立一個帳戶，以便我可以看到我去年購買的商品，以幫助我明年的預算。”

任務 (Task)

另一方面，任務更具技術性，任務通常類似於程式碼，設計，為此類建立測試資料，自動執行等等。這些往往是由一個人完成的事情。任務不是以使用者素材格式編寫的。任務更具技術性。

例如“評估使用者介面的角度材料設計”或“將應用程式提交到應用商店”。

最佳Scrum工具 

Scrum Process Canvas是一個用於幫助您管理Scrum專案的Scrum工具 - 從識別專案願景到最終產品交付。在一個設計精美的Scrum流程畫布中無縫導航整個Scrum流程。快速，輕鬆，無縫地執行Scrum活動。讓整個團隊充分參與。我們的敏捷軟體使敏捷專案變得簡單而有效。

其他Scrum閱讀

• 什麼是Scrum團隊？
• 什麼是Scrum工件？
• 什麼是5個Scrum值？
• 敏捷宣言和十二項原則
• Scrum中最經常提到的10個基本規則
• 什麼是Scrum的三大支柱？