Scrum 完整指南

Scrum 是一種專案管理框架，強調團隊合作、責任感以及朝著明確目標逐步推進。它從一個簡單的假設開始：從你所能看見或知道的事物開始。然後追蹤進度並依需要進行調整。

Scrum 的三大支柱

Scrum 建立在經驗主義之上，認為知識來自經驗，決策應基於已知的事實。這三大支柱將 Scrum 結合在一起。

為什麼選擇 Scrum？

Scrum 以逐步方式交付功能，而瀑布式開發僅在各階段交付。傳統的瀑布式開發是一種順序性、階段性的流程，價值直到專案結束才會交付。Scrum 透過每輪 Sprint（通常每 2–4 週）交付新功能，而非專注於未來的大規模發布，從而改變了這種模式。

Scrum 將複雜的工作分解為可管理的部分，將大型組織劃分為小型團隊，並將具有影響力的專案轉化為一系列短時間、有時限的Sprint.

透過迭代與增量式開發，企業可以更快、更有效地交付客戶真正需要的產品與服務。使用 Scrum，您可以在每個 Sprint 結束時接收並整合客戶反饋，這意味著您的成果是根據實際使用情境而非假設來塑造的。這使得讓客戶與關鍵利益相關者積極參與變得更容易。

敏捷 vs Scrum

敏捷 是一種實踐，可在整個軟體開發生命週期中實現持續迭代的開發與測試。敏捷將產品拆分成更小、可管理的元件。Scrum 只是眾多迭代與增量式敏捷軟體開發流程中的一種 讓我們能夠在最短時間內專注於交付商業價值。

Scrum 通常處理在專案初期可能變動或未知的需求。Scrum 的特徵包括：

• 輕量級
• 容易理解
• 難以掌握

Scrum 的優勢

以下是 Scrum 為組織、團隊、產品與個人帶來的優勢：

1. 更好的品質：有一套實現願景或目標的架構。Scrum 提供持續的反饋與透明度，以確保品質達到最高水準。Scrum 透過以下實踐來確保品質：
2. 縮短上市時間：Scrum 已證明能比傳統方法快 30%–40% 地為終端用戶交付價值。
3. 更高的投資回報率（ROI）：更短的上市時間是 Scrum 專案實現更高投資回報率的主要原因。早期收入與效益的累積意味著更高的總回報。這基於淨現值（NPV）計算的基本原則。
4. 更高的團隊士氣：與快樂且投入的個人合作是令人滿意且富有成效的。自我管理將原本由管理者或組織做出的決策交由Scrum團隊 成員。
5. 更強的團隊協作：當Scrum團隊負責專案與產品時，他們能夠取得優異成果。Scrum團隊透過提升參與度與溝通，進行協作，進而提升品質與專案表現。

Scrum架構

Scrum很簡單。它不是一組僵化且相互關聯的指令。Scrum並非一種方法論。Scrum體現了經驗主義的科學方法。它以啟發式方法取代程序化演算法的作法，尊重個人與自我組織，以應對不確定性並解決複雜問題。下圖展示了Scrum的實際運作，如Ken Schwaber與Jeff Sutherland在其著作《Scrum：在一半時間內完成兩倍工作的藝術》中所述，呈現從規劃到軟體交付的整個過程。

Scrum流程的組成部分

Scrum架構本身很簡單。它僅定義了幾項一般性指引，以及少量規則，角色, 產出物，以及活動。然而，這些組成部分各自對特定目的至關重要，也是成功運用此架構的必要條件。

Scrum架構的主要組成部分包括：

• Scrum角色: Scrum主管, 產品負責人，以及Scrum團隊
• 產出物: Sprint待辦事項清單, 產品待辦事項清單, 燃盡圖，日誌等
• Scrum活動: Sprint 計劃，Sprint 回顧，每日站會，Sprint 回顧，等等
• Sprint

下圖顯示了 Scrum 框架中的關鍵元素。該流程已使用 Visual Paradigm 的敏捷軟體工具中的Scrum 流程圖進行視覺化。

Scrum 角色

當組織採用 Scrum 時，首先要理解的是 Scrum 角色與傳統專案管理角色之間的差異。儘管 Scrum 中只有三個主要角色，但它們並不會自動對應到熟悉的職稱。讓我們先從每個角色的簡要定義開始：

產品負責人

產品負責人是負責代表業務或使用者社群的 Scrum 角色。他們與使用者密切合作，定義產品待辦事項中的功能。主要職責包括：

