Scrum快速指南

---

---

Scrum - 概述

敏捷已成為軟體開發行業中流行的術語之一。但敏捷開發究竟是什麼？簡單來說，敏捷開發是執行軟體開發團隊和專案的一種不同方式。

為了理解新的方法，讓我們回顧一下傳統方法。在傳統的軟體開發中，產品需求在開始開發之前就已經確定。

瀑布模型

具有此特點最常用的軟體開發模型是瀑布模型，如下圖所示。但是，在大多數情況下，會新增新的功能，並且之前的需求也可能會發生變化。瀑布模型的結構不適合適應需求的持續變化。此外，使用者在產品完全可用之前，無法清楚瞭解產品的功能。

迭代增量模型

在迭代增量模型中，開發始於有限數量的已最終確定和優先排序的需求。交付成果是產品的可執行增量。從需求到程式碼開發的一系列活動稱為迭代。根據增量的功能以及任何或所有新的、修改的、待處理的需求，將下一批需求提供給後續迭代。後續迭代的結果是產品增強的可執行增量。重複此過程，直到產品完成所需的功能。

使用者通常不參與開發工作，這可能會導致溝通差距，從而導致功能錯誤。參與對開發團隊來說是積極的，但對團隊的時間要求很高，並且可能會導致延誤。此外，迭代期間任何非正式的需求變更都可能導致混淆，也可能造成範圍蔓延。基於此前提，敏捷開發應運而生。

敏捷開發

敏捷開發基於迭代增量開發，其中需求和解決方案透過團隊協作不斷發展。它推薦一個時間盒式的迭代方法，並鼓勵快速靈活地響應變化。它是一個理論框架，並沒有規定開發團隊應該遵循的任何特定實踐。Scrum是一個具體的敏捷過程框架，它定義了需要遵循的實踐。

敏捷方法的早期實現包括Rational Unified Process（1994）、Scrum（1995）、Crystal Clear、極限程式設計（1996）、自適應軟體開發、特性驅動開發（1997）和動態系統開發方法 (DSDM)（1995）。在2001年釋出敏捷宣言之後，這些方法現在統稱為**敏捷方法**。

敏捷宣言

敏捷宣言由一群軟體開發人員於2001年釋出，強調需要給予開發團隊、適應變化的需求、客戶參與的重要性。

敏捷宣言如下：

“我們正在透過實踐和幫助他人實踐來揭示更好的軟體開發方法。透過這項工作，我們已經開始重視：

• 個體和互動勝過過程和工具
• 可以工作的軟體勝過面面俱到的文件
• 客戶協作勝過合同談判
• 響應變化勝過遵循計劃

也就是說，雖然右項也具有價值，但是我們更重視左項。”

……敏捷軟體開發宣言，作者：Beck，Kent，等人 (2001)

敏捷宣言條目的定義

左側宣言條目可以描述如下：

敏捷宣言的關鍵要素是，我們必須信任人們及其協作能力。因此，開發的具體敏捷方法透過強調整個專案生命週期中的團隊合作來充分發揮團隊成員的能力。

敏捷的關鍵原則

敏捷宣言基於以下原則：

敏捷方法

動態系統開發方法 (DSDM)

這是一個用於軟體專案的敏捷框架。它用於微調傳統方法。DSDM 的最新版本稱為 DSDM Atern。Atern 這個名字是北極燕鷗 (Arctic Tern) 的縮寫——一種可以長途跋涉的海鳥，它代表了該方法的許多特性，這些特性是自然的工作方式，例如優先順序排序和協作。

Scrum

這是最流行的敏捷框架，它特別關注如何在基於團隊的開發環境中管理任務。Scrum 使用迭代增量開發模型，迭代時間較短。Scrum 相對易於實施，並專注於快速頻繁的交付。

極限程式設計 (XP)

這是一種敏捷軟體開發。它提倡在短開發週期中頻繁釋出，旨在提高生產力並在可以採用新的客戶需求的檢查點引入檢查點。該方法名稱來源於這樣一個理念：傳統軟體工程實踐的有益元素被提升到極致。(極限程式設計是一種軟體開發規範，它組織人員以更高效地生產更高質量的軟體。) XP 以新穎的方法解決分析、開發和測試階段的問題，這些方法對最終產品的質量產生了重大影響。

測試驅動開發 (TDD)

這是一種軟體開發過程，它依賴於非常短的開發週期的重複：首先，開發人員編寫一個自動測試用例來定義所需的改進或新功能，然後生成最少的程式碼來透過該測試，最後將新程式碼提升到可接受的標準。

精益

這是一種生產實踐，它認為將資源用於除為最終客戶創造價值以外的任何目標都是浪費，因此是消除的目標。從消費產品或服務的客戶的角度來看，“價值”被定義為客戶願意為之付費的任何行動或過程。精益的核心是用更少的工作來保留價值。

看板

這是一個用於改進和保持高水平生產的系統。看板是組織用來控制庫存成本的策略——準時制 (JIT)——實現的一種方法。看板成為支援整體執行生產系統的一種有效工具，並證明是促進改進的絕佳方式。

