什麼是 Spike Item？

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

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

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

Spike 是什麼？

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

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

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

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

Spike 的三大原則

根據 Dean Leffingwell 的建議，Spike 必須具備：

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

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

Spike 與一般 User Story 差異

項目	一般 User Story	Spike 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 的價值在於：帶來可接受的行動依據與知識輸出

參考資料

• A User Story Primer
• What is Spike in Scrum?