当团队无法估算时：使用Spike

在敏捷开发中，团队经常面临仅通过估算无法回答的问题。*我们应该使用GraphQL还是REST？我们的系统能处理10,000个并发用户吗？这个第三方库已经可以投入生产了吗？*这些就是Spike变得非常有价值的时刻。

什么是Spike？
#

术语"Spike"源于极限编程（XP），在那里它指的是"一个非常简单的程序来探索潜在解决方案"。可以把它想象成在你的问题上钉入一根钉子——一个专注的、有时间限制的努力，以获得自信前进所需的知识。

Spike 不是提供客户价值的用户故事。相反，它是一个研究任务，旨在：

回答特定的技术或功能问题
在承诺采用某种方法之前减少不确定性
为更准确的估算提供数据

Spike的输出是知识，而不是可工作的软件。这种区别对于适当的待办事项管理和冲刺计划至关重要。

Spike的类型
#

了解Spike的两种主要类型有助于团队适当地应用它们：

技术Spike探索实施方法：

评估框架或库
原型架构模式
特定条件下的性能测试
调查与外部系统的集成复杂性

功能Spike探索用户需求：

澄清模糊的用户故事
验证关于用户行为的假设
使用原型测试UI/UX方法
理解领域复杂性

为什么Spike很重要？
#

解决不确定性：在复杂项目中，试图估算具有重大未知因素的工作会导致估算过高或错过截止日期。Spike将"我不知道"转换为可操作的信息，使团队能够自信地做出承诺。

为决策提供信息：在面对架构决策或技术选择时，Spike提供证据而不是意见。调查结果直接反馈到决策文档中，确保选择有实际调查的支持。

降低风险：通过预先投资少量有限的时间，团队可以避免以后代价高昂的转向。一个两天的Spike揭示了库的局限性，比在开发三个冲刺后发现同样的问题要便宜得多。

提高估算准确性：对于不熟悉工作的故事点通常是猜测。在Spike之后，团队可以使用关于复杂性、依赖性和潜在障碍的实际数据进行估算。

何时使用Spike
#

Spike适用于以下情况：

团队由于技术未知因素无法自信地估算故事
存在多个可行的解决方案，需要数据来选择
正在考虑新技术、框架或集成
性能特征不确定且关键
尽管与利益相关者讨论，需求仍然模糊

Spike 不适用于：

团队已经知道如何做的工作
推迟可以用现有信息做出的决策
替代适当的需求收集或用户验收测试

执行Spike的框架
#

1. 定义

标题：一个清晰的、以问题为中心的名称（例如，“评估Redis与Memcached用于会话存储”）
目标：要回答的具体问题——不是"研究缓存"而是"确定Redis集群能否满足我们50ms的延迟要求"
范围：明确将要和不会调查的内容的边界
时间盒：通常为1-3天；如果需要更多，Spike可能太宽泛
成功标准：如何知道Spike达到了目标

2. 研究和探索

数据收集：审查文档、案例研究和现有实现
原型制作：构建最小的概念验证代码——可丢弃的，不是生产就绪的
咨询：与专家、供应商或社区论坛互动
实验：用实际代码和测量测试假设

3. 文档

调查结果：尽可能有数据的具体结果
建议：明确的下一步及其理由
风险和挑战：已识别的障碍及其缓解策略
代码/工件：任何原型的链接（明确标记为Spike输出，而非生产代码）

4. 审查

展示：与团队和利益相关者分享结果
反馈：收集问题和替代观点
待办事项调整：根据调查结果创建、完善或删除故事

5. 结束

整合：确保知识被捕获以供将来参考
回顾：在下一次回顾中反思Spike过程本身

Spike模板
#

## Spike: [标题]

**时间盒**: [X天]
**负责人**: [姓名]
**冲刺**: [冲刺编号/名称]

### 要回答的问题
[此Spike将回答的单一、集中的问题]

### 背景
[为什么需要此Spike；是什么引发了不确定性]

### 假设
- [假设1]
- [假设2]

### 范围
**范围内**:
- [项目1]
- [项目2]

**范围外**:
- [项目1]

### 成功标准
- [ ] [标准1]
- [ ] [标准2]

### 调查结果
[在Spike期间完成]

### 建议
[Spike后完成]

### 后续故事
- [ ] [故事1]
- [ ] [故事2]

假设在Spike中的作用
#

每个Spike都始于假设——构建调查框架的基础性信念。明确这些假设有几个目的：

建立背景：利益相关者理解起点
揭示偏见：假设可以在调查开始前受到挑战
集中精力：Spike测试假设而不是漫无目的地探索
澄清结果：根据陈述的假设解释结果

例如，关于数据库选择的Spike可能假设：“我们的数据模型主要是关系型的"和"读操作将以10:1的比例超过写操作。“如果这些假设在调查期间被证明是不正确的，那本身就是一个有价值的发现。

常见陷阱
#

范围蔓延：Spike应该回答一个具体的问题，而不是成为开放式的研究项目。如果出现新问题，请将它们记录下来以备将来的Spike，而不是扩展当前的。

过度设计原型：Spike代码是用来丢弃的。当你开始为Spike代码添加错误处理或测试时，你可能已经从探索转向实现了。

跳过文档：Spike的价值超出了立即的决定。面临类似问题的未来团队成员从记录的调查结果中受益。

将Spike视为承诺：揭示某种方法行不通的Spike是成功的。目标是学习，而不是验证预定的答案。

将Spike整合到冲刺计划中
#

在规划冲刺时，请考虑：

在估算前进行Spike：如果故事有重大未知因素，在当前冲刺中安排一个Spike，并在未来的冲刺中进行实际工作
限制并发Spike：多个Spike会分散注意力；每个冲刺一两个通常就足够了
不要给Spike打分：由于Spike产生知识而不是可工作的软件，许多团队通过时间盒而不是故事点来跟踪它们
在细化中包含Spike结果：在团队估算相关故事之前展示Spike结果

结论
#

Spike将不确定性从焦虑的来源转变为学习的机会。它们承认软件开发的一个基本事实：在调查之前，我们通常不知道我们不知道什么。

当适当使用时，Spike使团队能够做出明智的技术决策，提供准确的估算，并避免代价高昂的项目中期转向。它们体现了敏捷的响应变化原则——通过在承诺行动之前投资于理解。

下次你的团队面对一个产生更多问题而非答案的故事时，考虑一下Spike是否可能是你可以做的最有价值的工作。有时，前进的最快路径是暂停和学习。

什么是Spike？#

Spike的类型#

为什么Spike很重要？#

何时使用Spike#

执行Spike的框架#

Spike模板#

假设在Spike中的作用#

常见陷阱#

将Spike整合到冲刺计划中#

结论#

延伸阅读#