結論

在過去的10年中，越來越多的成功案例表明，公司透過敏捷實踐顯著提高了其 IT 開發團隊和專案的成功率和績效。這導致敏捷在各種行業中得到廣泛採用，包括媒體和技術、大型公司，甚至政府。

敏捷框架幫助團隊從以下方面獲益：

• 更快的交付/上市時間
• 減少不確定性和風險
• 透過關注客戶價值來提高投資回報率 (ROI)

在這些不同的敏捷方法中，Scrum 在過去的 20 年裡在全球範圍內被證明是非常成功的。

Scrum - 框架

Scrum 是一個用於開發和維護複雜產品的框架。Ken Schwaber 和 Jeff Sutherland 開發了 Scrum。他們共同支援 Scrum 規則。

Scrum 定義

Scrum 是一種框架，人們可以在其中解決複雜的適應性問題，同時高效且富有創造性地交付具有最高可能價值的產品。

Scrum 是一個流程框架，自 20 世紀 90 年代初以來一直用於管理複雜的產品開發。Scrum 不是構建產品的過程或技術；相反，它是一個框架，您可以在其中使用各種過程和技術。Scrum 使您能夠明確產品管理和開發實踐的相對有效性，以便您可以改進。

Scrum 框架由 Scrum 團隊及其相關的角色、事件、工件和規則組成。框架中的每個元件都有其特定的用途，對於 Scrum 的成功和使用至關重要。

Scrum 的規則將事件、角色和工件結合在一起，管理它們之間的關係和互動。Scrum 的規則將在本教程中詳細描述。

注意 - 在整個行業中，存在著一些誤解，認為 Scrum 意味著沒有文件，Scrum 團隊只由開發人員組成，等等。事實並非完全如此；我們將在後面的章節中對此進行澄清。

Scrum 流程框架

在 Scrum 中，規定的事件用於建立規律性。所有事件都是時間盒事件，即每個事件都有最長持續時間。這些事件將在後續章節中更詳細地描述。

衝刺

Scrum 的核心是衝刺，這是一個兩週或一個月的時限，在此期間會建立一個潛在的可釋出產品增量。新的衝刺在之前的衝刺結束後立即開始。衝刺包括衝刺計劃、每日站會、開發工作、衝刺評審和衝刺回顧。

• 在衝刺計劃中，Scrum 團隊會協作規劃衝刺中要執行的工作。

• 每日站會是一個 15 分鐘的時間盒事件，Scrum 團隊可以使用它來同步活動並制定當天的計劃。

• 衝刺評審在衝刺結束時舉行，以檢查增量並在需要時更改產品待辦事項。

• 衝刺回顧發生在衝刺評審之後，下一個衝刺計劃之前。在這個會議上，Scrum團隊需要進行自我檢查，並制定一個計劃，以便在隨後的衝刺中實施改進。

結論

Scrum是一個流程框架，它定義了某些規則、事件和角色來帶來規律性。但是，它可以根據需要適應任何組織，前提是不違反基本的Scrum規則。

Scrum - 角色

Scrum團隊由三個角色組成，分別是Scrum主管、產品負責人和團隊。

Scrum主管

Scrum主管（有時寫作Scrum Master，儘管官方術語在“Scrum”之後沒有空格）是Scrum流程的維護者。他/她負責：

• 使流程順利執行
• 消除影響生產力的障礙
• 組織和主持關鍵會議

產品負責人

產品負責人負責最大限度地提高產品價值和團隊的工作價值。如何在不同組織、Scrum團隊和個人之間實現這一點可能差異很大。

產品負責人是唯一負責管理產品待辦事項的人。產品待辦事項管理包括：

• 清晰地表達產品待辦事項。

• 對產品待辦事項進行排序，以最好地實現目標和任務。

• 最佳化團隊執行工作的價值。

• 確保產品待辦事項對所有人可見、透明和清晰，並顯示團隊將進一步開展的工作。

• 確保團隊理解產品待辦事項中所需級別的專案。

產品負責人可以自己完成上述工作，也可以讓團隊完成。但是，產品負責人仍然對這些任務負責。

產品負責人是一個人，而不是一個委員會。產品負責人可以在產品待辦事項中代表委員會的願望，但希望更改產品待辦事項優先順序的人必須與產品負責人聯絡。

為了讓產品負責人成功，整個組織必須尊重他或她的決定。產品負責人的決定體現在產品待辦事項的內容和排序中。任何人都不能告訴團隊根據不同的需求集工作，團隊也不允許按照其他任何人所說的去做。這是由Scrum主管來確保的。

團隊

團隊是自組織的和跨職能的。這意味著團隊根據專案需要和相關性，由分析師、設計師、開發人員、測試人員等組成。

