結論先講
需求拆分是專案能不能準時交付的第一道關卡。拆不好，後面的估算、排程、追蹤全部會歪掉。一個好的 ticket 應該要小到一個人兩天內能做完、明確到不用再跑去問 PM「你到底要什麼」。
這篇會用「電商結帳功能」當例子，從一句話需求拆到大約 15 張 ticket，讓你看到完整的拆分過程。
為什麼需求拆分這麼重要
你一定遇過這種場景：
PM：「我們要做一個電商結帳功能。」 工程師：「好，大概要多久？」 PM：「越快越好。」
然後工程師開始寫 code，寫到一半才發現：要不要支援超商取貨？金流要串哪家？發票要怎麼開？庫存扣在哪個時間點？
結局就是：需求不斷追加、時程不斷延長、大家不斷加班。
模糊的需求是 scope creep 的溫床。
需求拆分做得好，你會得到：
- 可以準確估算的工作項目
- 可以平行開發的獨立任務
- 可以追蹤進度的具體指標
- 可以跟 PM 對齊的共同語言
Epic → User Story → Task 階層
需求拆分有一個經典的三層結構：
| 層級 | 定義 | 粒度 | 範例 |
|---|---|---|---|
| Epic | 一個大的商業目標或功能模組 | 數週到數月 | 電商結帳功能 |
| User Story | 從使用者角度描述的一個完整功能 | 1-5 天 | 使用者可以選擇超商取貨 |
| Task | 工程師的具體實作項目 | 數小時到 1 天 | 實作超商門市查詢 API |
Epic 怎麼定
Epic 通常對應一個商業目標。你可以用這個公式：
為了 [商業目的]，我們需要 [功能模組]
例如：「為了讓使用者能在網站上完成購買，我們需要結帳功能。」
User Story 怎麼寫
User Story 的經典格式：
As a [角色], I want to [做什麼], so that [為什麼]
例如：「身為一個購物者，我想要在結帳時選擇超商取貨，這樣我不在家也能收到包裹。」
INVEST 原則：好的 User Story 長什麼樣
| 原則 | 說明 | 反例 |
|---|---|---|
| Independent | 故事之間盡量獨立 | 「A 做完才能做 B」（代表拆得不好） |
| Negotiable | 可以討論調整 | 寫得太死，沒有協商空間 |
| Valuable | 對使用者有價值 | 「重構資料庫」（這是 task，不是 story） |
| Estimable | 可以估算 | 「做 AI 推薦」（太模糊無法估算） |
| Small | 夠小 | 「做結帳功能」（這是 epic） |
| Testable | 可以驗收 | 「改善使用者體驗」（怎麼驗？） |
常見錯誤判斷
- 太大：如果一個 story 估出來超過 5 天，代表需要再拆
- 太小：如果一個 story 是「改按鈕顏色」，那應該是 task，不是 story
- 太模糊：如果工程師看完還要問三個問題以上，代表 AC 不夠清楚
Acceptance Criteria：Given-When-Then
Acceptance Criteria（AC）是 User Story 的驗收條件。沒有 AC 的 story 等於沒有終點線的賽跑。
Given-When-Then 格式
Given: [前提條件]
When: [使用者操作]
Then: [預期結果]
範例：選擇超商取貨
AC1: 選擇超商取貨
Given: 使用者在結帳頁面
When: 使用者選擇「超商取貨」配送方式
Then: 顯示超商選擇介面，隱藏地址輸入欄位
AC2: 選擇超商門市
Given: 使用者已選擇超商取貨
When: 使用者從地圖上選擇一間門市
Then: 顯示門市名稱、地址，並儲存為配送地址
AC3: 超商取貨運費
Given: 使用者選擇超商取貨
When: 訂單金額未滿 $500
Then: 顯示運費 $60
實戰範例：拆解「電商結帳功能」
假設 PM 跟你說：「做一個結帳功能，要支援信用卡、超商取貨、開發票。」
Step 1：列出 User Stories
| # | User Story | 估算 |
|---|---|---|
| 1 | 使用者可以查看購物車摘要 | 2 SP |
| 2 | 使用者可以填寫配送地址 | 3 SP |
| 3 | 使用者可以選擇宅配 | 2 SP |
| 4 | 使用者可以選擇超商取貨 | 5 SP |
| 5 | 使用者可以選擇信用卡付款 | 5 SP |
| 6 | 使用者可以選擇貨到付款 | 2 SP |
| 7 | 使用者可以填寫統編開發票 | 3 SP |
| 8 | 使用者可以在送出前確認訂單 | 2 SP |
| 9 | 系統在結帳時檢查庫存 | 3 SP |
| 10 | 使用者送出訂單後收到確認信 | 2 SP |
Step 2：把大的 Story 再拆成 Tasks
以「使用者可以選擇信用卡付款」（5 SP）為例：
| Task | 估算 |
|---|---|
| 研究金流商（綠界/藍新）API 文件 | 0.5d |
| 實作金流 SDK 整合（後端） | 1d |
| 設計信用卡表單 UI（前端） | 0.5d |
| 實作信用卡表單驗證 | 0.5d |
| 實作付款 API endpoint | 0.5d |
| 串接金流回呼（webhook） | 0.5d |
| 處理付款失敗重試邏輯 | 0.5d |
| 撰寫整合測試 | 0.5d |
| Code Review + QA | 0.5d |
一個 5 SP 的 story 拆出 9 個 task，每個 task 都在半天到一天之間。這就是可以排進 sprint 的粒度。
Step 3：標注依賴關係
[購物車摘要] ─→ [配送地址] ─→ [宅配/超商取貨]
│
↓
[信用卡/貨到付款]
│
↓
[發票] ─→ [確認頁]
│
↓
[庫存檢查 + 確認信]
有依賴的要注意排序，沒依賴的可以平行開發。
常見拆分錯誤
1. 按技術層拆（而不是按使用者價值拆）
錯誤：
- Ticket 1：建立資料庫 schema
- Ticket 2：寫後端 API
- Ticket 3：做前端頁面
問題：前兩張 ticket 做完，使用者什麼也用不了。
正確：按 user story 拆，每張 ticket 都是一個可以 demo 的功能切片。
2. 忽略 edge cases
結帳功能的 edge cases：
- 庫存不足怎麼辦？
- 付款逾時怎麼辦？
- 同時有折價券和紅利點數怎麼計算？
- 使用者付款到一半關掉瀏覽器？
這些都應該是獨立的 ticket，不要塞在主 ticket 裡面。
3. 缺少「看不見的工作」
除了功能 ticket，別忘了：
- 環境設定（金流測試環境）
- 資料遷移
- 效能測試
- 文件撰寫
- 部署設定
工具推薦
| 工具 | 適合場景 | 優點 | 缺點 |
|---|---|---|---|
| Jira | 大團隊、企業 | 功能完整、報表強 | 太複雜、速度慢 |
| Linear | 中小型工程團隊 | 快速、鍵盤操作 | 自訂欄位較少 |
| GitHub Projects | 開源或小團隊 | 跟 code 整合 | 功能陽春 |
| Notion | 非工程團隊也要用 | 彈性大 | 沒有內建 sprint 管理 |
我個人推薦 Linear 給工程團隊——它的速度和設計哲學都是為開發者打造的。
拆分檢查清單
在開 sprint planning 之前，用這個清單檢查你的 ticket：
- 每個 story 都有明確的 Acceptance Criteria
- 每個 story 都符合 INVEST 原則
- 估算在 1-5 SP 之間（超過就再拆）
- Edge cases 有獨立的 ticket
- 依賴關係已標注
- 「看不見的工作」（環境、測試、文件）已列入
- PM 和工程師都看過並同意
FAQ
Q1：User Story 一定要用「As a… I want to… So that…」格式嗎？
不一定。格式是幫助你思考的工具，不是教條。重點是：(1) 從使用者角度出發 (2) 有清楚的目的 (3) 有可驗收的標準。如果你的團隊習慣用其他格式，只要資訊完整就好。
Q2：一個 Sprint 應該有多少 ticket？
沒有標準答案，取決於團隊大小和 sprint 長度。但一個經驗法則是：每個人每個 sprint 認領 3-5 個 story。太多代表粒度太細（可能在管理 task 而不是 story），太少代表 story 太大。
Q3：需求一直變怎麼辦？
需求會變是正常的，問題是怎麼管理。做法是：(1) 新需求走 backlog，不要直接插進當前 sprint (2) 如果非插不可，要拿掉等量的 ticket (3) 記錄每個 sprint 的 scope change，用數據跟 PM 溝通。
Q4：技術債算 User Story 還是 Task？
技術債如果對使用者有間接影響（例如效能優化讓頁面載入從 5 秒降到 1 秒），可以寫成 User Story。如果純粹是內部重構，就當 Task 掛在一個技術改善的 Epic 下面。重點是讓它出現在 backlog 裡，而不是藏在工程師心裡。
Q5：跨團隊的需求怎麼拆？
跨團隊的需求（例如結帳功能需要前端、後端、金流串接），建議用「垂直切片」而不是「水平切片」。也就是說，一個 ticket 包含前後端，讓一個小組可以端到端完成。如果真的無法避免跨團隊，在 ticket 上標注依賴和交付時間。