Post

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

上一篇文章我們介紹了怎麼用 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.