📖 目錄
Agile 敏捷概述
什麼是 Agile？
Agile（敏捷）是一種迭代式、增量式的軟體開發方法論，強調快速回應變化、持續交付價值、團隊協作和客戶參與。
敏捷宣言（Agile Manifesto, 2001）
我們透過親身實踐和協助他人，發現了更好的軟體開發方法。
透過這些工作，我們重視：
個人與互動 > 流程與工具
可用的軟體 > 詳盡的文檔
與客戶合作 > 合約談判
回應變化 > 遵循計劃
雖然右側項目有其價值，但我們更重視左側項目。
敏捷十二原則
- 最高優先級：透過早期和持續交付有價值的軟體來滿足客戶
- 歡迎變更：即使在開發後期也歡迎改變需求
- 頻繁交付：以較短的時間週期交付可用的軟體
- 共同合作：業務人員與開發人員每天一起工作
- 激勵個人：給予支援與信任，讓他們完成工作
- 面對面溝通：最有效率的溝通方式
- 可用軟體：是進度的主要衡量指標
- 永續節奏：維持穩定的開發節奏
- 技術卓越：持續關注技術優越性與良好設計
- 簡單為上：最大化未完成工作的藝術
- 自組織團隊：最好的架構、需求和設計來自自組織團隊
- 定期反思：定期反省如何更有效，並相應調整
核心價值觀
迭代開發 ➜ 增量交付 ➜ 快速反饋 ➜ 持續改進
⬇️ ⬇️ ⬇️ ⬇️
2-4週 可用功能 用戶驗證 流程優化
Scrum 框架
什麼是 Scrum？
Scrum 是最流行的敏捷開發框架之一，由 Ken Schwaber 和 Jeff Sutherland 在 1990 年代創建。Scrum 提供了一個結構化的框架來實踐敏捷原則。
Scrum 核心概念
產品待辦清單 ➜ Sprint 規劃 ➜ Sprint 執行 ➜ Sprint 審查 ➜ Sprint 回顧
(Backlog) (Planning) (2-4週) (Review) (Retrospective)
⬇️
每日站立會議
(Daily Scrum)
Scrum 框架圖
┌─────────────────────────────────────────────────────────┐
│ 產品負責人 │
│ (Product Owner) │
│ │ │
│ 產品待辦清單 │
│ (Product Backlog) │
└─────────────────────────┬───────────────────────────────┘
│
┌─────▼─────┐
│ Sprint 規劃 │
│ Planning │
└─────┬─────┘
│
┌───────────▼───────────┐
│ Sprint 待辦清單 │
│ (Sprint Backlog) │
└───────────┬───────────┘
│
┌─────────────────────▼─────────────────────┐
│ Sprint (2-4 週) │
│ ┌────────────────────────────────────┐ │
│ │ 每日站立會議 (Daily Scrum) │ │
│ │ 開發團隊 (Dev Team) │ │
│ │ Scrum Master │ │
│ └────────────────────────────────────┘ │
└─────────────────────┬─────────────────────┘
│
┌─────▼─────┐
│ 產品增量 │
│ (Increment)│
└─────┬─────┘
│
┌───────────┴────────────┐
│ │
┌─────▼─────┐ ┌──────▼──────┐
│ Sprint 審查│ │ Sprint 回顧 │
│ Review │ │Retrospective│
└───────────┘ └─────────────┘
Scrum 角色
Scrum 團隊由三個角色組成，每個角色有明確的職責。
1. 產品負責人（Product Owner, PO）
核心職責：最大化產品價值
主要任務
✅ 管理產品待辦清單 - 定義產品待辦項目 - 排定優先順序 - 確保清單對所有人可見
✅ 定義驗收標準 - 明確定義「完成」的標準 - 驗收 Sprint 成果
✅ 與利害關係人溝通 - 收集需求與回饋 - 傳達產品願景 - 管理期望
✅ 決策權 - 決定要做什麼（What） - 決定優先順序 - 決定是否發布
成功特質
業務知識 + 溝通能力 + 決策能力 + 可用性
一天的工作範例
09:00 - 檢視產品待辦清單，調整優先順序
10:00 - 參加每日站立會議
10:15 - 與客戶討論新需求
11:30 - 撰寫使用者故事（User Story）
13:00 - 回答開發團隊的問題
14:00 - 準備 Sprint 審查簡報
15:30 - 驗收已完成的功能
16:30 - 分析產品數據與使用者回饋
2. Scrum Master（SM）
核心職責：確保 Scrum 流程順利運作
主要任務
✅ 服務開發團隊 - 移除障礙（Impediments） - 促進團隊自組織 - 教導 Scrum 實踐
✅ 服務產品負責人 - 協助管理產品待辦清單 - 促進 Scrum 活動 - 提供敏捷技巧建議
✅ 服務組織 - 引導組織採用 Scrum - 與其他 Scrum Master 合作 - 提升組織敏捷成熟度
✅ 促進儀式 - 主持每日站立會議 - 促進 Sprint 規劃 - 引導回顧會議
成功特質
僕人式領導 + 促進技巧 + 問題解決 + Scrum 專業知識
常見障礙與解決
| 障礙類型 | 範例 | 解決方式 |
|---|---|---|
| 組織障礙 | 跨部門協調困難 | 向上管理，協調資源 |
| 技術障礙 | 開發環境問題 | 協調 IT 部門支援 |
| 團隊障礙 | 團隊衝突 | 促進溝通，團隊建設 |
| 流程障礙 | 需求不明確 | 協助 PO 釐清需求 |
3. 開發團隊（Development Team）
核心職責：交付可用的產品增量
特性
✅ 跨功能（Cross-functional） - 具備完成工作所需的所有技能 - 不依賴團隊外部人員
✅ 自組織（Self-organizing） - 自行決定如何完成工作（How） - 沒有子團隊或層級
✅ 規模適中 - 建議 3-9 人 - 足夠小以保持敏捷 - 足夠大以完成重要工作
成員技能組成（範例）
全端工程師 x 2
前端工程師 x 2
後端工程師 x 2
QA 測試 x 1
UI/UX 設計 x 1
DevOps x 1
──────────────
總計：9 人
開發團隊的責任
✅ 預估工作量
✅ 承諾 Sprint 目標
✅ 執行開發工作
✅ 確保品質
✅ 持續整合
✅ 互相協助
✅ 分享知識
Scrum 儀式
Scrum 定義了五個正式的會議（Ceremonies/Events），每個都有特定的目的。
1. Sprint 規劃（Sprint Planning）
目的：規劃這個 Sprint 要完成什麼以及如何完成
時間盒（Time-box）
- 2 週 Sprint：最多 4 小時
- 4 週 Sprint：最多 8 小時
參與者
- Product Owner（必須）
- Scrum Master（必須）
- Development Team（必須）
議程
Part 1：我們要做什麼？（What）
1. Product Owner 展示優先順序最高的產品待辦項目
2. 團隊討論並釐清需求
3. 團隊承諾本 Sprint 可完成的項目
4. 制定 Sprint 目標
Part 2：我們如何做？（How）
1. 將選定的產品待辦項目拆解成任務
2. 預估任務工作量
3. 識別依賴關係
4. 分配初步責任（可選）
輸入
- 產品待辦清單（優先順序已排序）
- 最新的產品增量
- 團隊的預測產能
- 過去的績效數據
輸出
- Sprint 目標
- Sprint 待辦清單
- 如何交付工作的計劃
實際範例
專案：社交媒體應用
Sprint 目標：
「讓使用者可以建立和編輯個人檔案」
選定的使用者故事：
1. 作為使用者，我想建立個人檔案，以便其他人認識我
- 估計：8 點
2. 作為使用者，我想上傳大頭照，以便個人化我的檔案
- 估計：5 點
3. 作為使用者，我想編輯個人資料，以便保持資訊最新
- 估計：5 點
4. 作為使用者，我想設定隱私選項，以便控制誰能看到我的檔案
- 估計：8 點
總計：26 點
團隊產能：25-30 點/Sprint
任務拆解範例
使用者故事：「作為使用者，我想建立個人檔案」
任務拆解：
□ 設計資料庫 schema（2h）
□ 建立 API endpoint（4h）
□ 實作資料驗證（3h）
□ 設計 UI 介面（4h）
□ 實作前端表單（6h）
□ 整合前後端（3h）
□ 撰寫單元測試（4h）
□ 撰寫整合測試（3h）
□ Code Review（2h）
□ 文檔更新（1h）
總計：32 小時 ≈ 8 故事點
2. 每日站立會議（Daily Scrum/Stand-up）
目的：同步團隊進度，識別障礙
時間盒
- 每天同一時間
- 最多 15 分鐘
- 站著開會（保持簡短）
參與者
- Development Team（必須）
- Scrum Master（促進）
- Product Owner（可選）
- 其他人可旁聽但不發言
三個問題
每個開發團隊成員回答：
-
昨天我完成了什麼？ - 幫助團隊達成 Sprint 目標
-
今天我計劃做什麼？ - 幫助團隊達成 Sprint 目標
-
我遇到什麼障礙？ - 阻礙我或團隊進度的事情
實際範例
成員 A（前端工程師）：
- 昨天：完成了個人檔案編輯頁面的 UI
- 今天：整合後端 API，實作表單驗證
- 障礙：需要後端 API 文檔更新
成員 B（後端工程師）：
- 昨天：完成了檔案 API 的 CRUD 功能
- 今天：更新 API 文檔，協助前端整合
- 障礙：無
成員 C（QA）：
- 昨天：撰寫了檔案上傳的測試案例
- 今天：執行整合測試，記錄缺陷
- 障礙：測試環境資料庫連線不穩定
Scrum Master 記下：
⚠️ 需要更新 API 文檔（成員 B 今天處理）
⚠️ 測試環境資料庫問題（會後聯絡 DevOps）
最佳實踐
✅ DO（該做） - 準時開始，準時結束 - 保持簡短扼要 - 聚焦在目標和障礙 - 站著開會 - 立即識別需要協作的事項
❌ DON'T（別做） - 變成狀態報告會議 - 討論技術細節 - 解決問題（會後再談） - 超過 15 分鐘 - 批評或指責
3. Sprint 審查（Sprint Review）
目的：檢視本 Sprint 完成的工作，調整產品待辦清單
時間盒
- 2 週 Sprint：最多 2 小時
- 4 週 Sprint：最多 4 小時
參與者
- Product Owner（必須）
- Scrum Master（必須）
- Development Team（必須）
- 利害關係人（邀請）
- 客戶（邀請）
議程
1. 回顧 Sprint 目標（5 分鐘）
- Sprint 目標是什麼
- 是否達成
2. 展示完成的工作（60-90 分鐘）
- 展示可用的功能
- 實際操作演示
- 不要用投影片！
3. 討論與回饋（20-30 分鐘）
- 利害關係人提供回饋
- 討論接下來該做什麼
- 調整產品待辦清單
4. 市場與時程檢視（10-20 分鐘）
- 討論預算、時程
- 討論下個 Sprint 的可能性
實際範例
專案：社交媒體應用 - Sprint 5 審查
09:00 - 09:05 回顧 Sprint 目標
「讓使用者可以建立和編輯個人檔案」
✅ 目標達成
09:05 - 10:15 功能展示
展示 1：建立個人檔案
[實際操作]
- 註冊新帳號
- 填寫個人資料（姓名、生日、興趣）
- 選擇隱私設定
- 儲存檔案
展示 2：上傳大頭照
[實際操作]
- 點選上傳按鈕
- 選擇圖片
- 裁切圖片
- 預覽並確認
展示 3：編輯個人資料
[實際操作]
- 修改個人資訊
- 即時儲存
- 查看更新結果
10:15 - 10:35 回饋討論
利害關係人 A（行銷）：
「大頭照上傳很順暢！但可以加入濾鏡嗎？」
→ PO 記錄到產品待辦清單
客戶 B：
「隱私設定有點複雜，可以簡化嗎？」
→ PO 標記為高優先級改善項目
團隊討論：
「濾鏡功能預估需要 2 個 Sprint」
10:35 - 10:50 下個 Sprint 討論
PO 分享：
「根據回饋，下個 Sprint 我們聚焦在：
1. 簡化隱私設定 UI
2. 加入基本的個人檔案搜尋功能
3. 開始評估濾鏡功能的技術方案」
10:50 - 11:00 時程檢視
已完成：5/12 Sprints
已交付：12 個主要功能
預計發布：還有 7 個 Sprint（14 週）
驗收標準（Definition of Done）
功能必須符合以下條件才算「完成」：
✅ 程式碼已撰寫並遵循編碼標準
✅ 單元測試已撰寫且通過
✅ 整合測試已執行且通過
✅ Code Review 已完成
✅ 文檔已更新
✅ 功能已部署到測試環境
✅ Product Owner 已驗收
✅ 無已知的嚴重缺陷
4. Sprint 回顧（Sprint Retrospective）
目的：檢視團隊流程，持續改進
時間盒
- 2 週 Sprint：最多 1.5 小時
- 4 週 Sprint：最多 3 小時
參與者
- Scrum Master（促進，必須）
- Development Team（必須）
- Product Owner（可選）
基本格式
1. 設定氛圍（5-10 分鐘）
- 破冰活動
- 建立安全環境
2. 收集數據（15-20 分鐘）
- 什麼做得好？（Keep）
- 什麼可以改進？（Improve）
- 嘗試什麼新事物？（Try）
3. 產生洞察（20-30 分鐘）
- 識別模式
- 找出根本原因
- 討論改進方案
4. 決定行動（15-20 分鐘）
- 選擇 1-3 個改進項目
- 指定負責人
- 設定檢查點
5. 結束（5-10 分鐘）
- 總結行動項目
- 感謝團隊
實際範例：Mad/Sad/Glad 格式
Sprint 5 回顧 - Mad/Sad/Glad
😠 Mad（生氣）：
- 測試環境經常不穩定
- 需求澄清花太多時間
- 會議太多，開發時間不夠
😢 Sad（難過）：
- 有些技術債務沒時間處理
- Code Review 有時被延遲
- 團隊新成員還在適應
😊 Glad（高興）：
- Sprint 目標達成了！
- 團隊協作很好
- 新的 CI/CD 流程很順暢
- Daily Scrum 變得更高效
討論與洞察：
問題 1：測試環境不穩定
根本原因：資料庫配置與正式環境不同
解決方案：使用 Docker 容器統一環境
問題 2：需求澄清花太多時間
根本原因：User Story 缺乏驗收標準
解決方案：PO 在規劃前先寫好驗收標準
問題 3：會議太多
根本原因：一些會議可以非同步處理
解決方案：使用 Slack 進行非緊急溝通
行動項目（下個 Sprint）：
1. 建立 Docker 測試環境
- 負責人：DevOps 工程師
- 檢查點：下個 Sprint 第一週
2. PO 在 Sprint Planning 前完成所有 Story 的驗收標準
- 負責人：Product Owner
- 檢查點：每次 Sprint Planning
3. 取消非必要的週會，改用非同步更新
- 負責人：Scrum Master
- 檢查點：立即執行
其他回顧格式
1. Start/Stop/Continue
Start（開始做）：
- 配對程式設計
- 每週技術分享
Stop（停止做）：
- 在 Daily Scrum 討論技術細節
- 週五下午排重要任務
Continue（繼續做）：
- Code Review 標準
- 自動化測試
2. 4Ls - Liked/Learned/Lacked/Longed For
Liked（喜歡）：
- 新的部署流程很順暢
Learned（學到）：
- 學到了新的測試框架
Lacked（缺乏）：
- 缺乏效能監控工具
Longed For（渴望）：
- 希望有更好的開發工具
3. Sailboat（帆船回顧）
🏝️ 目標（島嶼）：
- 按時發布產品
⛵ 推動力（風）：
- 團隊士氣高
- 技術能力強
⚓ 阻力（錨）：
- 技術債務
- 遺留系統整合困難
🪨 風險（礁石）：
- 關鍵成員即將離職
- 第三方 API 不穩定
5. 產品待辦清單精煉（Backlog Refinement）
目的：讓產品待辦清單保持在健康狀態
時間盒
- 非正式儀式
- 通常每週 1-2 小時
- 不超過 Sprint 時間的 10%
參與者
- Product Owner（主導）
- Development Team（參與）
- Scrum Master（可選）
活動內容
1. 新增項目
- 加入新的使用者故事
- 記錄技術需求
2. 細化項目
- 拆分大型故事
- 撰寫驗收標準
- 加入細節說明
3. 預估項目
- 使用故事點或理想天數
- Planning Poker
4. 排序項目
- 依據業務價值
- 依據依賴關係
- 依據風險
5. 移除項目
- 刪除過時的項目
- 歸檔不相關的項目
使用者故事範例
格式：
作為 [角色]
我想要 [功能]
以便 [商業價值]
範例 1：基本故事
標題：使用者登入
作為使用者
我想要登入系統
以便存取我的個人資料
驗收標準：
✅ 使用者可以用 Email 和密碼登入
✅ 登入失敗顯示錯誤訊息
✅ 登入成功後導向首頁
✅ 支援「記住我」功能
✅ 密碼輸入錯誤 5 次後鎖定帳號
估計：5 點
優先級：高
依賴：無
範例 2：詳細故事
標題：商品搜尋自動完成
作為購物者
我想要在輸入搜尋關鍵字時看到建議
以便快速找到我想要的商品
驗收標準：
✅ 輸入 3 個字元後顯示建議
✅ 最多顯示 10 個建議
✅ 建議包含商品名稱和圖片
✅ 點選建議後跳轉到商品頁
✅ 建議在 300ms 內回應
✅ 支援中英文搜尋
技術備註：
- 使用 Elasticsearch 實作
- 需要建立商品名稱的索引
- 前端使用 debounce 減少 API 呼叫
估計：13 點（較大，可能需要拆分）
優先級：中
依賴：商品資料必須已匯入
Planning Poker（規劃撲克）
用於估計使用者故事的大小：
估計流程：
1. Product Owner 說明使用者故事
2. 開發團隊討論和澄清
3. 每個人私下選擇一張卡片：
數字：1, 2, 3, 5, 8, 13, 21, 40, 100
（費波那契數列）
4. 同時翻開卡片
5. 如果數字不一致：
- 最大和最小的人說明原因
- 重新討論
- 再次投票
6. 達成共識
範例：
故事：「實作購物車功能」
第一輪投票：5, 5, 8, 13
- 投 13 的人：「需要考慮庫存檢查和價格計算」
- 投 5 的人：「我以為只是基本的加入/移除功能」
- PO 澄清：「需要包含庫存檢查」
第二輪投票：8, 8, 8, 8
✅ 共識達成：8 點
Scrum 產出物
1. 產品待辦清單（Product Backlog）
定義：按優先順序排列的產品需求清單
特性
- 動態的：持續更新和調整
- 有優先順序：最重要的在最上面
- 細化程度不同：頂部項目更詳細
- 透明的：所有人都能看到
內容類型
1. 功能（Features）
- 新功能開發
- 使用者故事
2. 缺陷（Bugs）
- 需要修復的問題
- 技術債務
3. 技術工作（Technical Work）
- 架構改進
- 效能優化
- 安全性更新
4. 知識獲取（Knowledge Acquisition）
- 技術研究
- 原型開發
- 概念驗證
優先順序模型：MoSCoW
Must Have（必須有）：
- 核心功能
- 法規要求
- 關鍵缺陷
Should Have（應該有）：
- 重要但不緊急
- 可以延後一個 Sprint
Could Have（可以有）：
- 加分項目
- 時間允許才做
Won't Have（不會有）：
- 這個版本不做
- 未來再考慮
範例：電商產品待辦清單
優先級 1（Must Have）：
□ [50 點] 使用者註冊和登入系統
□ [30 點] 商品瀏覽和搜尋
□ [40 點] 購物車功能
□ [60 點] 結帳和付款流程
□ [20 點] 訂單確認和通知
優先級 2（Should Have）：
□ [20 點] 使用者評論和評分
□ [15 點] 願望清單
□ [25 點] 訂單追蹤
□ [10 點] 促銷碼功能
優先級 3（Could Have）：
□ [30 點] 社群分享功能
□ [15 點] 商品推薦系統
□ [10 點] 忠誠度點數
優先級 4（Won't Have - This Release）：
□ [40 點] AR 虛擬試穿
□ [50 點] 直播購物
□ [30 點] AI 客服聊天機器人
2. Sprint 待辦清單（Sprint Backlog）
定義：團隊在本 Sprint 承諾完成的工作
組成
Sprint 待辦清單 = 選定的產品待辦項目 + 交付計劃 + Sprint 目標
特性
- 團隊擁有：由開發團隊管理
- 可調整：Sprint 期間可修改任務
- 透明：任何人都能看到進度
- 即時更新：每天更新
範例：Sprint 待辦清單
Sprint 10 待辦清單
Sprint 目標：「讓使用者可以管理和追蹤訂單」
時間：2024-03-01 到 2024-03-14（2週）
使用者故事 1：查看訂單列表 [13 點]
狀態：進行中
任務：
✅ 設計訂單列表 API（4h）- 王小明 - 已完成
✅ 實作後端 API（6h）- 王小明 - 已完成
🔄 設計 UI 介面（4h）- 李小華 - 進行中
⏳ 實作前端元件（8h）- 李小華 - 待處理
⏳ 撰寫測試（4h）- 陳小美 - 待處理
⏳ 整合測試（3h）- 陳小美 - 待處理
使用者故事 2：查看訂單詳情 [8 點]
狀態：待處理
任務：
⏳ 設計訂單詳情 API（3h）- 未分配
⏳ 實作後端 API（5h）- 未分配
⏳ 設計 UI 介面（3h）- 未分配
⏳ 實作前端元件（6h）- 未分配
⏳ 撰寫測試（3h）- 未分配
使用者故事 3：取消訂單 [5 點]
狀態：待處理
任務：
⏳ 設計取消訂單 API（2h）- 未分配
⏳ 實作業務邏輯（4h）- 未分配
⏳ 實作前端按鈕（2h）- 未分配
⏳ 通知系統整合（3h）- 未分配
⏳ 測試（2h）- 未分配
Sprint 燃盡圖：
26 點 |█
|██
|███
|████
|█████
|██████
|███████▼ (目前這裡：剩餘 18 點)
|████████
|█████████
|██████████
0 └──────────────────→
Day 1 2 3 4 5 6 7 8 9 10
3. 產品增量（Increment）
定義：Sprint 結束時所有已完成產品待辦項目的總和
特性
- 可用的：符合完成定義
- 可發布的：隨時可以上線
- 累積的：包含之前所有 Sprint 的增量
- 可檢驗的：可以被檢視和驗證
完成定義（Definition of Done, DoD）
程式碼層級：
✅ 程式碼已提交到版本控制
✅ 程式碼符合編碼標準
✅ 所有變數和函式都有註解
✅ 沒有 hardcode 的數值
✅ 沒有 TODO 或 FIXME 註解
測試層級：
✅ 單元測試已撰寫且通過（覆蓋率 > 80%）
✅ 整合測試已執行且通過
✅ 手動測試已執行
✅ 無已知的 Critical 或 High 缺陷
✅ 效能測試已通過
審查層級：
✅ Code Review 已完成且核准
✅ 至少有 2 位成員審查過
部署層級：
✅ 已部署到測試環境
✅ 已部署到預生產環境
✅ 煙霧測試已通過
文檔層級：
✅ API 文檔已更新
✅ 使用者文檔已更新
✅ Release Notes 已撰寫
驗收層級：
✅ Product Owner 已驗收
✅ 符合所有驗收標準
增量範例
產品：電商平台
Sprint 1 增量：
✅ 使用者註冊
✅ 使用者登入
→ 可發布：基本使用者系統上線
Sprint 2 增量：
✅ 使用者註冊
✅ 使用者登入
✅ 商品瀏覽
✅ 商品搜尋
→ 可發布：使用者可以瀏覽商品
Sprint 3 增量：
✅ 使用者註冊
✅ 使用者登入
✅ 商品瀏覽
✅ 商品搜尋
✅ 購物車
→ 可發布：使用者可以加入購物車
Sprint 4 增量：
✅ 使用者註冊
✅ 使用者登入
✅ 商品瀏覽
✅ 商品搜尋
✅ 購物車
✅ 結帳
✅ 付款
→ 可發布：完整的購物流程可上線！
優點與缺點
✅ 優點
1. 快速回應變化
傳統方式：需求變更 → 變更控制流程 → 評估影響 → 重新計劃（週/月）
Scrum：需求變更 → 加入 Backlog → 下個 Sprint 處理（天/週）
2. 早期交付價值
- 每個 Sprint 都交付可用功能
- 快速獲得市場反饋
- 投資回報週期短
3. 持續改進
- 每個 Sprint 後都有回顧
- 團隊不斷優化流程
- 問題快速暴露和解決
4. 高透明度
- 每日站立會議
- Sprint 審查展示成果
- 所有人都能看到進度
5. 團隊賦權
- 自組織團隊
- 團隊決定如何工作
- 提升團隊士氣和責任感
6. 降低風險
- 短週期迭代
- 問題早期發現
- 失敗成本低
7. 客戶參與
- 定期審查和回饋
- 確保開發正確的產品
- 建立信任關係
❌ 缺點
1. 需要文化轉變
挑戰：
- 從指揮控制到授權
- 從個人績效到團隊成果
- 從計劃驅動到價值驅動
需要時間適應和學習
2. 需求高度投入
Product Owner：
- 需要大量時間參與
- 需要快速決策能力
- 需要深入了解業務
開發團隊：
- 需要跨功能技能
- 需要自我管理能力
- 需要頻繁溝通
3. 適合小型團隊
- Scrum 建議 3-9 人
- 大型專案需要 Scrum of Scrums
- 跨團隊協調複雜
4. 文檔可能不足
- 強調可用軟體勝過文檔
- 可能缺乏完整的系統文檔
- 知識傳承可能困難
5. 範圍蔓延風險
- 歡迎變更可能導致無止境的改動
- 需要強大的 Product Owner 控制
- Sprint 目標可能被稀釋
6. 不適合固定合約
固定範圍、固定價格、固定時間的合約
難以在 Scrum 中實施：
- 需求會變化
- 範圍會調整
- 精確預估困難
7. 需要成熟的技術實踐
技術要求：
✅ 持續整合
✅ 自動化測試
✅ 重構能力
✅ 配對程式設計
✅ Test-Driven Development
沒有這些，每個 Sprint 交付可用增量會很困難
適用場景
✅ 適合使用 Scrum 的情況
1. 需求不明確或會變化
範例：新創公司的 MVP 產品
- 需要快速驗證市場
- 根據回饋調整方向
- 探索最佳產品市場契合度
2. 創新型專案
範例：AI 聊天機器人
- 技術不確定性高
- 需要實驗和學習
- 根據結果調整方向
3. 需要快速上市
範例：電商促銷活動平台
- 市場機會窗口短
- 需要快速交付核心功能
- 後續持續迭代改善
4. 使用者需求需要驗證
範例：社群媒體應用
- 使用者行為難以預測
- 需要透過真實使用者測試
- 根據數據驅動決策
5. 複雜領域問題
範例：醫療診斷系統
- 領域知識複雜
- 需要領域專家持續參與
- 透過迭代逐步理解需求
❌ 不適合使用 Scrum 的情況
1. 需求非常明確且穩定
範例：法規遵循報表系統
- 需求由法規明確定義
- 不會頻繁變更
- Waterfall 可能更適合
2. 固定範圍固定價格合約
範例：政府標案
- 需要精確的範圍定義
- 固定預算和時程
- 需要完整的前期文檔
3. 分散的團隊且溝通困難
問題：
- 不同時區
- 語言障礙
- 無法每日同步
Scrum 需要高度協作和頻繁溝通
4. 無法獲得 Product Owner 的充分投入
問題：
- PO 兼任其他工作
- 無法每日回答問題
- 無法參加所有儀式
會嚴重影響 Sprint 進度
5. 技術基礎設施薄弱
缺乏：
- 版本控制系統
- 自動化測試
- 持續整合
- 測試環境
難以每個 Sprint 交付可用增量
實際執行範例
案例：行動社群應用開發
讓我們透過一個完整的案例，看看 Scrum 如何實際執行。
專案背景
- 專案名稱：ConnectNow - 行動社群應用
- 客戶：新創公司
- 目標：6 個月內推出 MVP
- 團隊：8 人（PO x1, SM x1, Dev x6）
- Sprint 長度：2 週
- 總 Sprint 數：12 個 Sprint
Sprint 0：準備階段（2週）
Week 1：團隊組建與環境設定
團隊組成
Product Owner: Sarah（創辦人，全職）
Scrum Master: Mike（兼任開發）
開發團隊（6人）:
- Alex: 全端工程師（資深）
- Jenny: iOS 工程師
- Tom: Android 工程師
- Lisa: 後端工程師
- David: UI/UX 設計師
- Emma: QA 工程師
開發環境設定
# 版本控制
✅ GitHub 組織建立
✅ Repositories 建立（iOS, Android, Backend, Design）
# 專案管理
✅ Jira 專案建立
✅ Sprint 看板配置
✅ Backlog 設定
# CI/CD
✅ GitHub Actions 設定
✅ TestFlight（iOS）設定
✅ Google Play 內部測試設定
# 溝通工具
✅ Slack workspace 建立
✅ Google Meet for meetings
✅ Miro for 線上協作
Week 2：產品願景與初始 Backlog
產品願景工作坊
願景：
「打造最真實的社群連結平台，
讓人們可以透過興趣找到志同道合的朋友」
目標使用者：
- 18-35 歲都市青年
- 想擴展社交圈
- 有特定興趣愛好
核心價值主張：
1. 基於真實興趣配對
2. 小型聚會活動組織
3. 真實身份驗證
4. 安全的社交環境
初始產品待辦清單
使用 User Story Mapping 建立：
[使用者旅程]
註冊/登入 → 建立檔案 → 探索興趣 → 配對連結 → 參加活動 → 建立社群
[Epic 1: 使用者管理]
└─ 使用者註冊
└─ 使用者登入
└─ 身份驗證
└─ 個人檔案建立
└─ 個人檔案編輯
[Epic 2: 興趣系統]
└─ 興趣分類瀏覽
└─ 興趣搜尋
└─ 興趣標籤
└─ 使用者興趣選擇
└─ 興趣推薦
[Epic 3: 配對系統]
└─ 基於興趣配對
└─ 配對建議
└─ 發送連結請求
└─ 接受/拒絕請求
└─ 聊天功能
[Epic 4: 活動系統]
└─ 建立活動
└─ 瀏覽活動
└─ 報名活動
└─ 活動簽到
└─ 活動評價
[Epic 5: 社群功能]
└─ 建立社群
└─ 加入社群
└─ 社群動態
└─ 社群管理
MVP 範圍定義
Sarah（PO）與團隊討論後，定義 MVP 包含：
MVP 功能（前 6 個月）:
✅ Must Have:
- 使用者註冊/登入
- 個人檔案建立
- 興趣選擇
- 基於興趣的配對建議
- 基本聊天功能
- 瀏覽活動
- 報名活動
🔶 Should Have:
- 身份驗證
- 建立活動
- 活動評價
- 推播通知
⏸️ Could Have (Post-MVP):
- 社群功能
- 進階配對算法
- 視訊聊天
估計全部待辦清單
團隊花了一整天進行 Planning Poker：
總估計：約 250 故事點
團隊速度預測：
- 預期每 Sprint 完成：20-25 點
- 12 個 Sprint 可完成：240-300 點
- 結論：範圍合理，但需要持續調整優先順序
Sprint 1：奠定基礎
Sprint 規劃（2小時）
Sprint 目標
「建立應用的基礎架構和使用者認證系統」
選定的使用者故事
1. [8點] 使用者可以用 Email 註冊
驗收標準：
✅ Email 格式驗證
✅ 密碼強度檢查（至少8字元）
✅ 註冊成功後發送驗證Email
✅ 錯誤訊息友善
2. [5點] 使用者可以用 Email 登入
驗收標準：
✅ Email 和密碼驗證
✅ 登入失敗顯示錯誤訊息
✅ 登入成功後獲得 JWT token
✅ Token 儲存在安全儲存空間
3. [8點] 建立基本的個人檔案頁面
驗收標準：
✅ 顯示使用者名稱
✅ 顯示大頭照（預設圖片）
✅ 顯示個人簡介
✅ 有編輯按鈕
4. [5點] 建立專案 CI/CD 管道
驗收標準：
✅ 每次 commit 自動執行測試
✅ 測試通過後自動建置
✅ 自動部署到開發環境
✅ Slack 通知建置狀態
總計：26 點
團隊產能：25 點
承諾：有點挑戰但可達成
Sprint 執行（2週）
Day 1（Monday）
Daily Scrum (10:00)
Alex（全端）:
- 昨天：N/A (第一天)
- 今天：設定後端專案架構，建立 User model
- 障礙：無
Jenny（iOS）:
- 昨天：N/A
- 今天：設定 iOS 專案，建立登入畫面 UI
- 障礙：需要 API 文檔
Tom（Android）:
- 昨天：N/A
- 今天：設定 Android 專案，建立登入畫面 UI
- 障礙：需要 API 文檔
Lisa（後端）:
- 昨天：N/A
- 今天：協助 Alex 設定資料庫，設計 Auth API
- 障礙：無
David（UI/UX）:
- 昨天：N/A
- 今天：完成登入/註冊頁面設計稿
- 障礙：無
Emma（QA）:
- 昨天：N/A
- 今天：設定測試環境，建立測試案例
- 障礙：無
Mike（SM）記下：
⚠️ 前端需要 API 文檔
→ 行動：Lisa 今天會提供初版 API 文檔
Day 3（Wednesday）
Daily Scrum
Alex:
- 昨天：完成 User model 和註冊 API
- 今天：實作 JWT 認證中間件
- 障礙：無
Jenny:
- 昨天：完成登入畫面 UI
- 今天：整合登入 API
- 障礙：API 401 錯誤處理不清楚
Lisa:
- 昨天：完成 API 文檔，設定郵件服務
- 今天：實作發送驗證 Email 功能
- 障礙：無
[其他成員...]
Mike 記下：
⚠️ API 錯誤處理需要統一
→ 行動：Lisa 和 Alex 會後討論，更新 API 文檔
Day 7（Monday, Week 2）
Daily Scrum
團隊狀態：
✅ 使用者註冊 API - 完成
✅ 使用者登入 API - 完成
✅ iOS 註冊/登入畫面 - 完成，整合中
✅ Android 註冊/登入畫面 - 完成，整合中
🔄 CI/CD 管道 - 80% 完成
🔄 個人檔案頁面 - 進行中
⏳ Email 驗證功能 - 待測試
Alex:
- 昨天：完成個人檔案 API
- 今天：協助前端整合，Code Review
- 障礙：無
Emma:
- 昨天：測試註冊/登入流程
- 今天：測試個人檔案功能，記錄缺陷
- 障礙：測試環境有時連不上資料庫
Mike 記下：
⚠️ 測試環境不穩定
→ 行動：Mike 會檢查資料庫連線配置
Day 10（Thursday, Week 2）
每日站立會議
團隊狀態：
✅ 使用者註冊 - 完成並測試通過
✅ 使用者登入 - 完成並測試通過
✅ 個人檔案頁面 - 完成並測試通過
✅ CI/CD 管道 - 完成
⚠️ 發現 2 個中等缺陷需要修復
今天重點：
- 修復缺陷
- 準備 Sprint Review demo
- 完成文檔
預計可以達成 Sprint 目標 ✅
Sprint 審查（2小時）
參與者 - Scrum 團隊（8人） - 創辦人/CEO - 投資人（2位） - 早期顧問（3位）
Demo 腳本
Sarah（PO）開場
「歡迎大家！這是我們的第一個 Sprint。
我們的目標是建立基礎架構和使用者認證。
讓我展示我們完成了什麼...」
Demo 1：使用者註冊（Jenny 展示 iOS）
[實際操作]
1. 打開 App
2. 點選「註冊」
3. 輸入 Email: demo@example.com
4. 輸入密碼: SecurePass123
5. 點選「註冊」
6. 顯示「註冊成功，請檢查Email驗證」
7. 切換到 Email 客戶端
8. 顯示收到驗證郵件
Demo 2：使用者登入（Tom 展示 Android）
[實際操作]
1. 輸入剛才註冊的帳號
2. 點選「登入」
3. 成功登入，進入首頁
4. 顯示歡迎訊息
Demo 3：個人檔案（Alex 展示）
[實際操作]
1. 點選右上角個人圖示
2. 進入個人檔案頁面
3. 顯示預設大頭照和基本資訊
4. 展示 UI 設計
Demo 4：CI/CD（Mike 展示）
[展示 GitHub]
1. 顯示最新的 commit
2. 顯示自動化測試通過 ✅
3. 顯示自動部署成功 ✅
4. Slack 通知訊息
回饋與討論
投資人 A：
「登入流程很順暢！但註冊時可以加入 Google 登入嗎？」
→ Sarah：「好建議！我會加入待辦清單，可能在 Sprint 3 處理」
顧問 B：
「個人檔案頁面有點空，使用者會想加什麼資訊？」
→ David：「下個 Sprint 我們會加入興趣標籤選擇」
CEO：
「進度符合預期！請繼續保持」
Sarah 總結：
「這個 Sprint 我們完成了 26 點，建立了堅實的基礎。
下個 Sprint 我們會專注在興趣系統和個人檔案完善。」
Sprint 回顧（1.5小時）
Mike 使用「帆船回顧」格式：
🏝️ 目標（我們要去哪？）
「6個月後推出 MVP」
⛵ 推動力（什麼幫助我們前進？）
- ✅ 團隊協作很好
- ✅ Daily Scrum 很有效率
- ✅ PO 隨時可以回答問題
- ✅ 技術選型正確
⚓ 阻力（什麼拖慢我們？）
- ❌ 測試環境不穩定
- ❌ API 文檔有時更新不及時
- ❌ Code Review 有時被延遲
🪨 風險（前方的礁石）
- ⚠️ 團隊成員對行動開發經驗不同
- ⚠️ 推播通知功能技術不確定
💡 討論與洞察
問題：測試環境不穩定
原因：資料庫連線池配置不當
解決：Mike 會在明天修正配置
問題：API 文檔更新不及時
原因：沒有自動化流程
解決：使用 Swagger 自動生成文檔
問題：Code Review 延遲
原因：大家都在自己的任務上
解決：設定 rule：PR 建立後 4 小時內必須有人審查
📋 行動項目（下個 Sprint）
1. 設定 Swagger 自動文檔生成
負責：Alex
檢查：Sprint 2 Day 3
2. 建立 Code Review SLA：4 小時回應
負責：全體
檢查：每日確認
3. 修正測試環境配置
負責：Mike
檢查：明天
4. 配對程式設計：資深帶新人
負責：Alex 配 Jenny/Tom
檢查：每週至少 2 次
團隊感謝：
🎉 感謝 David 的精美設計
🎉 感謝 Lisa 快速回應問題
🎉 感謝整個團隊的努力！
Sprint 1 度量
承諾故事點：26 點
完成故事點：26 點
完成率：100% ✅
速度（Velocity）：26 點
缺陷：
- 發現：5 個
- 修復：5 個
- 遺留：0 個
團隊滿意度：8.5/10
Sprint 2-4：核心功能開發
(略過詳細過程，總結關鍵點)
Sprint 2：興趣系統
Sprint 目標：「使用者可以選擇和管理興趣」
完成：
✅ 興趣分類列表（100+ 種興趣）
✅ 使用者選擇興趣（最多10個）
✅ 個人檔案顯示興趣標籤
✅ 興趣圖示設計
完成故事點：24 點
速度穩定 ✅
Sprint 3：檔案完善與社交登入
Sprint 目標：「完善個人檔案功能」
完成：
✅ Google 登入整合
✅ 上傳大頭照
✅ 編輯個人簡介
✅ 個人檔案完整度指示器
學習：
- Google 登入整合比預期複雜（iOS vs Android 不同）
- 圖片上傳需要壓縮功能
完成故事點：22 點
調整：下個 Sprint 預留緩衝時間處理技術難題
Sprint 4：配對算法 v1
Sprint 目標：「實作基本的配對推薦」
完成：
✅ 基於共同興趣的簡單配對算法
✅ 配對建議列表
✅ 發送連結請求
✅ 接受/拒絕請求
技術債：
⚠️ 配對算法需要優化（效能）
⚠️ 需要更好的推薦策略
決定：先上線簡單版本，根據數據再優化
完成故事點：20 點
Sprint 5：第一次危機
Sprint 規劃
Sprint 目標：「實作即時聊天功能」
選定故事：
1. [13點] WebSocket 即時聊天
2. [8點] 聊天介面
3. [5點] 聊天通知
總計：26 點
問題發生（Day 5）
Daily Scrum
Alex:
- 昨天：研究 WebSocket 實作方案
- 今天：繼續 WebSocket 實作
- 障礙：❌ WebSocket 在行動網路下不穩定
Lisa:
- 昨天：協助 Alex 測試
- 今天：研究替代方案
- 障礙：❌ 技術方案可能需要重新評估
Mike（SM）：
⚠️ 重大風險：核心技術方案可能不可行
→ 緊急會議：下午 2 點全員討論
緊急技術會議
問題：WebSocket 在 4G/5G 網路下連線不穩定
討論方案：
1. 繼續 WebSocket，加入重連機制
- 複雜度高
- 時間不確定
2. 改用 Firebase Cloud Messaging + Polling
- 技術成熟
- 但不是真正的即時
3. 使用第三方聊天服務（如 SendBird, Stream）
- 快速整合
- 但增加成本
決策：
Sarah（PO）決定：
「我們的核心價值不是聊天，而是配對。
使用 SendBird，專注在我們的核心功能。」
Sprint 目標調整：
「整合第三方聊天服務」✅
新的故事：
1. [8點] 整合 SendBird SDK
2. [5點] 聊天介面調整
3. [3點] 基本聊天測試
總計：16 點（承諾降低）
Sprint 結果
完成故事點：16 點
Sprint 回顧重點：
💡 學習：
- 技術方案需要更早驗證
- Build vs Buy 的決策很重要
- 靈活調整 Sprint 目標
📋 行動：
- 未來 Sprint 規劃前，高風險技術要做 Spike（探針）
- 建立技術決策文檔
團隊反思：
「雖然這個 Sprint 我們改變了方向，
但這就是敏捷的價值 - 快速發現問題，快速調整」
Sprint 6-10：MVP 衝刺
(總結關鍵里程碑)
Sprint 6：活動系統 v1
- 建立活動功能
- 報名活動
- 活動列表
Sprint 7：通知系統
- 推播通知整合
- Email 通知
- App 內通知
Sprint 8：搜尋與過濾
- 活動搜尋
- 使用者搜尋
- 進階過濾
Sprint 9：個人檔案完善
- 個人檔案驗證
- 隱私設定
- 黑名單功能
Sprint 10：效能優化
- API 回應時間優化
- App 啟動速度優化
- 圖片載入優化
累積進度
完成 Sprint：10/12
完成故事點：230/250
進度：92%
預計按時完成 ✅
Sprint 11-12：Beta 測試與發布
Sprint 11：Beta 測試
目標：「準備 Beta 版本並收集早期使用者回饋」
活動：
1. 招募 Beta 測試者（50人）
2. 建立回饋收集機制
3. 修復 Critical 缺陷
4. 優化使用者體驗
Beta 測試結果：
📊 註冊率：45/50（90%）
📊 平均使用時間：15 分鐘/天
📊 滿意度：7.5/10
📊 主要問題：
- 配對推薦不夠精準
- 活動資訊不夠豐富
- 需要更多社交功能
回饋處理：
✅ 立即修復：4 個 Critical bugs
📝 待辦清單：15 個改進建議
🎯 Post-MVP：10 個新功能想法
Sprint 12：正式發布
目標：「發布 ConnectNow 1.0 到 App Store 和 Google Play」
Week 1：發布準備
□ 最終測試
□ 準備行銷素材
□ 準備 App Store 資料
□ 準備支援文檔
□ 客服 FAQ
Week 2：發布執行
Day 1: 提交 iOS App Review
Day 3: iOS 審查通過 ✅
Day 3: 發布 Android 到 Google Play
Day 4: Android 上架 ✅
Day 5: 正式發布公告！🎉
Sprint 審查（也是專案回顧）
Sarah（PO）：
「6 個月前，我們從零開始。
今天，我們的 App 已經在 App Store 和 Google Play 上了！」
成果展示：
✅ 完整的 MVP 功能
✅ iOS 和 Android 雙平台
✅ 50+ Beta 使用者
✅ 4.5 星評價（Beta）
✅ 100+ 筆活動建立
✅ 500+ 次配對連結
度量：
- 總 Sprint：12
- 總故事點完成：252
- 平均速度：21 點/Sprint
- 缺陷密度：低
- 團隊滿意度：8.8/10
CEO 回饋：
「這個團隊展現了驚人的執行力。
從概念到產品只花了 6 個月，
而且品質非常好。我們準備好下一階段了！」
下一步（Post-MVP）：
- 擴大使用者規模
- 優化配對算法
- 增加社群功能
- 商業模式驗證
專案總結
數據統計
時間：
- 總週數：26 週（6 個月）
- Sprint 數：12 個 Sprint
- Sprint 長度：2 週
故事點：
- 總承諾：312 點
- 總完成：252 點
- 完成率：81%
- 平均速度：21 點/Sprint
品質：
- 總缺陷：45 個
- Critical：3 個（已修復）
- High：8 個（已修復）
- Medium：20 個（已修復）
- Low：14 個（部分修復）
- 測試覆蓋率：75%
團隊：
- 團隊規模：8 人
- 總人月：48 人月
- 離職：0 人
- 團隊滿意度：8.8/10
關鍵成功因素
✅ 1. 充分授權的 Product Owner
- Sarah 全職投入
- 快速決策能力
- 清晰的產品願景
✅ 2. 跨功能的團隊
- 所有技能都在團隊內
- 不依賴外部資源
- 快速協作
✅ 3. 技術實踐到位
- 自動化測試
- 持續整合
- 每日部署
✅ 4. 快速調整能力
- Sprint 5 技術方案調整
- 根據 Beta 回饋快速改進
- 不固守原計劃
✅ 5. 定期回顧改進
- 每個 Sprint 都有行動項目
- 團隊不斷優化流程
- 持續學習
學到的教訓
💡 1. 技術風險要早期驗證
教訓：Sprint 5 的 WebSocket 問題
改進：高風險技術先做 Spike
💡 2. Build vs Buy 的智慧
教訓：自建聊天耗時，改用第三方
改進：聚焦核心價值，非核心考慮購買
💡 3. MVP 範圍要克制
教訓：初期想做太多功能
改進：聚焦最小可行功能集
💡 4. 使用者回饋無價
教訓：Beta 測試發現許多假設錯誤
改進：更早進行使用者測試
💡 5. 團隊速度會穩定
教訓：前 3 個 Sprint 速度波動
改進：第 4 個 Sprint 後速度穩定，預測更準確
Scrum 的價值體現
🎯 回應變化的能力
- Sprint 5 技術方案轉向
- 根據 Beta 回饋調整優先順序
- 市場變化快速反應
📦 持續交付價值
- 每 2 週都有可展示的功能
- 早期就能開始 Beta 測試
- 6 個月完成 MVP
🔍 透明度
- 所有人都知道進度
- 問題早期暴露
- 投資人充分了解狀況
👥 團隊賦權
- 團隊自主決策執行方式
- 高度協作
- 團隊滿意度高
♻️ 持續改進
- 12 次回顧會議
- 執行了 30+ 個改進行動
- 流程越來越順暢
進階主題
Scrum of Scrums
當專案需要多個 Scrum 團隊時：
[Chief Product Owner]
│
┌───────────────┼───────────────┐
│ │ │
[Team A] [Team B] [Team C]
8 people 8 people 8 people
│ │ │
└───────────────┼───────────────┘
│
[Scrum of Scrums]
(每日或每週)
議程：
- 每個團隊的代表參加
- 討論團隊間依賴
- 解決跨團隊障礙
- 同步進度
Scaled Agile Framework (SAFe)
大型組織的敏捷實踐：
[Portfolio Level]
│
[Program Level] - Multiple Teams
│
[Team Level] - Individual Scrum Teams
DevOps 與 Scrum
Scrum + DevOps = 完整的價值交付
Scrum：
- 如何組織工作
- 如何協作
- 如何持續改進
DevOps：
- 如何自動化
- 如何快速部署
- 如何監控運維
整合：
- 每個 Sprint 自動部署
- 持續整合/持續交付
- 基礎設施即代碼
最佳實踐
1. Product Owner 最佳實踐
✅ 充分投入（至少 50% 時間）
✅ 清晰的產品願景
✅ 優先順序明確
✅ 驗收標準清楚
✅ 快速決策
✅ 信任團隊
2. Scrum Master 最佳實踐
✅ 僕人式領導
✅ 保護團隊
✅ 促進而非控制
✅ 教練而非命令
✅ 持續改進流程
✅ 移除障礙
3. 開發團隊最佳實踐
✅ 跨功能協作
✅ 自主承諾
✅ 透明溝通
✅ 持續整合
✅ 品質內建
✅ 互相幫助
4. Sprint 規劃最佳實踐
✅ 準備好的 Backlog（精煉過）
✅ 明確的 Sprint 目標
✅ 團隊充分理解需求
✅ 估計基於團隊共識
✅ 承諾實際可達成
✅ 預留緩衝（80% 產能）
5. Daily Scrum 最佳實踐
✅ 準時開始結束
✅ 全員參與
✅ 站著開會
✅ 聚焦目標和障礙
✅ 會後深入討論
✅ 更新任務板
常見陷阱
❌ 1. Scrum 但不敏捷
問題：
- 執行 Scrum 儀式但思維仍是瀑布式
- 把 Sprint 當成小型瀑布
- 不歡迎變更
解決：
- 回到敏捷原則
- 培養敏捷思維
- 擁抱變化
❌ 2. Product Owner 不投入
問題：
- PO 兼任多個角色
- 無法及時回答問題
- 不參加 Daily Scrum
影響：
- 團隊等待決策
- Sprint 目標不清
- 交付價值降低
解決：
- PO 至少 50% 時間投入
- 如果不行，指定 Product Owner 代理
❌ 3. 沒有完成定義
問題：
- 「完成」定義不明確
- 每個人理解不同
- 累積技術債務
解決：
- 建立清晰的 DoD
- 團隊共同制定
- 嚴格執行
❌ 4. Sprint 承諾過多
問題：
- 壓力大
- 品質下降
- 團隊疲憊
解決：
- 基於歷史速度規劃
- 預留 20% 緩衝
- 學會說「不」
❌ 5. 忽略回顧
問題：
- 沒有改進行動
- 重複相同問題
- 團隊士氣低落
解決：
- 認真對待回顧
- 追蹤行動項目
- 慶祝改進
工具推薦
專案管理
Jira: 最流行，功能強大
Trello: 簡單直觀
Azure DevOps: 微軟生態系
Linear: 現代化介面
溝通協作
Slack: 團隊即時通訊
Microsoft Teams: 企業方案
Zoom/Meet: 視訊會議
Miro: 線上白板
CI/CD
GitHub Actions: 整合 GitHub
GitLab CI: 整合 GitLab
Jenkins: 開源經典
CircleCI: 雲端方案
監控
Datadog: 全方位監控
New Relic: 應用效能監控
Sentry: 錯誤追蹤
延伸閱讀
書籍
- Scrum Guide - Ken Schwaber & Jeff Sutherland（官方指南）
- User Story Mapping - Jeff Patton
- The Agile Samurai - Jonathan Rasmusson
- Essential Scrum - Kenneth Rubin
認證
- Certified ScrumMaster (CSM)
- Professional Scrum Master (PSM)
- Certified Scrum Product Owner (CSPO)