接續上一篇介紹 scrum 的內容，今天進一步來說明在 scrum 中的角色及各項事件。
Scrum 的三個角色
1. 產品負責人（Product Owner, PO）
主要職責：- 定義產品目標與願景。
- 管理並優先排序產品待辦清單（Product Backlog）。
- 確保開發團隊了解需求內容與業務價值。
- 與利害關係人（Stakeholders）溝通需求與期望。
2. Scrum Master
主要職責：- 確保 Scrum 流程正確執行。
- 移除團隊在開發過程中的障礙。
- 協助團隊自我管理與持續改善。
- 教育團隊與組織關於 Scrum 的實踐與原則。
重點： Scrum Master 是「流程守護者」，促進團隊良好協作，不是 PM 或主管。
Scrum Team 建議人數
➤ Scrum Team 總人數：
建議 10 人以內（不含利害關係人）
➤ 組成：
- 1 位 Product Owner
- 1 位 Scrum Master
- 3–9 位開發團隊成員（Developers）
🔍 什麼是 Product Backlog？
Product Backlog 是由產品負責人（PO）負責維護的一份動態清單，列出所有對產品有價值的工作項目（稱為 Product Backlog Items, PBIs），並依照優先順序排序。
- Product Backlog 排越上面的實作優先序越高，項目分解的顆粒度也越小
- Product Backlog Item 中含有 Features、Bugs 與 Spike(用來先做調研或技術驗證)
一個「好的待辦事項（Product Backlog Item, PBI）」應該要符合 DEEP 原則，這是一個常被用來衡量 backlog 品質的指標。
- Detailed appropriately（適當詳盡）：項目的細節程度要與它的開發時機相符：越接近開發的項目，細節越要明確；時間還早的項目可以保留彈性。
- Estimated（已估算）：每個項目都應該有基本的估算值（如 Story Point），便於 Sprint 規劃與預測。
- Emergent（可演化）：Backlog 是動態的，隨著學習與回饋，項目可以新增、調整或刪除。
- Prioritized（有優先順序）：PO 應根據業務價值、風險、技術可行性等因素，持續調整項目的順序。
估點是什麼？
Story Point 是一種 相對估算單位，它反映的是：
- 工作的規模大小
- 技術難度
- 風險與不確定性
而不是單純工時。換句話說，一個 5 點的項目不一定代表要 5 小時，而是比 2 點的項目更大、更複雜或風險更高。
✋ 常見的估點方式
1. Fibonacci 序列（推薦）
- 常用序列：1, 2, 3, 5, 8, 13, 21...
- 為什麼？因為數字間距隨著規模變大而加大，有助於凸顯不確定性與差異性
Fibonacci 序列是一串數字，每個數字都是前兩個數字的總和：
🎯 為什麼估點建議用 Fibonacci？
📌 使用建議
2. T-shirt Size（適合初期粗估）
- XS, S, M, L, XL...
- 用來快速比較項目的相對大小，後續再轉換成點數
3. Planning Poker（團隊共識估點法）
- 每個人匿名選一個估點值（如用紙牌或線上工具）
- 若出現差異，先讓最大與最小的說明理由，再重新估
- 好處：促進溝通、提升理解、建立共識
🚫 為什麼 Story Point ≠ 工時？
1. 估點本質是「相對值」，不是「絕對值」
Story Point 是一種相對估算，它的意義是：
- A 任務是 3 點、B 任務是 6 點 → 表示 B 任務大約是 A 的兩倍複雜
- 跟小時無關，而是任務規模、難度、風險與不確定性的整體感受
📌 不同人、不同團隊對同一件事的「所需時間」可能不同，但對相對難度卻比較容易有共識。
2. 每個人工作的速度不同，工時估不準
假設：
- 工程師 A 做完某功能只要 4 小時
- 工程師 B 可能需要 6 小時
- 工程師 C 剛熟悉技術，可能要 8 小時
➡️ 如果把點數對應工時，就會讓估點結果變得主觀、混亂，難以統一與追蹤。
而 Story Point 是用「團隊共識」去評估「這件事有多難」，不管誰做、怎麼做，是比較穩定的指標。
3. 用工時估容易導致微觀管理（micro-management）
這是最常見也最危險的問題：