業內一些人將這個團隊稱為開發團隊。然而，這種說法會導致爭議，即團隊只能有開發人員而沒有其他角色。顯然，這只是一個誤解。要開發軟體產品，我們需要所有角色，這就是Scrum的本質——團隊將協同工作。跨職能團隊擁有完成工作所需的所有能力，無需依賴團隊以外的人，從而可以節省時間和精力。Scrum中的團隊模型旨在最佳化靈活性和創造力以及生產力。

最佳團隊規模應足夠小，以保持靈活，又足夠大，可以在一個衝刺內完成大量工作。如果可能，團隊規模應保持在五到九人之間。少於五名團隊成員會減少互動，並導致生產力增益較小。超過九名成員需要過多的協調。

Scrum團隊每天緊密合作，以確保資訊順利流動並快速解決問題。Scrum團隊迭代地和增量地交付產品，最大限度地提高反饋機會。完整產品的增量交付確保始終可以使用潛在有用的工作產品版本。

Scrum - Scrum主管

Scrum主管是一位經過培訓的責任人，提供如下服務：

Scrum主管對產品負責人的服務

Scrum主管透過多種方式為產品負責人服務，包括：

• 尋找有效的待辦事項管理技術。

• 幫助Scrum團隊理解清晰簡潔的產品待辦事項的需求。

• 理解在經驗環境中的產品規劃。

• 確保產品負責人知道如何安排產品待辦事項以最大化價值。

• 理解和實踐敏捷性。

• 根據需要主持Scrum活動。

Scrum主管對Scrum團隊的服務

Scrum主管透過多種方式為Scrum團隊服務，包括：

• 指導Scrum團隊進行自我組織和跨職能工作。

• 幫助Scrum團隊建立高價值產品。

• 消除阻礙Scrum團隊進展的障礙。

• 根據請求或需要主持Scrum活動。

• 在尚未完全採用和理解Scrum的組織環境中指導Scrum團隊。

Scrum主管對組織的服務

Scrum主管透過多種方式為組織服務，包括：

• 領導和指導組織採用Scrum。

• 規劃組織內的Scrum實施。

• 幫助員工和利益相關者理解和實施Scrum和經驗性產品開發。

• 引起能夠提高Scrum團隊生產力的變化。

• 與其他Scrum主管合作，提高Scrum在組織中的應用有效性。

結論

Scrum是一個流程框架，它定義了某些規則、事件和角色來帶來規律性。但是，它可以根據需要適應任何組織，前提是不違反基本的Scrum規則。

Scrum - 事件

Scrum流程框架可以透過一系列事件和相應的工件來檢視。Scrum事件是限時事件。這意味著，在一個專案中，每個Scrum事件都有一個預定義的最大持續時間。這些事件使參與專案的所有人都能夠了解專案的進度。Scrum的重要事件包括：

• 衝刺
• 衝刺計劃
• 每日站會
• 衝刺評審
• 衝刺回顧

衝刺

在衝刺期間，將開發一個可工作的產品增量。它的持續時間通常為兩週或一個月，並且此持續時間對於專案中的所有衝刺保持不變。我們不能讓專案中不同衝刺的持續時間不同。在上一個衝刺結束之後，立即開始一個新的衝刺。

衝刺目標是為衝刺設定的目標。它為團隊提供指導，說明為什麼它要構建增量。它是在衝刺計劃會議期間建立的。隨著對需求的更多瞭解，衝刺的範圍在產品負責人和團隊之間得到澄清和重新協商。因此，每個衝刺都與它相關聯，定義了要構建的內容、設計以及將指導構建它的靈活計劃、開發工作和最終的產品增量。

如果衝刺目標變得過時，則應取消衝刺。如果組織改變方向，或者市場或技術條件發生變化，則可能會發生這種情況。衝刺只能由產品負責人取消，儘管其他人也會對此產生影響。

由於衝刺的持續時間較短，在衝刺期間取消衝刺很少有意義。由於衝刺取消會消耗資源，以便重新組織到另一個衝刺中，因此它們非常少見。

如果衝刺被取消，並且衝刺期間產生的部分工作可能釋出，則產品負責人通常會接受它。所有未完成的衝刺待辦事項都將放回產品待辦事項中。

衝刺計劃

在衝刺計劃會議中計劃在衝刺中要執行的工作。衝刺計劃會議對於兩週的衝刺最多持續四個小時，對於一個月的衝刺最多持續八個小時。Scrum主管有責任確保會議舉行，並且所有必需的與會者都出席並瞭解預定會議的目的。Scrum主管主持會議，以監控討論的持續時間和按時結束。

衝刺計劃側重於以下兩個問題：

• 在衝刺增量中需要交付什麼以及可以交付什麼？
• 如何完成衝刺執行所需的工作？

此會議的輸入是：

• 產品待辦事項
• 最新的產品增量
• 衝刺期間團隊的預計產能
• 團隊過去的績效

Scrum團隊討論在衝刺期間可以開發的功能。產品負責人提供關於產品待辦事項的說明。團隊從產品待辦事項中為衝刺選擇專案，因為他們是評估他們在衝刺中可以完成哪些工作的最佳人選。團隊由分析師、設計師、開發人員和測試人員組成。工作以協作的方式進行，從而最大限度地減少返工。

