做 Sprint 计划时，隔三差五就会冒出一个谁也打不了分的故事。估算从 2 到 13 都有，有人来一句"这个嘛，得看情况"，讨论就开始原地打转。*用 GraphQL 还是 REST？系统真扛得住一万并发用户吗？这个第三方库敢上生产吗？*这类问题靠估算是估不出来的，只能动手去查。Spike 就是干这个的。
Spike 是怎么来的#
这个词出自极限编程（XP），原意是"用来探索候选方案的极简程序"——像往问题里钉进一根钉子。放到今天，它就是一个限定了时间盒的短期调研任务，产出的是知识，不是能跑的软件。Spike 不是用户故事，本身不产生客户价值，这没关系：它的职责就是把一个具体的问题回答清楚，好让真正的工作能被诚实地估算和排期。
实践中分两类。技术 Spike 探索"怎么做"：评估框架或库、给架构模式做原型、在贴近真实的条件下压测性能、搞清楚一个外部集成到底有多麻烦。功能 Spike 探索"做什么"：把含糊的故事掰清楚、用一次性原型验证 UI 思路、把领域里的复杂性啃到能理解为止。
为什么值得花这个时间#
带着大块未知去估算，结果无非两种：注水的估算，或者爆掉的工期。Spike 把"不知道"变成实打实的数据，团队才能理直气壮地做承诺。它还能把观点之争变成证据之争——与其吵哪个数据库更好，不如花两天去测，测出来的结论可以直接写进决策文档。
说到底，这是很便宜的保险。花两天做个 Spike 发现某个库的硬伤，比开发推进三个 Sprint 之后才撞上同一堵墙，代价小得多。
什么时候该用，什么时候不该用#
该用的场景：团队因为技术上的未知没法放心估算；有好几个可行方案，需要数据来选；正在考虑引入新技术、新框架或新集成；性能既不确定又很关键；跟利益相关方开了无数次会，需求还是模糊。
不该用的场景：团队本来就会做的活儿，别 Spike；手头信息已经够做决定了，别拿 Spike 当拖延的借口。另外，Spike 也代替不了正经的需求梳理和用户验收测试——它回答的是一个问题，不负责验证整个产品。
我的做法#
第一步，把问题写下来。不是"研究缓存"，而是"Redis 集群能不能满足我们 50ms 的延迟要求？"。划清范围——查什么、不查什么；时间盒定在一到三天（再长就说明问题太大了）；再定好成功标准，这样才知道什么时候算完。
然后就是调研：读文档和案例，搭一个最小可用的概念验证，找做过的人聊聊，用真实代码去测量。Spike 的代码从写下第一行起就是准备扔的。
时间盒一到，把调查结果、带理由的建议、发现的风险写成文档，原型链接要注明"这是 Spike 产物，不是生产代码"。向团队汇报，回答提问，再根据学到的东西调整待办列表——新建故事、细化故事、砍掉故事，都行。还建议在下一次回顾里复盘一下 Spike 本身的做法，这件事练几次就会明显熟练起来。
我在用的模板#
## Spike: [标题]
**时间盒**: [X天]
**负责人**: [姓名]
**冲刺**: [冲刺编号/名称]
### 要回答的问题
[此Spike将回答的单一、集中的问题]
### 背景
[为什么需要此Spike；是什么引发了不确定性]
### 假设
- [假设1]
- [假设2]
### 范围
**范围内**:
- [项目1]
- [项目2]
**范围外**:
- [项目1]
### 成功标准
- [ ] [标准1]
- [ ] [标准2]
### 调查结果
[在Spike期间完成]
### 建议
[Spike后完成]
### 后续故事
- [ ] [故事1]
- [ ] [故事2]“假设"这一栏很值。动手之前先写下"我们的数据模型基本是关系型的"“读写比大概 10:1”，有两个好处：别人可以在你烧掉时间盒之前就挑战你的前提；而如果调研到一半发现某条假设站不住，那不是白干两天，那本身就是重要发现。
Spike 容易跑偏的几种方式#
最经典的是范围蔓延——Spike 悄悄变成了没有尽头的研究课题。新问题一定会冒出来，冒出来就记下来，留给下一个 Spike，别扩大当前这个。第二种是把原型做过头：当你发现自己在给 Spike 代码加错误处理、写测试的时候，你已经从探索越界到实现了。第三种是不写文档——半年后总会有人碰到同样的问题，你那两天的心得不该就这么蒸发。最后一种是把 Spike 当成对既定答案的背书。一个证明了"此路不通"的 Spike，恰恰是干得漂亮的 Spike。
怎么排进 Sprint 计划#
几条在规划冲刺时管用的习惯：故事里真有硬未知，就本个 Sprint 做 Spike，实际开发放到后面的 Sprint；每个 Sprint 最多一两个 Spike，多了注意力就散了；别给 Spike 打故事点——它产出知识不产出软件，按时间盒管理就好；Spike 的结论要在梳理会上、在团队估算相关故事之前讲，而不是之后。
下次再遇到一个问题比答案多的故事，不妨想想：这个 Sprint 里最有价值的工作，也许就是做个 Spike。停下来把事情搞懂，往往才是最快的路。
延伸阅读#
本网站相关文章：
- 回顾：反思Spike结果 - 把 Spike 的收获纳入持续改进
- 用户验收测试 - 验证基于 Spike 的决策是否满足用户需求
- 决策文档 - 把 Spike 结论沉淀成结构化的决策
- API计划 - Spike 如何支撑 API 设计决策
外部资源：
- Spike - 规模化敏捷框架（SAFe） - SAFe 关于大规模实施 Spike 的指南
- Spike解决方案 - 极限编程 - Spike 的 XP 出处
- Scrum指南 - Spike 在 Sprint 计划中的位置
- Martin Fowler论技术债务 - Spike 如何帮助预防技术债务
- 敏捷联盟：Spike - 敏捷联盟对 Spike 的定义和指导