Post

什麼是 Spike Item?

在敏捷開發流程中,我們常會遇到一種情境:

因為資訊不足,我們無法準確估計,也不確定該怎麼做

這種時候,就適合安排一個 Spike 任務,目的是進行短時間的研究或驗證,幫助團隊降低不確定性,為後續的開發鋪路

Spike 是什麼?

Spike 是一種以學習為目的的工作項目,用來處理:

  • 技術上我們沒碰過的問題
  • 第三方 API、SDK 的可行性驗證
  • 架構選型前的比較分析
  • 尚未明確定義的需求探索

Spike 最常出現在開發人員說出這句話的時候:

「我不知道這能不能做,也不知道要花多久時間」

Spike 的三大原則

根據 Dean Leffingwell 的建議,Spike 必須具備:

  • Estimable 可估計:有時間範圍
  • Demonstrable 可證明:有明確產出
  • Acceptable 可接受:完成後有用,能讓團隊做出決策

Spike 不是「模糊研究」的代名詞,而是用來處理特定未知的短期任務

Spike 與一般 User Story 差異

項目一般 User StorySpike Story(探索型任務)
目的交付對使用者有價值的功能獲取知識、驗證技術可行性
可估性可用點數或時間估算開發工時固定 Timebox(例如 0.5 ~ 2 天內完成)
成果可展示/可交付的功能決策依據、筆記、驗證結果、PoC
驗收標準功能可運作、通過測試、可 Demo問題有清楚結論,結果有助於後續拆解
是否可拆解通常可拆成更小 Story通常不拆,但執行後可幫助拆 Story

Spike Story 並不是開發功能,而是為了降低後續 Story 的風險與模糊,讓實作可以順利開始

什麼時候該用 Spike?

你可以這樣判斷:

問題適合 Spike 嗎?
不知道這技術能不能支援✅ 適合 Spike
不知道怎麼估時✅ 適合 Spike
功能邏輯太複雜,需要先理清✅ 適合 Spike
只是覺得麻煩,不想做❌ 不適合 Spike
功能早已確認,只是細節多❌ 不適合 Spike(應該直接拆小任務)

Spike 並非用來逃避規劃與責任,也不是為了替代 Story。它應該是臨時探索性的策略,幫助釐清尚未決定的技術或需求面向

技術 Spike 與功能 Spike

Spike 通常分為兩種類型:

技術 Spike(Technical Spike)

用於評估新技術對現有實作的影響。團隊可能會嘗試實驗一種技術,以便在承諾某項功能之前能更有信心

範例:

  • 測試一個從未用過的雲端儲存服務是否能滿足需求
  • 比較 Kafka 與 RabbitMQ 哪個更適合現有架構

功能 Spike(Functional Spike)

用於探索不明確的業務需求或使用者行為。可能需要快速原型、線框圖、流程模擬等

範例:

  • 透過 UX 線框圖測試使用者對不同付款流程的反應
  • 模擬登入流程以確認帳號驗證邏輯與操作習慣是否一致

Spike 的輸出應該包含什麼?

完成一個 Spike,建議至少交付以下產出:

  • 清楚的探索結論(推薦 A 解還是 B 解?)
  • 驗證紀錄、技術筆記或操作步驟
  • 原型或 PoC(如果需要)
  • 後續工作建議(例如:現在可以開始實作哪些功能)

範例:要整合 Stripe 支付

情境:團隊要整合 Stripe 支付功能,但沒人用過 Stripe API

Spike 安排如下

  • 目標
    • 是否支援我們的幣別與付款方式
    • 是否能快速整合
    • 安全性與合規是否滿足
  • 時間限制:1 天
  • 交付內容
    • 研究紀錄
    • 測試程式或原型(PoC)
    • 結論與建議:是否推薦使用 Stripe

決策與估算:Spike 還是直接做?

在面對不確定工作時,建議優先考慮是否能夠直接拆分成小任務,而不是一律使用 Spike:

  1. 嘗試使用 INVEST 原則或其他故事拆解策略來拆成小任務
  2. 如果依然無法估時或無法開始開發,再使用 Spike

Spike 是解決問題的其中一種策略,不是唯一解法

結語

Spike 是讓團隊減少猜測、提升決策品質的重要工具,不論你們是否跑 Scrum、使用工具,它都能自然地整合進你們的工作流程中

用得好,它能:

  • 降低未來開發風險
  • 協助做出更正確的選擇
  • 提高後續任務的估時與可行性

用得不好,它就成了「永遠在研究但從不實作」的陷阱

Spike 的價值在於:帶來可接受的行動依據與知識輸出

參考資料

This post is licensed under CC BY 4.0 by the author.