Scrum 概述

Scrum 概述

在 Scrum 中，專案經理稱為 Scrum 主管，專案團隊稱為 Scrum 團隊。有一位產品負責人，負責對產品待辦事項中的功能與需求進行優先順序排序。

Scrum 方法論利用 Sprint 來交付工作的小增量，並收集客戶的反饋。

有三個（3）Scrum 基石：

SCRUM採用經驗主義方法（有時稱為經驗主義）來適應不斷變化的客戶需求。經驗主義是根據實際經驗做出決策的實踐。經驗主義方法意味著以基於事實、基於經驗和基於證據的方式工作——特別是在進展基於對現實的觀察，而非基於大量初始需求的詳細前期計劃時。

簡而言之，我們從過去的錯誤與經驗中學習並改進。支援每項實踐中經驗過程控制的 Scrum 三大基石為：透明度、檢視與調整，如下圖所示：

The Three Pillars of Scrum

  • 透明度 — 使用共同的語言與標準，以確保一致性與共識。
  • 檢視 — 頻繁檢視 Scrum 的進展與交付成果，以取得反饋。不隱藏專案進度非常重要。
  • 調整 — 能輕鬆融入收到的反饋，並在問題出現時加以處理。

Scrum 流程的組成部分

這個 Scrum 框架本身非常簡單。它僅定義了一些通用指南，以及一組小規模的規則，角色, 產出物，以及事件。然而，這些每個組成部分都非常重要，具有特定用途，且對成功運用此框架至關重要。

Scrum 框架的主要組成部分為：

下圖說明了 SCRUM 框架中的關鍵元素。此流程已應用於敏捷軟體工具 — Scrum 流程圖.

Scrum Framework
Scrum 框架

Scrum 角色

當組織決定採用 Scrum 時，首先要了解的是 Scrum 角色與傳統專案執行角色之間的差異。雖然 Scrum 只有三個主要角色，但它們並不會自動與我們大多數人熟悉的職稱對應。讓我們先簡要定義每個角色：

產品負責人

產品負責人是負責代表業務或使用者社群，並與使用者群體合作，決定產品發行中將包含哪些功能的 Scrum 角色。產品負責人的主要職責包括：

  • 設定產品或服務的發展方向與策略，包括短期與長期目標；
  • 提供或取得有關產品或服務的知識；
  • 協助開發團隊理解並解讀客戶需求；
  • 收集、優先排序並管理產品或服務的需求；
  • 承擔與產品或服務預算相關的任何責任，包括其盈利能力；
  • 決定產品或服務功能的發布日期；
  • 每天與開發團隊一起回答問題並做出決策；
  • 接受或拒絕與 Sprint 相關的已完成功能；
  • 在每個 Sprint 結束時展示開發團隊的主要交付成果；
  • 負責產品待辦事項清單。

Scrum 主管

Scrum 主管是敏捷開發團隊的促進者。Scrum 是一種方法，使團隊能夠根據敏捷原則自我組織並快速變更。Scrum 主管負責管理資訊交流的流程。Scrum 主管的主要職責包括：

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

Scrum 團隊

Scrum 團隊（也稱為開發團隊）由 3 到 9 名成員組成，他們共同擁有交付產品或服務所需的全部技術能力。他們由 Scrum 主管直接指導，但並非直接管理。團隊必須具備自我組織、多功能且足夠負責的特質，以完成所有必要任務。

開發團隊負責在每個 Sprint 中交付可發行的產品增量——從分析、設計、開發、測試到技術撰寫。Scrum 團隊的主要特徵包括：

  • 團隊必須自我組織。所有團隊成員必須自行管理自己的努力以完成分配的任務。在敏捷 Scrum 中，並無團隊領導者或直屬經理的角色。每個人都必須足夠投入，以執行自身工作並貢獻於團隊的成功。若有一人失敗，所有人都會失敗。
  • 團隊必須具備跨功能。所有團隊成員都必須具備交付完整、可立即使用的服務或產品所需的知識與技能。必要時可使用專家，但僅作為教練，將知識傳授給團隊並彌補特定缺口。
  • 產品負責人需要具備商業遠見。產品負責人代表客戶的聲音，必須將其需求傳達給 Scrum 主管與開發團隊。這通常是一個全職角色。
  • Scrum 主管並非直屬經理。他們為開發團隊提供所需的指導，並協助排除團隊所面臨的任何障礙。

產品待辦事項清單

這是專案中所有待辦工作的有序清單。它以故事的形式呈現，通常稱為使用者故事。

使用者故事 — 用戶與專案交付成果（產品、服務或成果）互動方式的不同呈現。透過使用者故事，團隊識別出交付成果所需的特色與功能。

因此，產品待辦事項清單包含針對產品／服務／成果的優先排序使用者故事（特色與功能）。產品負責人負責對待辦事項清單進行優先排序。

注意：您不需要在开始工作前就为整个项目创建所有故事（这是敏捷方法的一个优势）。从您已知的故事开始，随着您了解得更多，再向待办事项列表中添加内容，并根据需要重新排序优先级。

冲刺规划

與瀑布式方法不同，敏捷團隊不會事先規劃所有內容。在這裡，團隊僅做部分規劃：當前衝刺所需的內容（衝刺通常為2至4週），完成後學習經驗，再為下一個衝刺重新規劃。

Scrum團隊審查產品待辦事項清單，並選擇在衝刺時間框內可完成的使用者故事數量。所選的使用者故事將成為衝刺待辦事項清單。衝刺待辦事項清單代表了衝刺的目標。

完成的定義也將被建立。完成的定義可視為待辦事項的接受標準。

僅規劃團隊負荷範圍內的工作——也就是團隊在每個衝刺中實際上能夠完成的工作。

每日Scrum會議（每日站會）

團隊利用此會議彼此做出微小承諾，識別問題，並確保衝刺工作在團隊內順利流動。會議通常持續15分鐘。團隊需回答以下問題：

  • 自上一次Scrum會議以來，我完成了什麼？
  • 我今天的計劃是什麼？我打算在現在到下一次Scrum會議之間完成什麼？
  • 是否有任何障礙（問題、困難或風險）阻礙了我？

請記住，此會議並非進度報告會議——它不是用來解決問題的，而是為了意識到問題（如有）。若需專門會議解決問題，應另行召開。

衝刺回顧會議

每個衝刺結束時，團隊會展示所有已完成的工作項目。此回顧會議用於接收專案利益相關者的反饋與任何變更請求。

請注意，根據規劃階段所建立的「完成定義」，未完全完成的工作項目將不會被展示，因為它們並未「完成」。

衝刺回顧會議

此會議在衝刺回顧後進行。目的是幫助團隊從衝刺中學習。該過程著重於持續改進，而非在衝刺進行不順時責怪團隊。

團隊反思如何變得更有效率，並識別其他可改進的領域。

Scrum主管對每一項改進內容的重要性進行排序，然後團隊選擇合適數量的改進項目，於下一個衝刺.

Leave a Reply