最熱門的敏捷開發方法 — Scrum 框架簡介

2024/07/29閱讀時間約 10 分鐘

最熱門的敏捷開發方法 — Scrum 框架

引言

在當今快速變化的環境中，組織回應變化的能力愈發重要。傳統「瀑布式」(Waterfall) 和「循序」(Sequential) 的產品開發方法在應對快速的市場變化和模糊的客戶需求時往往顯得僵化，因此，「敏捷開發」（Agile Development）成為近二十多年來全球新創、科技產業開發產品與服務的首選。

敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024 年 7 月 LeSS (Large-Scale Scrum, 大規模 Scrum) 網站發布了新一版的《Scrum 指南》(Scrum Guide — LeSS Version) ，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。

敏捷開發的概念

敏捷開發是一種透過短週期開發和頻繁交付「可用的軟體」(Working Software) 來快速滿足市場與客戶需求、適應挑戰與變化，並持續改善產品與流程的軟體開發「哲學」(Philosophy) 和「理念」(Principles)。

敏捷開發不是一套特定的產品開發流程，也不是能夠立即提高產能的神奇方法。但如果你身處變化快速的市場或環境，並認同「提升團隊適應變化的能力才能提高組織的競爭力」，那麼敏捷開發的精神與實踐方法絕對值得你深入了解。

敏捷軟體開發宣言

Scrum 框架的起源

Scrum 框架是敏捷開發的一種具體實踐方法，名稱源於橄欖球運動中團隊合作爭球的動作。1986年，這個術語被日本學者竹內弘高和野中郁次郎首次使用於學術論文中，他們將成功的產品開發團隊比喻為在動態環境中爭球、推進的橄欖球隊。

後來，美國軟體開發顧問 Ken Schwaber 和 Jeff Sutherland 在 1990 年代初期將這個概念引入軟體開發領域，並創建了 Scrum 框架。兩人於 2001 年參與起草《敏捷宣言》(Agile Manifesto)，推動敏捷開發成為業界主流。

由於 Scrum 框架簡單易懂，並經過多年來業界的實踐與改進，現在已成為全球最廣泛應用的敏捷開發實踐方法，許多人甚至誤以為「Scrum」就是敏捷開發。

Scrum 框架的理論支柱

Scrum 框架基於「經驗主義」(Empiricism) 而設計。「經驗主義」主張知識來自實驗，並應基於觀察實證的結果進行決策。因此，Scrum 融合了「迭代開發」(Iterative Development) 及「增量開發」(Incremental Development) 的開發方式，以儘早發掘產品開發的風險，並逐步提升團隊的適應能力。

Scrum 框架之所以能夠達成敏捷開發的效益，有賴於在流程與產品上透過以下三個理論支柱進行改善：「透明」(Transparency)、「檢視」(Inspection) 和「調適」(Adaptation)。唯有讓流程與產品的相關資訊達到一定程度的透明，團隊才能進行有效的檢視。而唯有透過有紀律的檢視，團隊才能及時在流程與產品上進行調適。

Scrum 框架的三種角色

在 Scrum 框架中，一個基本產品開發團隊的大小通常保持在 10 人以下，以提高成員們頻繁溝通、密切合作的可能性。若有較多成員共同進行產品開發，應將團隊拆分為適當的大小，以兼顧每個團隊的靈活度及生產力。

作為敏捷開發的框架，Scrum 定義了以下三種角色：

1. 團隊 (Team)

Scrum 團隊應是「跨職能」(cross-functional) 的，包含負責設計、開發、測試工作的成員，通常由 4~8 人組成。團隊擁有「決定如何實現產品需求」的權力，並被授權進行「自我管理」(Self-Managing)：在每個迭代開始後自行決定誰做什麼、何時做、如何做，並自行監控、管理過程與進度。

2. 產品負責人 (Product Owner, PO)

產品負責人負責發展並傳達產品願景、釐清產品需求，並確保團隊的工作成果能最大化地提升產品價值。產品負責人擁有「決定產品需求優先順序」的權力，同時負有「清楚說明產品需求價值」的責任。產品負責人應由一個「個人」擔任，但可將部分工作委任給他人。即使工作已委任，產品負責人最終仍須為執行結果負責。

3. Scrum Master (SM, 通常不翻譯為中文)

Scrum Master 負責引導團隊實施 Scrum、確保流程順利進行，並移除影響團隊的阻礙。這個角色沒有決策權，因此需透過「幫助每個人理解 Scrum 理論並建立具體實踐的方法」來發揮影響力，通常會由團隊中的一員來兼任。若 Scrum Master 對 Scrum 框架及敏捷精神認識不足，可能會讓 Scrum 的導入淪為形式，甚至成為辦公室的政治災難。

Scrum 框架的三種角色

Scrum 框架的流程與事件

衝刺期 (Sprint, 亦常被譯為「衝刺」)

Scrum 框架中以衝刺期作為迭代與增量開發的核心概念，顧名思義就是讓團隊全力以赴達成目標的一段時間。衝刺期通常為 1～4 週的固定長度，以便團隊可以有穩定的開發節奏，並能以實驗的方式控制變因來改善工作流程或產品功能。

每個衝刺期包含以下五種事件：

1. 衝刺計劃會議 (Sprint Planning)

在衝刺期開始時，團隊會與產品負責人訂定目標，規劃希望在衝刺期內達成的產品需求，再將各需求拆解為工作清單，以完成當前衝刺期的準備工作。

2. 每日短會 (Daily Scrum)

衝刺期開始後，團隊成員每日召開不超過 15 分鐘的短會，讓團隊成員有機會根據實際工作狀況動態調整任務分配，以期達成原定的衝刺目標。

3. 衝刺審查會議 (Sprint Review)

在衝刺期結束時，團隊會透過衝刺審查會議向利害關係人展示工作成果、收集回饋，並討論達成產品願景及目標的進展狀況。

4. 衝刺自省會議 (Sprint Retrospective)

衝刺自省會議安排在衝刺期結束後，用以讓團隊檢視整個衝刺期的執行過程，找出改善工作流程的機會與方法。

5. 需求梳理會議 (Product Backlog Refinement)

為確保未來衝刺期順利進行，團隊針對當下衝刺期中尚未明確定義的產品需求進行澄清與梳理，包括確認各需求的價值、釐清驗收條件、估算所需工作量或系統複雜度、將大需求拆分小需求等。

Scrum 框架的文件與產出

Scrum 框架中定義了以下三種文件與產出，以幫助團隊管理產品開發相關工作：

1. 產品待辦清單 (Product Backlog)

產品待辦清單是產品負責人為實現「產品願景」(Product Vision) 而建立並維護的工作列表。清單上的項目稱為「產品待辦項目」(Product Backlog Item, PBI)，可由團隊添加，但最終由產品負責人評估各項目的重要性與價值並決定優先順序。

2. 衝刺待辦清單 (Sprint Backlog)

衝刺待辦清單是團隊在每個衝刺期開始時創建的，用以管理該衝刺期的工作內容。創建這份清單前，團隊會與產品負責人一起確認該衝刺期的「衝刺目標」(Sprint Goal)，以確保清單包含達成目標所需的所有工作。

3. 增量 (Increment)

增量指的是團隊在每個衝刺期透過交付實際可用軟體所產出的價值增額。增量不僅包括新增的產品功能，也包括修正瑕疵、改善效能、移除不需要的舊功能，或驗證技術可行性等。完成的增量若以可用的軟體形式交付，應符合團隊自訂的「完工標準」(Definition of Done, DOD)，並最好能達到「潛在可發行產品」(Potential Shippable Product) 的品質水準。