• 定義產品的願景與策略，包括短期與長期目標；
• 提供或收集有關產品或服務的知識；
• 理解並向開發團隊傳達客戶需求；
• 收集、優先排序並管理產品或服務的需求；
• 對產品或服務的預算負責，包括利潤；
• 決定產品或服務的發行日期；
• 每天與開發團隊一起回答問題並做出決策；
• 接受或拒絕 Sprint 完成的工作；
• 在每個 Sprint 結束時展示團隊的主要交付成果；
• 管理產品待辦事項。

Scrum 主管

Scrum 主管是敏捷開發團隊的促進者。Scrum 允許團隊根據敏捷原則自我組織並快速適應。Scrum 主管負責管理資訊流。主要職責：

• 擔任教練，協助團隊遵循 Scrum 的價值觀與實務；
• 協助排除障礙，並保護團隊免受外部干擾；
• 促進團隊與利益相關者之間的良好合作；
• 在團隊內促進常識與透明度；
• 保護團隊免受組織上的干擾。

Scrum 小組

Scrum 小組（也稱為開發小組）由 3 到 9 名成員組成，必須共同具備交付產品或服務所需的全部技術技能。他們由 Scrum 主管直接指導，但並非以傳統方式進行管理。他們必須具備自我組織、跨功能以及對完成所有必要任務負責的特質。

開發小組負責在每個 Sprint 結束時交付一個可發行的產品增量——涵蓋分析、設計、開發、測試和技術撰寫。Scrum 小組的重要特徵包括：

• 自我組織：所有成員自行管理自己的工作以完成分配的任務。在敏捷 Scrum 中，沒有團隊領導者或直屬經理。每個人必須投入足夠的精力來推動自身活動並為團隊的成功做出貢獻。若有一人失敗，所有人都會失敗。
• 跨功能：所有成員必須具備交付高品質、可發行產品所需的全部知識與技能。專家可被引入提供指導，但僅限於將知識傳授給團隊以彌補技能缺口。
• 產品負責人需具備商業願景：產品負責人代表客戶的聲音，必須將其需求轉化為可執行的項目，提供給 Scrum 主管與開發小組。這通常是一個全職角色。
• Scrum 主管並非直屬經理：他們協助指導開發小組，並消除阻礙進展的障礙。

Scrum 藝品

Scrum 藝品有助於定義即將進入團隊以及目前正在處理的工作。雖然還有更多藝品——例如使用者故事、發布待辦事項、燃盡圖——但這裡我們專注於核心三項：

產品待辦事項

產品待辦事項是一份按優先順序排列的使用者故事清單，代表產品團隊所需或預期的功能。通常由產品負責人維護此清單。

Sprint 待辦事項

Sprint 待辦事項包含一組在當前 Sprint 中需完成的選定項目。關於 Sprint 待辦事項與產品待辦事項之間的關係，有兩點需特別注意：
1. 團隊決定要加入 Sprint 的項目。因此，團隊擁有並對交付這些項目負責。
2. 在將項目從產品待辦事項移至 Sprint 待辦事項之前，團隊必須確保已掌握所有必要資訊。團隊通常會定義一項標準清單，項目在加入前必須符合這些條件。

產品待辦事項 vs Sprint 待辦事項
而 Sprint 待辦事項是 Scrum 小組承諾在 Sprint 中完成的任務清單。在 Sprint 規劃會議中，團隊通常會選擇幾個 產品待辦事項以使用者故事的形式，並確定完成每一項所需的任務，如下所示：

燃盡圖

燃盡圖是剩餘工作量隨時間變化的圖形化表示。剩餘工作（或待辦事項工作）顯示在垂直軸上，時間則沿水平軸排列。這是一張持續更新的待辦工作量圖表。可用來預測所有工作何時完成。它常見於敏捷軟體開發方法（如 Scrum）中，但也可應用於任何具有可衡量進度的專案。剩餘工作可按時間或 故事點.

Scrum 事件

溝通是關鍵！Scrum 依賴於所有方面的透明度（Scrum 原則 #1）。基於這一核心原則，該框架圍繞一系列關鍵活動建立，以確保另外兩個原則——檢視與調整，如下表所示：