然後，Scrum團隊提出衝刺目標。衝刺目標是一個目標，它為團隊提供指導，說明為什麼它要構建產品增量。然後，團隊決定如何在衝刺期間將選定的功能構建到可工作的產品增量中。為本次衝刺選擇的待辦事項加上交付它們的計劃，稱為衝刺待辦事項。

衝刺期間的工作在衝刺計劃期間進行估算，其規模和/或工作量可能不同。在衝刺計劃會議結束時，工作被劃分為持續時間為一天或更短的任務。這是為了方便工作分配和跟蹤完成情況。如果團隊意識到工作過多或過少，它可以與產品負責人重新協商選定的產品待辦事項。

團隊還可以邀請其他人（不是Scrum團隊成員）參加衝刺計劃會議，以獲取技術或領域方面的建議或估算方面的幫助。

每日站會

每日站會是團隊的 15 分鐘會議，每天舉行一次，以快速瞭解自上次每日站會以來的工作，併為接下來的 24 小時制定計劃。此會議也稱為每日站立會議。

每日站會每天在同一時間和同一地點舉行，以降低複雜性。

在會議期間，每個團隊成員都會解釋：

• 他昨天做了什麼來幫助團隊實現衝刺目標？

• 他今天將做什麼來幫助團隊實現衝刺目標？

• 他是否看到任何障礙阻止他或團隊實現衝刺目標？

每日站會被誤認為是狀態跟蹤事件，但實際上它是一個計劃事件。

會議的輸入應該是團隊在實現衝刺目標方面的工作進展情況，而輸出應該是最佳化團隊在實現衝刺目標方面的努力的新計劃或修改後的計劃。

雖然 Scrum 主管協調每日站會並確保會議目標得到滿足，但會議由團隊負責。

如有必要，團隊可在每日站會後立即進行任何詳細討論，或重新規劃衝刺剩餘的工作。

以下是每日站會的益處：

• 改善團隊內部溝通。

• 識別任何障礙，以便及早消除，從而最大限度地減少對沖刺的影響。

• 突出並促進快速決策。

• 提高團隊的知識水平。

衝刺評審

衝刺評審在每個衝刺結束時舉行。在衝刺評審期間，將審查即將釋出的增量的演示。在這個會議上，Scrum團隊和利益相關者合作瞭解在衝刺中完成了什麼工作。基於此，以及衝刺期間產品待辦事項的任何變更，與會者確定所需的下一步，這些步驟可以最佳化價值。因此，衝刺評審的目的是獲得反饋並團結一致地取得進展。

對於兩週的衝刺，衝刺評審通常持續兩小時；對於一個月的衝刺，通常持續四小時。

Scrum主管確保：

• 會議按時舉行。

• 參與者理解會議目的。

• 會議集中於既定議程，並在規定時間內完成。

衝刺評審包括以下方面：

• 與會者包括Scrum團隊和產品負責人邀請的主要利益相關者。

• 產品負責人解釋在衝刺期間完成了哪些產品待辦事項，以及哪些未完成。

• 團隊討論衝刺期間進展順利之處、遇到的問題以及如何解決這些問題。

• 團隊演示已完成的工作，並解答關於增量的任何問題。

• 然後，全體人員討論下一步該做什麼。因此，衝刺評審為後續衝刺的衝刺計劃提供了寶貴的輸入。

• 然後，Scrum團隊審查產品增量下一次預期釋出的時間表、預算、潛在能力和市場。

• 衝刺評審的結果是更新後的產品待辦事項，它定義了下一個衝刺可能包含的產品待辦事項。

衝刺回顧

衝刺回顧在衝刺評審之後和下一個衝刺計劃之前進行。對於兩週的衝刺，這通常是一個小時的會議；對於一個月的衝刺，通常是一個三小時的會議。

衝刺回顧的目的是：

• 結合上次衝刺中關於人員、關係、流程和工具的經驗教訓。

• 確定進展順利的主要方面和潛在的改進之處。

• 制定實施改進以提高產品質量的計劃。

衝刺回顧是Scrum團隊進行內省和在Scrum流程框架內改進的機會，以便使下一個衝刺的結果更有效。

參考文獻

Scrum指南 © 1991-2013 Ken Schwaber 和 Jeff Sutherland，版權所有。

Scrum - 工件

Scrum工件提供Scrum團隊和利益相關者需要了解的關於正在開發的產品、已完成的活動和專案中計劃的活動的關鍵資訊。Scrum流程框架中定義了以下工件：

• 產品待辦事項
• 衝刺待辦事項
• 燃盡圖
• 增量

這些是Scrum專案中最低限度需要的工件，專案工件並不僅限於這些。

產品待辦事項

產品待辦事項是作為最終產品一部分所需功能的有序列表，它是對產品進行任何更改的唯一需求來源。

