Post

如何把 User Story 拆小？之實際常見拆法

Posted Updated
By Elaine
15 min read

在上一篇文章我們介紹了怎麼用 SPIDR 原則（Spike、Path、Interface、Data、Rules）來拆小 Story

不過 SPIDR 比較像是拆解的「方向提示」，就像地圖上的指南針，幫助我們找到有可能拆解的面向，但具體要怎麼拆，還是需要一套實際的方法

這篇文章，我們就來介紹 幾種常見又實用的 User Story 拆解模式，幫助你面對那些「這故事太大了，塞不進 Sprint」的情況，能有具體做法可以用

10 種常見故事拆法

1. 依工作流程分步拆（Workflow Steps）

從使用者完成任務的流程出發，把每一步分開做

  • 範例：線上訂餐流程
  • 拆法：
    • 選擇餐點
    • 填寫外送地址
    • 完成付款
    • 餐廳接單與通知出餐

2. 按商業規則拆（Business Rule Variations）

當故事裡有很多 if…else 或不同情境邏輯，就能按規則逐一拆開

  • 範例：會員折扣計算
  • 拆法：
    • 一般會員折扣
    • VIP 折扣
    • 節日活動折扣（如生日、雙11）

3. 拆出最困難的工程（Major Effort）

先做最困難、最基礎的部分，大部分精力將用於實現第一個部分，讓功能可用，後面再慢慢疊加

  • 範例：串接第三方金流
  • 拆法：
    • 信用卡付款
    • Apple Pay
    • 街口支付或 LINE Pay

4. 先簡單、再複雜（Simple / Complex）

先推出最小版本，其他變化之後慢慢補

  • 範例：上傳個人大頭貼
  • 拆法：
    • 單張圖片上傳
    • 圖片裁切與預覽
    • 拖曳更換頭像

5. 資料變化拆（Variations in Data）

同一功能會吃不同資料時，可以資料為單位來拆

  • 範例：推播通知訊息
  • 拆法：
    • 中文推播
    • 英文推播
    • VIP 客製化通知

6. 輸入方式拆（Data Entry Methods）

如果 UI 上輸入資料的方式不同，也能分開做

  • 範例：新增待辦事項
  • 拆法：
    • 手動輸入新增
    • 語音輸入新增
    • 從截圖自動偵測待辦

7. 延後系統品質（Defer System Qualities）

先做「功能」，晚點再補「效能」、「穩定性」、「即時性」這些品質

  • 範例：顯示即時通知
  • 拆法：
    • 每分鐘輪詢一次
    • 後續再改為 WebSocket 即時推送

8. 依 CRUD 操作拆（Operations）

看到「管理」就可以想：註冊、修改、刪除 → 各自做一張

  • 範例：部落格文章管理
  • 拆法：
    • 新增文章
    • 修改文章
    • 刪除文章

9. 按使用情境拆（Use Case Scenarios）

故事包含多種情境或角色時，每個情境都可以是獨立一張卡

  • 範例：檢舉留言功能
  • 拆法：
    • 登入使用者檢舉
    • 未登入者跳轉登入
    • 被檢舉者收到通知

10. 拆出 Spike（技術研究任務）

當技術細節不明時，先做一張 Spike Item 研究清楚

  • 範例：圖片壓縮功能
  • Spike：調查 sharp、imagemin 等套件是否能壓縮圖片並保有品質

Bill Wake 提出的 20 種拆法

Bill Wake 在《Twenty Ways to Split Stories》中提出 20 種從不同維度切入的拆解方式：

The Big Picture（整體觀）

  1. Research vs Action
    • 比較：研究比行動容易
    • 原因：研究是針對做法、工具或解法的可行性做資料收集與比較，不需動手實作；而行動則是包含研究後實際寫程式或執行任務的過程
    • 例子：
      • 想建立通知機制，先調查市面上有哪些推播服務（如 FCM、OneSignal）以及收費方式
      • 想做系統整合前，先研究現有 API 的授權與限制（如是否支援 OAuth2、是否有 rate limit）
  2. Spike vs Implementation
    • 比較：Spike（技術探索）比正式實作容易
    • 原因：Spike 是一種短期、目的明確的原型實驗，用來驗證技術做不做得到，而非實際交付可上線的功能
    • 例子：
      • 想實作指紋辨識登入，在正式開發前，先建立一張 Spike Story：用 React Native 嘗試串接指紋辨識 API 建立 demo
      • 想支援多國幣別轉換，先做 Spike 嘗試整合免費匯率 API，看看是否更新即時、資料格式能不能轉換
      • 想用 WebSocket 做聊天室同步，先建立 Spike 測試 Socket.IO 能不能順利跑在內部環境上
  3. Manual vs Automated
    • 比較：手動流程比自動化容易
    • 原因：手動流程可以先交付價值，日後再自動化
    • 例子：審核流程先讓客服人工處理，等穩定後再改為自動審核機制
  4. Buy vs Build
    • 比較：購買比開發容易
    • 原因：現成工具節省大量開發與測試時間
    • 例子：購買商用圖表元件庫如 Highcharts，取代自行開發圖表模組
  5. Build vs Buy
    • 比較：自行開發比套件更適合特定需求
    • 原因：若套件不符需求，維護與客製成本反而更高
    • 例子：客服系統要求高彈性回覆流程，因此選擇自己建置