活動	檢視	調整
Sprint 規劃	產品待辦事項清單 （承諾於 回顧) （定義為 完成)	Sprint 目標 預測 Sprint 待辦事項清單
每日站會	朝向 Sprint 目標的進展	Sprint 待辦事項清單 每日計畫
Sprint 回顧	產品增量 產品待辦事項清單（發行） 市場商業環境	產品待辦事項清單
Sprint 回顧	團隊協作 技術與工程實務 完成的定義	具體改進

注意：在每個 Sprint 中，Scrum 有五個關鍵會議，如下所示：

Sprint 計劃

每個 Sprint 都從規劃開始。團隊必須確定並承諾在 Sprint 中交付的內容。可能的項目總是從 Sprint 待辦事項中提取，如下所示：

這正是 Scrum Master 展現價值的地方。產品負責人從商業/客戶角度定義所需內容，Scrum 團隊決定他們認為自己能夠交付的內容，而 Scrum Master 則確保雙方的最佳契合。

每日 Scrum 會議

當團隊承諾將在 Sprint 中交付的內容後，他們會舉行每日站會。核心目標是確保每位團隊成員（以及可能的觀察者）完全了解工作的狀態與進展：

• 我昨天做了什麼？
• 我今天要做什麼？
• 什麼阻礙了我？

這每日更新為團隊提供了即時反饋。會議時間短暫——每人不超過 3 分鐘。

注意：觀察者僅為觀察而來。Scrum Master 必須盡量減少外部與內部的干擾。

Sprint 评审會議

Sprint 评审或演示在 Sprint 結束時舉行，用以檢視增量成果。團隊根據「完成定義」展示增量成果，聚焦於 Sprint 目標。產品負責人審查並接受已交付的增量。

Sprint 回顧

Sprint 回顧通常是 Sprint 中最後一項活動。許多團隊會在 Sprint 评审後立即進行。整個團隊——包括 Scrum Master 和產品負責人——都應參與。一個小時的回顧通常已足夠。此會議讓團隊反思：

1. 我們應該開始做什麼？
2. 我們應該停止做什麼？
3. 我們應該繼續做什麼？

目標是持續提升團隊效率。

待辦事項精煉

將產品待辦事項視為專案的路線圖。隨著團隊合作，他們會建立並更新完成專案所需的所有項目清單，確保所有必要需求都已滿足。

Sprint

在 Scrum 框架中，執行 Scrum 產品待辦事項中某項內容所需的所有活動，均在 Sprint 內完成（也稱為「迭代」）。Sprint 始終短暫——通常為 2 到 4 週。每個 Sprint 都遵循明確的流程，如下所示：

如前所述，產品待辦事項中的項目會被優先排序並選入 Sprint 待辦事項。一個 Sprint 只包含幾個主要項目——單一項目的工作量低估可能對 Sprint 產生重大影響。由於較大的項目通常更難估算與理解，Sprint 失敗的風險也隨之增加。經驗豐富的 Scrum 團隊會投入時間與精力，將複雜或大型項目（例如使用者功能或 Epic）分解為較小的使用者故事（或進一步拆解為任務或子任務）。

Epic

Epic 捕捉大量工作內容。它本質上是一個「大型使用者故事」，可進一步拆解為許多較小的故事。完成一個 Epic 可能需要多個 Sprint。因此，在開發中使用 Epic 時，必須將其分解為較小的使用者故事。

Epic 在專案生命週期早期引入。它們屬於高階、近乎行銷導向的功能要點。

我們將大型故事稱為「Epic」，以傳達其規模。這就像一部電影。如果我告訴你一部電影是「動作冒險片」，你就能預期到一些內容——例如車輛追逐、槍戰等。同樣地，將一個故事標記為「Epic」，有時也能傳達額外的背景資訊。

使用者故事

使用者故事是產品需求或商業案例的簡短陳述。通常以簡單語言撰寫，以幫助讀者理解軟體應具備的功能。產品負責人創建故事，然後 Scrum 團隊成員將故事拆解為一個或多個 Scrum 任務。

使用者故事通常是終端用戶可見的功能。它們遵循以下格式：「我想要[做某事]，以便[我可以達成某個目標]。」它們為客戶/用戶帶來價值。這是客戶的產品需求。

範例：「作為一位客戶，我想要建立帳戶，以便查看去年的購買紀錄，幫助我規劃明年的預算。」

任務

相反地，任務更具技術性。任務通常涉及程式碼、設計、建立測試資料、自動化等。這些通常是個人的責任。任務不會以使用者故事的格式撰寫，它們更具技術性。

範例：「使用材質設計評估UI角度」或「將應用程式提交至App Store。」