產品待辦事項列出了所有構成未來版本產品更改的功能、特性、需求、增強功能和修復。產品待辦事項具有描述、順序、估算和價值等屬性。這些專案通常被稱為使用者故事。產品負責人負責產品待辦事項，包括其內容、可用性和排序。

產品待辦事項是一個不斷發展的工件。其最早的版本可能只包含最初已知和最容易理解的需求。隨著產品及其使用環境的進步，產品待辦事項也會得到發展。產品待辦事項不斷變化以包含使其有效所需的內容。只要產品存在，其產品待辦事項也存在。

隨著所構建產品的應用和價值的提升，產品待辦事項將成為一個更大、更詳盡的列表。業務需求、市場條件或技術的改變會導致產品待辦事項的改變，使其成為一個動態的工件。

產品待辦事項細化意味著向產品待辦事項新增細節、估算和優先順序順序。這是由產品負責人和團隊執行的持續過程。Scrum團隊決定如何以及何時進行細化。

產品負責人或經產品負責人同意，可以隨時更新產品待辦事項。

較高順序的產品待辦事項通常比較低順序的產品待辦事項更清晰、更詳細。基於更高的清晰度和更詳細的資訊，可以做出更精確的估計。順序越低，細節越少。

可能成為即將到來的衝刺的候選需求的產品待辦事項會被細化，以便這些專案可以在衝刺期間得到開發。團隊可以在一個衝刺內完成開發的產品待辦事項被認為已準備好用於衝刺計劃會議中進行選擇。

衝刺待辦事項

衝刺待辦事項是為衝刺選擇的 Product Backlog 專案的集合，加上交付產品增量和實現衝刺目標的計劃。

衝刺待辦事項是團隊對將在下一個增量中提供的功能以及將該功能交付為可工作的產品增量所需工作的預測。

衝刺待辦事項是一個足夠詳細的計劃，團隊可以在每日站會中理解並跟蹤。團隊在整個衝刺過程中修改衝刺待辦事項，並且衝刺待辦事項在衝刺過程中逐漸形成。這種形成發生在團隊完成計劃並更多地瞭解實現衝刺目標所需的工作時。

當需要新的工作時，團隊將其新增到衝刺待辦事項中。當工作正在執行或完成時，剩餘工作的估算會被更新。當計劃中的某些元素被認為是不必要的時，它們就會被刪除。在衝刺期間，只有團隊才能更改其衝刺待辦事項。衝刺待辦事項是團隊計劃在衝刺期間完成的工作的清晰可見的即時畫面，它完全屬於團隊。

增量

增量是衝刺期間完成的所有產品待辦事項的總和，以及所有先前衝刺的增量的總和。在一個衝刺結束時，新的增量必須是一個可工作的產品，這意味著它必須處於可用的狀態。無論產品負責人是否決定實際釋出它，它都必須處於可工作狀態。

Scrum團隊需要就什麼是增量達成共識。這在每個Scrum團隊中差異很大，但是，團隊成員必須對完成工作意味著什麼有一個共同的理解。這用於評估產品增量上的工作何時完成。

同樣的理解指導團隊瞭解在衝刺計劃期間可以選擇多少產品待辦事項。每個衝刺的目的都是交付潛在可釋出功能的增量。

團隊每個衝刺都會交付一個產品功能增量。這個增量是可用的，因此產品負責人可以選擇立即釋出它。如果增量的理解是開發組織的約定、標準或指南的一部分，則所有Scrum團隊都必須至少遵循它。如果它不是開發組織的約定，則Scrum團隊必須定義適合該產品的增量定義。

每個增量都是對所有先前增量的補充，並且經過徹底測試，確保所有增量都能一起工作。

隨著Scrum團隊的成熟，預計他們對增量的定義將擴充套件到包括更嚴格的更高質量標準。任何一個產品都應該有一個增量定義，作為對其進行的任何工作的標準。

衝刺燃盡圖

在衝刺的任何時間點，都可以對沖刺待辦事項中剩餘的總工作量進行彙總。團隊跟蹤每次每日站會的剩餘總工作量，以預測實現衝刺目標的可能性。透過在整個衝刺期間跟蹤剩餘的工作，團隊可以管理其進度。

衝刺燃盡圖是追蹤Scrum團隊所花費的工作量的實踐。這已被證明是監控衝刺朝衝刺目標前進的有用技術。

產品負責人至少在每次衝刺評審時跟蹤此剩餘總工作量。產品負責人將此數量與先前衝刺評審中剩餘的工作量進行比較，以評估在目標所需時間之前完成預計工作的進度。此資訊將與所有利益相關者共享。

結論

Scrum的角色、事件、工件和規則是不可避免的。如果只實施Scrum的某些部分，結果就不是Scrum。Scrum需要完整地實施，如果與其他技術、方法和實踐相結合，則功能良好。

參考文獻

Scrum指南 © 1991-2013 Ken Schwaber 和 Jeff Sutherland，版權所有。

Scrum - 使用者故事

正如您所瞭解的，使用者故事通常用於描述產品功能，並將構成Scrum工件的一部分——**產品待辦事項**和**衝刺待辦事項**。

