做 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 不打故事点，按时间盒管理；结论要在梳理会上讲，赶在团队估算相关故事之前。

延伸阅读

#

本网站相关文章：

• 回顾：反思Spike结果 - 把 Spike 的收获纳入持续改进
• 用户验收测试 - 验证基于 Spike 的决策是否满足用户需求
• 决策文档 - 把 Spike 结论沉淀成结构化的决策
• API计划 - Spike 如何支撑 API 设计决策

外部资源：

• Spike - 规模化敏捷框架（SAFe） - SAFe 关于大规模实施 Spike 的指南
• Spike解决方案 - 极限编程 - Spike 的 XP 出处
• Scrum指南 - Spike 在 Sprint 计划中的位置
• Martin Fowler论技术债务 - Spike 如何帮助预防技术债务

我经历过的最糟糕的几次回顾会，长得一模一样：Sprint 目标没达成，于是整整一小时变成"为什么没完成"的审讯大会。而最好的几次回顾会，几乎没怎么提目标本身。我们聊的是这段时间怎么干活的、什么东西拖了后腿、下次想换个什么做法。这个差别，就是所谓"不被结果绑架的心态"。自己带着团队跑了一段时间 Sprint 之后，我越来越觉得这是 Scrum Master 最要紧的一种素质。

先说清楚：结果当然重要。流程漂亮但什么都发不出去的团队，没人会发工资。但是，完成 Sprint 是团队的活儿；Scrum Master 的活儿是改进那台"产出 Sprint 的机器"。这是两份不同的工作，我见过的 Scrum 乱象，大多是从把这两件事搅在一起开始的。

Scrum Master 和项目经理有什么区别

#

这两个角色经常被混为一谈，部分原因是不少公司干脆让一个人兼着。核心区别是：

Scrum 本身没有项目经理这个角色。项目经理平时干的不少活，分到了产品负责人（决定做什么、先做什么）和开发人员（规划怎么做）身上。

放下对结果的执念之后，会变好的几件事

#

首先，团队才有空间真正当家做主。Scrum 的前提本来就是自组织团队，可一个为每个结果提心吊胆的 Scrum Master，不知不觉就会把手伸进决策里。团队很快就学会了：“反正拍板的不是我们。“把重心放回流程，你才能放手让大家去实验、偶尔做错决定、再从里面学到东西。主人翁意识只能这么长出来。

回顾会也会变得诚实。当会议室里的问题是"为什么数字没达标”，真话就藏起来了；换成"什么拖慢了我们、下次试点什么”，大家才肯开口。Sprint 中途冒出来的障碍也一样：执着结果的 Scrum Master 会为交期慌了手脚，专注流程的那位则闷头去把拦路的东西清掉；如果拦路的是一个谁都还没摸清的问题，就提议做一个限定时间的 Spike 去查清楚。

跟利益相关方的关系也会缓和许多。如果你能讲的故事只有燃尽图，那任何一点波动看起来都像失败。要是还能讲清楚团队学到了什么、怎么在调整，大家的预期就会现实得多——很多本来会在 Sprint 中途砸到团队头上的压力，你也就能在外面替他们挡掉。

如果你已经在为某个结果魂不守舍

#

道理都懂，做起来难，我知道。当你在某件事上投入很深的时候，“专注过程"听起来就像冰箱贴上的鸡汤。

说几个对我真正有用的办法。第一，别为"在乎结果"责怪自己——想要一个结果是人之常情，装作不在乎撑不了多久。第二，把结果目标翻译成你能控制的过程目标：不是"赢下这场比赛”，而是"每天练 30 分钟"。发布受不受欢迎你控制不了，但有没有做过评审、跑过测试、提前演示过，你控制得了。第三，看清是什么在给执念添柴。要是你一天刷十遍仪表盘或者股价，就定好固定的查看时间，其余时间不看。路上的小胜利也要记得庆祝，不然远处那个大目标会把你的注意力吃得干干净净。如果这种执念已经严重到影响睡眠和日常生活，去找专业人士聊聊很值得，一点也不丢人。

结果依然重要。但那些能稳定拿到结果的团队，背后总有一个人在照看"怎么做"，而不只是"做出了什么"。