結論先講
Agile 不是一套流程，是一種心態：快速交付、快速回饋、快速調整。Scrum 適合需求相對明確的產品開發，Kanban 適合持續交付的維運或支援團隊，Scrumban 則是兩者的混合。別糾結於「我們做的是不是正統 Agile」，問自己：「我們有沒有比上個月更快交付價值？」
Agile 到底是什麼
2001 年的 Agile Manifesto 寫了四個價值觀：
| 我們更重視 | 而不是 |
|---|---|
| 個人與互動 | 流程與工具 |
| 可用的軟體 | 完整的文件 |
| 客戶協作 | 合約談判 |
| 回應變化 | 遵循計畫 |
注意：右邊的東西不是不重要，而是左邊的「更重要」。
Agile 的核心迴圈
計畫 → 開發 → 交付 → 回饋 → 調整 → 計畫 → ...
這個迴圈越短，你就越「敏捷」。瀑布模型的迴圈是 6-12 個月，Scrum 是 1-4 週，Kanban 是持續的。
Scrum 實戰指南
角色：三個就夠了
| 角色 | 真正的職責 | 常見誤解 |
|---|---|---|
| Product Owner (PO) | 決定做什麼、排優先順序 | 不是 PM、不是老闆的傳聲筒 |
| Scrum Master (SM) | 移除障礙、引導流程 | 不是專案經理、不是打雜的 |
| Development Team | 決定怎麼做、自組織完成工作 | 不是等指令的執行者 |
PO 常見問題
PO 最大的挑戰是「說不」。當五個利害關係人同時說他們的需求最重要，PO 要能根據數據和策略做出取捨。如果你的 PO 每次都說「老闆說的」，那他不是 PO，是轉發器。
儀式：四個，不多不少
1. Sprint Planning（Sprint 開始時）
| 項目 | 建議 |
|---|---|
| 時間 | 2 週 Sprint → 2 小時 |
| 參與者 | 全團隊 |
| 輸出 | Sprint Goal + Sprint Backlog |
實務建議：先定 Sprint Goal（一句話），再選 ticket。不是把 ticket 塞滿 Sprint，是挑能達成 Goal 的 ticket。
2. Daily Standup（每天）
| 項目 | 建議 |
|---|---|
| 時間 | 15 分鐘，嚴格計時 |
| 格式 | 昨天做了什麼 / 今天要做什麼 / 有什麼卡住 |
| 重點 | 同步資訊，不是進度報告 |
實務建議：如果每個人都在唸流水帳，那你的 standup 出了問題。重點是「卡住的事」——如果沒有卡住的事，30 秒講完就好。不要變成每個人對主管報告。
3. Sprint Review（Sprint 結束時）
| 項目 | 建議 |
|---|---|
| 時間 | 1 小時 |
| 參與者 | 團隊 + 利害關係人 |
| 格式 | Demo，不是投影片 |
實務建議：Demo 用活的系統，不要用截圖。讓利害關係人親手操作更好。Review 的目的是拿回饋，不是炫耀。
4. Sprint Retrospective（Sprint 結束後）
| 項目 | 建議 |
|---|---|
| 時間 | 1-1.5 小時 |
| 參與者 | 團隊內部（不包含利害關係人） |
| 輸出 | 2-3 個可追蹤的改善行動 |
實務建議：第八篇會深入講 Retro 怎麼做好。
產出物：三個
- Product Backlog：所有待做的事，PO 排序
- Sprint Backlog：這個 Sprint 要做的事
- Increment：Sprint 結束時可交付的產品增量
Kanban 實戰指南
什麼時候 Kanban 比 Scrum 好
- 工作類型多變（今天修 bug、明天做 feature、後天處理客訴）
- 沒有固定的發佈週期（持續部署）
- 團隊同時支援多個專案
- 維運、客服、DevOps 團隊
核心概念
1. 看板（Board）
To Do → In Progress → In Review → Done
每張卡片代表一個工作項目，從左移到右。
2. WIP Limit（Work In Progress 限制）
這是 Kanban 最重要的概念。
WIP Limit 限制每個欄位能有幾張卡片。例如：
| 欄位 | WIP Limit |
|---|---|
| To Do | 不限 |
| In Progress | 3（團隊 5 人） |
| In Review | 2 |
| Done | 不限 |
為什麼要限制？因為多工是效率殺手。一個人同時做三件事，每件事都在等他，結果三件事都做很久。限制 WIP 強迫你先完成手上的事再拿新的。
3. Flow（流動）
追蹤卡片從「開始」到「完成」的時間（Cycle Time）。如果平均 Cycle Time 越來越長，代表流程某處出了問題。
Kanban 沒有 Sprint
這是 Kanban 和 Scrum 最大的差異。Kanban 沒有固定的迭代週期，工作完成就拉新的進來。這讓 Kanban 更彈性，但也更需要紀律——因為沒有 Sprint 結束的壓力，工作可能會拖。
Scrumban：兩者的混合
越來越多團隊在用 Scrumban，取 Scrum 的結構和 Kanban 的彈性：
| 從 Scrum 拿 | 從 Kanban 拿 |
|---|---|
| Sprint 週期（但更彈性） | WIP Limit |
| Planning 和 Retro | 持續拉取工作 |
| Sprint Goal | 流量指標 |
適合場景
- 從 Scrum 轉過來，覺得太僵化
- 從 Kanban 轉過來，覺得太鬆散
- 團隊有部分產品開發、部分維運的混合工作
決策矩陣：哪個適合你
| 情境 | 推薦 | 理由 |
|---|---|---|
| 產品團隊，固定發佈週期 | Scrum | 結構化、容易管理 |
| 維運或支援團隊 | Kanban | 工作隨時進來、需要彈性 |
| 新創團隊，快速迭代 | Scrumban | 需要方向感但不想太僵化 |
| 一個人的 side project | Kanban | 不需要儀式，專注流動 |
| 外包團隊，有明確 deadline | Scrum | 客戶需要可預測的交付 |
| 跨職能團隊（開發 + 設計 + QA） | Scrum | 需要同步和對齊 |
Anti-patterns：Agile 劇場
以下症狀代表你的團隊在「演 Agile」而不是「做 Agile」：
1. Cargo Cult Scrum
做了所有儀式，但沒有吸收精神：
- Standup 變成 45 分鐘的進度報告
- Sprint Review 沒有利害關係人參加
- Retro 每次都講一樣的問題但沒有改善
- Sprint Planning 是 PO 單方面指派工作
2. Water-Scrum-Fall
前期花三個月寫需求文件 → 用 Scrum 開發三個月 → 最後花兩個月 UAT。這就是瀑布模型披了 Scrum 的皮。
3. Sprint 0, Sprint 0.5, Sprint -1
如果你的團隊有 Sprint 0（「準備期」），問問自己：為什麼不能在 Sprint 1 就開始交付？通常答案是「需求還不清楚」或「環境還沒準備好」——這些都可以在 Sprint 1 裡做。
4. 點數通膨
為了讓 velocity 看起來好看，團隊偷偷把估算調高。上個 Sprint 那個功能估 3 SP，這個 Sprint 差不多的功能估 5 SP。Velocity 數字漂亮了，但實際產出沒變。
5. 沒有 Definition of Done
「做完了」但沒有測試、沒有文件、沒有 deploy。下個 Sprint 一半時間在收拾上個 Sprint 的殘局。
「We do Agile」vs 真正的敏捷
| 表面敏捷 | 真正敏捷 |
|---|---|
| 每天開 standup | 團隊隨時同步，standup 只是形式之一 |
| 用 Jira | 工作流程透明，不管用什麼工具 |
| 兩週一個 Sprint | 持續交付價值，Sprint 只是節奏 |
| PO 寫 User Story | 團隊和使用者直接對話 |
| Sprint 結束才 deploy | 隨時可以 deploy |
| Retro 寫在白板上 | 改善行動有人追蹤、有期限 |
最好的檢驗方法：問你的團隊「上次你們根據使用者回饋調整方向是什麼時候？」如果答不出來，你可能沒有在做 Agile。
實用建議：開始導入的步驟
如果你的團隊還沒用任何 Agile 方法，別想一步到位：
- 第一週：建立看板（To Do / In Progress / Done），把現有工作視覺化
- 第二週：開始每日 standup（15 分鐘，站著）
- 第三週：設定 WIP Limit
- 第四週：第一次 Retro（回顧這個月什麼有用、什麼沒用）
- 第二個月：如果需要更多結構，開始嘗試 Sprint
不需要一次到位，慢慢疊加就好。Agile 本身也應該用 Agile 的方式導入。
FAQ
Q1：小團隊（2-3 人）需要做 Scrum 嗎？
不需要完整的 Scrum，太重了。建議用 Kanban + 每週一次的 planning/retro。2-3 個人每天坐在一起，自然就同步了，不需要正式的 standup。
Q2：PM 堅持用瀑布，我能做什麼？
你可以在團隊內部用 Agile 的方式工作（看板、WIP Limit、短迭代），對外用 PM 要求的格式報告。很多團隊都是這樣運作的——內部敏捷、外部瀑布。
Q3：Scrum Master 一定要專職嗎？
理想上是，但小團隊通常不可能。可以讓 tech lead 或 senior 工程師兼任，但要注意：SM 不是管人的，是服務團隊的。如果 SM 同時是主管，他很難在 retro 裡聽到真話。
Q4：兩週的 Sprint 太長或太短？
兩週是最常見的起點。如果你的團隊交付節奏很快（例如每天 deploy），可以試一週。如果需求很大很複雜，可以試三週。但超過四週就不算 Sprint 了，那是 mini waterfall。
Q5：遠端團隊怎麼做 Agile？
核心不變，工具調整。用 Slack 或 Teams 做非同步 standup（每天早上寫三句話），用 Miro 或 FigJam 做遠端 Retro，用 Linear 或 Jira 做看板。最重要的是保持透明——讓每個人都能看到誰在做什麼、什麼卡住了。