User Experience（使用者體驗）

  1. Batch vs Online
    • 比較：批次處理比即時互動容易
    • 原因：批次系統不需與使用者即時互動，邏輯單純
    • 例子：報表系統先做成每日批次產出 CSV，之後再提供線上即時查詢功能
  2. Single-User vs Multi-User
    • 比較：單使用者比多使用者容易
    • 原因：無需考慮多使用者同步問題與帳號系統設計
    • 例子：先實作單一使用者的記事功能，再加上多人共享與同步機制
  3. API only vs User Interface
    • 比較：只有 API 比做完整 UI 容易
    • 原因：透過程式就可驗證邏輯，省去畫面設計與測試成本
    • 例子：先寫 API 並用 Postman 測試訂單建立功能，再開發前端介面操作流程
  4. Character UI / Script UI vs GUI
    • 比較：文字/腳本介面比圖形化介面容易
    • 原因：CLI 通常沒有複雜互動，功能驗證快
    • 例子：內部工具先用指令列腳本執行排程，後來才建立 GUI 介面供業務操作
  5. Generic UI vs Custom UI
    • 比較：通用元件 UI 比客製化介面容易
    • 原因：可快速使用既有元件，節省開發時間
    • 例子：表單使用 Bootstrap 元件先交付 MVP，後續再重新設計風格與互動細節

Ilities（非功能性）

  1. Static vs Dynamic
    • 比較：靜態資料比動態計算容易
    • 原因：靜態只需設定一次，動態需每次依條件變動重新計算
    • 例子：設定檔先用固定值寫死在程式中，之後再改為動態由後台載入
  2. Ignore errors vs Handle errors
    • 比較：忽略錯誤比處理錯誤容易
    • 原因：錯誤處理需更多防呆與例外控制
    • 例子：登入功能一開始只處理成功案例，錯誤訊息日後再補上完整提示
  3. Transient vs Persistent
    • 比較：暫存資料比持久化資料容易
    • 原因：不需考慮資料同步與儲存格式
    • 例子：購物車資料先存在記憶體中，待結帳時再寫入資料庫
  4. Low fidelity vs High fidelity
    • 比較：低擬真比高擬真容易
    • 原因：初期只需功能運作，後期再強化外觀與體驗
    • 例子：商品圖片先上傳低畫質版本，之後再提供高清切換與放大檢視
  5. Unreliable vs Reliable
    • 比較：不穩定比穩定容易
    • 原因：可靠性需更多監控、容錯與驗證機制
    • 例子：第一次上線的推播系統沒有重送機制，後續才加入保障機制
  6. Small scale vs Large scale
    • 比較：小規模比大規模容易
    • 原因：資料量小較易管理與驗證
    • 例子：先針對內部 10 人試用平台，日後才支援上千人規模
  7. Less “ilities” vs More “ilities”
    • 比較：少考慮非功能性容易
    • 原因：非功能性需求可延後實作（如效能、擴充性、安全）
    • 例子：MVP 階段先不考慮資料加密，等正式版上線前再加密與稽核紀錄

Features（功能邏輯）

  1. Few features vs Many features
    • 比較：功能少比多容易
    • 原因：越多功能越容易牽一髮動全身
    • 例子：購物平台第一版只支援商品瀏覽與下單，付款、通知、評價等延後開發
  2. Main flow vs Alternate flows
    • 比較：主要流程比替代流程容易
    • 原因：Happy Path 是最基本流程，先確保主流程沒問題再擴展例外狀況
    • 例子：表單送出成功流程先做，錯誤重試、網路中斷等例外情境後補
  3. 0 vs 1
    • 比較：處理「無」比處理「有」容易
    • 原因：0 是最單純的狀態，不需儲存與轉換
    • 例子：通知系統先支援「不推播」（0），再做推播單一訊息（1）
  4. 1 vs Many
    • 比較：處理一個比多個容易
    • 原因：多筆需要處理排序、批次與 UI 優化
    • 例子：上傳圖片功能先做單張，再做多張與拖曳排序
  5. Split condition vs Full condition
    • 比較：條件拆分比一次處理全部容易
    • 原因：複雜條件可分段實作、逐步驗證
    • 例子：促銷邏輯先只支援「滿額折扣」，再加入「指定商品 + 滿件免運」
  6. One level vs All levels
    • 比較：單層比多層容易
    • 原因：階層越多越難同步與呈現
    • 例子：組織圖先只顯示第一層主管與員工，之後再支援遞迴展開全層級
  7. Base case vs General case
    • 比較：基本情況比一般通則容易
    • 原因：基本情境可先證明功能通順，再處理各種例外與擴展
    • 例子：處理商品價格先處理單一幣別，再支援多國幣種、匯率轉換等

結語：拆 Story 沒有唯一解，但總有更小的方式

這幾種方法不是要你全都背起來，而是讓你每當遇到「這故事太大怎麼辦？」的時候，有各種角度可以去切、去想

當你會拆 Story，你的團隊會更流暢、開發速度更快、Demo 更精彩、客戶更開心

參考資料

軟實力
鈦坦教會我的那些事 敏捷 工程效率 流程優化 軟實力
This post is licensed under CC BY 4.0 by the author.