使用者故事

在軟體開發中，產品功能起著至關重要的作用。正是這些功能終端使用者希望在最終產品中使用的功能。在一般術語中，它們被稱為需求。軟體開發專案的成功在於準確和適當地理解使用者需求，然後在最終產品中實現這些需求。因此，開發專案團隊需要充分了解需求或產品功能。

1999年，肯特·貝克提出了“使用者故事”來描述產品功能。他指出，使用者故事是從使用者的角度出發，描述使用者想要什麼，而不是系統能為他做什麼。因此，視角徹底從產品轉向了使用者，“使用者故事”成為了所有敏捷框架中需求的實際標準。

在Scrum專案中，產品待辦事項列表是一個使用者故事的清單。這些使用者故事會被優先順序排序，並在衝刺計劃會議中納入衝刺待辦事項列表。

估算也基於使用者故事，產品規模以使用者故事點來估算。

使用者故事結構

使用者故事的結構如下：

作為一個 <使用者型別>，

我想要 <執行某個任務>，

以便 <我可以實現某個目標/好處/價值>。

讓我們看看如何為銀行客戶從ATM取款的場景構建使用者故事。

使用者故事：客戶取款

作為一個 客戶，

我想要 從ATM取款，

以便 我不必在銀行排隊等候

使用者故事驗收標準

每個使用者故事都定義了驗收標準，以便透過基於驗收標準的驗收測試來確認使用者故事的實現是否正確。

以下是客戶取款使用者故事示例的驗收標準：

驗收標準1

已知賬戶信用良好

• 並且卡有效
• 並且出鈔機中有現金，

當客戶請求取款時

則確保賬戶已扣款

• 並確保現金已發出
• 並確保卡已返回。

驗收標準2

已知賬戶透支

• 並且卡有效

當客戶請求取款時

則確保顯示拒絕訊息

• 並確保未發出現金
• 並確保卡已返回。

編寫使用者故事

產品負責人負責產品待辦事項列表，也負責使用者故事。但這並不意味著只有產品負責人才能編寫使用者故事。Scrum團隊中的任何人都可以編寫使用者故事，並且隨著需求的細化和新功能的新增，這項活動可以在整個專案中展開。

使用者故事中的非功能性需求

也可以將非功能性需求納入使用者故事。在給定的ATM示例中，ATM需要全天候（24x7，365天）可用是一個非功能性需求，可以用用例來描述。

管理使用者故事

使用者故事在產品待辦事項列表中進行管理。使用者故事按優先順序排序。優先順序最高的使用者故事會被細化到粒度級別，而優先順序最低的使用者故事則保持較低的細節級別。對於每個衝刺，優先順序最高，因此粒度也更高的使用者故事會被納入衝刺待辦事項列表。如果要向產品待辦事項列表新增使用者故事，則首先確定其優先順序，然後根據其優先順序將其放置在相應位置。使用者故事可以隨時重新排序優先順序。如果需要，也可以刪除任何使用者故事。

使用者故事的好處

• 使用者故事的主要好處在於其以使用者為中心的定義。這是因為最終將使用該產品的是在相關使用者場景中使用該產品的使用者。它將終端使用者與團隊成員聯絡起來。

• 使用者故事的語法本身確保捕獲使用者想要實現的目標、好處或價值。

• 由於驗收標準本身就是使用者故事的一部分，因此對Scrum團隊來說將是一個額外的好處。

• 可以在專案執行過程中更改使用者故事。如果使用者故事的範圍變得很大，則需要將其分解成更小的使用者故事。驗收標準中的條件也可以更改。

• 由於在每個衝刺結束時都會向用戶交付可工作的產品增量，因此Scrum團隊可以在衝刺評審會議上獲得使用者的反饋。這使得能夠持續地將反饋納入產品中。

結論

Scrum的使用者故事使使用者更貼近Scrum團隊，並避免了最後一刻的意外。

Scrum - 燃盡圖

衝刺跟蹤通常使用燃盡圖來完成。燃盡圖顯示剩餘工作量（以每天的小時數表示）。例如，讓我們考慮一個為期兩週的衝刺：

衝刺時長：2周

每週天數: 5

每天小時數: 6

資源數量: 6

因此，衝刺開始時總剩餘工作量為2*5*6*6 = 360小時。

因此，在理想情況下，剩餘工作量每天減少36小時，燃盡圖如下所示：

如果衝刺工作按計劃每天完成，則Scrum進度幾乎與理想曲線一致。

如果衝刺工作延誤且未達到時間承諾，則燃盡圖如下所示：

但是，由於燃盡圖是每天繪製的，並且可以儘早發現進度偏差，因此可以採取糾正措施來滿足衝刺時間線。假設團隊加班以滿足時間線，則燃盡圖如下所示：

因此，在衝刺中的任何時間點，都可以直觀地瞭解衝刺中剩餘的總工作量，並可以提高滿足衝刺時間線的可能性。

結論

燃盡圖幫助Scrum團隊跟蹤其進度以及為實現衝刺目標需要做什麼。

Scrum - 估算

在Scrum專案中，估算由整個團隊在衝刺計劃會議期間完成。估算的目標是根據優先順序和團隊在衝刺時間框內交付的能力來考慮衝刺的使用者故事。

產品負責人確保優先順序高的使用者故事清晰明瞭，可以進行估算，並將它們放在產品待辦事項列表的開頭。

由於Scrum團隊整體負責交付產品增量，因此會注意根據產品增量的規模和所需的工作量來選擇衝刺的使用者故事。

產品增量的規模以使用者故事點來估算。一旦確定了規模，就可以透過過去的資料（即每個使用者故事點的努力，稱為生產力）來估算工作量。

Scrum估算技術

Scrum對使用者故事的估算以每個使用者故事的難度程度為基礎。為了評估難度程度，使用特定的量表。

Scrum估算中使用了幾種型別的量表。以下是一些示例：

• 數值大小（1到10）
• T恤尺寸（XS、S、M、L、XL、XXL、XXXL）
• 斐波那契數列（1、2、3、5、8、13、21、34，等等）
• 犬種（吉娃娃……大丹犬）

通常選擇估算技術的方式是使整個Scrum團隊熟悉並習慣於量表的值。最常用和最流行的技術是基於斐波那契數列的計劃撲克。

計劃撲克技術

在計劃撲克估算技術中，透過玩計劃撲克來獲得使用者故事的估算值。整個Scrum團隊都參與其中，這使得估算速度快且可靠。

計劃撲克使用一副牌進行。由於使用斐波那契數列，因此牌上的數字為1、2、3、5、8、13、21、34等。這些數字代表故事點。每個估算者都有一副牌。當團隊成員舉起一張牌時，牌上的數字應該足夠大，以便所有團隊成員都能看到。

團隊成員中的一位被選為主持人。主持人閱讀正在進行估算的使用者故事的描述。如果估算者有任何疑問，產品負責人將回答。

每個估算者私下選擇一張代表其估算值的牌。在所有估算者都做出選擇之前，不顯示牌。那時，所有牌同時翻轉並舉起，以便所有團隊成員都能看到每個估算值。

在第一輪中，估算值很可能會有差異。估算值最高和最低的估算者解釋其估算值的原因。應注意，所有討論都僅用於理解，任何內容都不應被個人化。主持人必須確保這一點。

團隊可以討論故事及其估算值幾分鐘。

主持人可以記錄討論內容，這在開發特定故事時會有所幫助。討論結束後，每個估算者透過再次選擇一張牌來重新估算。牌再次保密，直到每個人都估算完畢，然後同時翻轉。

重複此過程，直到估算值收斂到可以用於故事的單個估算值。估算輪數可能因使用者故事而異。

計劃撲克估算的好處

計劃撲克結合了三種估算方法：

專家意見：在基於專家意見的估算方法中，會詢問專家某項工作需要多長時間或規模有多大。專家根據其經驗、直覺或直覺提供估算值。

專家意見估算通常不需要花費太多時間，並且與某些分析方法相比更準確。

類比：類比估算使用使用者故事的比較。待估算的使用者故事與之前實現的類似使用者故事進行比較。由於估算基於已驗證的資料，因此會產生準確的結果。

分解：分解估算透過將使用者故事分解成更小、更容易估算的使用者故事來完成。包含在一個衝刺中的使用者故事通常需要兩到五天時間來開發。因此，可能需要較長時間的使用者故事需要分解成更小的用例。這種方法還確保會有許多可比較的故事。

結論

計劃撲克是一種令人愉快且高效的估算方法。由於在得出最終估算值之前會議是開放討論的，因此團隊很容易達成共識，並對所處理的使用者故事的實現有一個廣泛的瞭解。

Scrum - 工具

Scrum工具有助於Scrum專案的計劃和跟蹤。它們提供了一個集中管理產品待辦事項列表、衝刺待辦事項列表、計劃和跟蹤衝刺、顯示燃盡圖、進行每日Scrum會議和進行Scrum回顧的地方。

有許多不同型別的Scrum工具可用。有些是免費的（開源），有些是付費的，還有一些可以獲得工具的精簡版。但是，要獲得所有功能和可擴充套件性，則需要購買完整版。

可用的Scrum工具

以下是截至目前市場上一些Scrum工具的列表。開源工具用星號(*)標記。

結論

敏捷方法總體上，Scrum方法具體上，並不意味著沒有文件工作。Scrum工件已被定義，Scrum規劃和跟蹤也已完善。

Scrum工具有助於捕獲和跟蹤有關Scrum專案的資訊。工具的選擇取決於組織所需的功能，以及對任何其他工具的需求。

Scrum - 優勢

Scrum支援客戶、團隊成員和相關利益干係人之間的持續協作。其時間盒方法和來自產品負責人的持續反饋確保始終提供具有基本功能的可用產品。此外，Scrum為專案中的不同角色提供了不同的益處。

客戶收益

Sprint持續時間較短，每次Sprint計劃都會優先處理使用者故事。它確保每次Sprint交付時都包含客戶立即需要的功能。此外，如果客戶提出任何變更請求，它將被吸收到當前Sprint中，或包含在下一個Sprint中。因此，開發團隊能夠快速響應客戶的需求。

組織收益

組織可以專注於開發優先順序使用者故事所需的工作，從而減少額外開銷和返工。由於Scrum為客戶帶來的特定好處，開發團隊效率提高，客戶滿意度提高，因此可以實現客戶留存和客戶推薦。它增加了組織的市場潛力。

產品經理收益

產品經理在專案中扮演產品負責人的角色。產品負責人的職責是確保客戶滿意度。由於Scrum促進了快速響應、工作優先順序排序和吸收變更，產品經理可以輕鬆確保工作符合客戶需求，進而確保客戶滿意度。

專案經理收益

專案經理在專案中扮演Scrum Master的角色。Scrum的協作性質促進了輕鬆而具體的規劃和跟蹤。使用燃盡圖來了解剩餘工作，以及每日Scrum會議讓專案經理始終了解專案的進度。這種意識對於監控專案以及快速發現和解決問題至關重要。

開發團隊收益

由於Sprint的時間盒性質以及在每個Sprint結束時交付可工作的產品增量，開發團隊會熱情地看到他們的工作立即得到應用。內建的團隊協作使團隊享受他們所做的工作。由於每個Sprint的使用者故事都基於客戶優先順序，團隊也瞭解他們的工作是有價值的。

Scrum - 認證

Scrum認證由Scrum聯盟提供。提供的認證包括：

• 認證Scrum Master (CSM)
• 認證Scrum產品負責人 (CSPO)
• 認證Scrum從業者 (CSP)
• 認證Scrum教練 (CSC)
• 認證Scrum培訓師 (CST)

認證Scrum Master (CSM)

認證Scrum Master是成為Scrum聯盟成員、扮演Scrum Master角色以及獲得其他認證的基礎認證。該認證需要參加CSM課程。之後，候選人會收到一封電子郵件，其中詳細說明Scrum會員資格和CSM線上考試的詳細資訊。參加考試後，候選人將獲得認證Scrum Master (CSM) 認證。

認證Scrum產品負責人 (CSPO)

認證Scrum產品負責人是成為Scrum聯盟成員、扮演產品負責人角色以及獲得其他認證的基礎認證。

認證Scrum從業者 (CSP)

認證Scrum從業者是面向經驗豐富的Scrum Master和產品負責人的認證。候選人應至少擔任一年Scrum Master或產品負責人。候選人必須提交一份申請，其中包含對其在指定角色中所做工作的詳細描述。

如果候選人積極從事Scrum Master角色或產品負責人角色達規定時間，則可以在獲得CSM認證或CSPO認證後立即獲得CSP認證。

認證Scrum教練 (CSC)

認證Scrum教練是面向專注於教練的人員的認證。該認證要求候選人在過去5年中至少指導Scrum團隊採用和掌握Scrum 1500小時。

認證Scrum培訓師 (CST)

認證Scrum培訓師是面向想要教授CSM或CSPO課程的人員的認證。申請人必須擁有CSM或CSPO認證，並且在申請前至少擔任一年CSP。

Scrum - 常見問題

以下是關於Scrum的一些常見問題：

問題：Scrum和敏捷開發有什麼區別？

答案：敏捷開發是一種軟體方法，而Scrum是遵循敏捷的一種流程框架。

問題：Sprint和迭代是一樣的嗎？

答案：Scrum的Sprint和迭代增量模型的迭代都會交付可工作的產品增量。但是，它們的區別在於：

• Sprint和迭代的生命週期不同。
• Sprint是時間盒的，而迭代不是。
• Sprint的持續時間比迭代的持續時間短得多。

問題：Scrum Master是一個職位名稱，還是一個現有職位的人員擔任的角色？

答案：Scrum Master是一個現有職位的人員擔任的角色。通常的做法是，擔任專案經理角色的人也擔任Scrum Master的角色。

問題：產品負責人和Scrum Master的角色可以由同一個人擔任嗎？

答案：不可以，因為所有權不同。產品負責人負責產品待辦事項、使用者故事的優先順序排序以及使用分配給Sprint的使用者故事驗證可工作的產品增量。

問題：Scrum專案不需要任何文件嗎？

答案：不是的。Scrum專案，像任何其他專案一樣，需要文件，例如使用者故事、設計、測試用例等。

結論

敏捷和Scrum並不相同。Scrum是採用敏捷的一種流程框架。建議經驗豐富的團隊成員使用Scrum，因為該框架需要大量的協作和自我組織。如果嚴格遵守Scrum規則，專案可能會失敗。因此，整個團隊必須充分理解Scrum的概念。由於Sprint持續時間短且是時間盒的，即使Scrum Master持續監控專案，也沒有時間在工作中學習Scrum的細節。