什么是敏捷开发中的Spike？
Spike，如果需要翻译的话，中文可以翻译成“探针”，但是一般不会翻译而直接使用Spike这个词。
Spike可以理解为：以回答问题或收集信息为目的的任务，而不是生产非专业产品的任务。有时编写User Story时，无法很好地对其进行估算User Story Point，直到开发团队做一些实际工作来解决技术问题或设计问题为止。解决这一问题的方法是创建一个“Spike”，这代表要做一些工作，其目的是提供解决问题的方法或者寻找解决问题的答案。
英文解释：
A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.
Spike这个术语来自极限编程（XP）。一个Spike指的是一个用来探索/寻找潜在的解决问题的方法（探针）。XP大师Ward Cunningham 解释了这个术语是如何在C2.com的wiki上被创造的。
Ward Cunningham说：“我经常问Kent[Beck]，我们能做的最简单的事情是什么，它能让我们相信我们在正确的轨道上？” 这种走出目前困难的做法常常使我们能够找到更简单和更有说服力的解决办法。Kent称之为Spike。“我发现这种做法在维护大型框架时特别有用。”
其实在Scrum中，常常会用到下面的三个术语（或者其中的一个）：
- Spike – a quick and dirty implementation, designed to be thrown away, to gain knowledge – indicator: unable to estimate a user story effectively
- Research – broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate – indicator: don’t know a potential solution
- Tracer Bullet – very narrow implementation in production quality of an epic/large user story – indicator: user story is too large in estimation
了解了什么是Spike，Research和Tracer Bullet之后，我们在Scrum中就可以使客户和团队能够确定何时以及如何实施这些活动。我们决定与客户一起开展一个有时间限制的Spike和Research活动。这些是在一次迭代中完成的，用于帮助定义即将到来的User Story 的估算和在下一次迭代中开始的起点。
虽然估算是Spike和Research的指标（indicator），但它们不是最终目标。Spike或Research还包括：
- 了解“如何”实现业务价值（Understand “how” to implement a piece of business value）
- 提出帮助客户做出商业价值决策的解决方案（Propose a solution to help the customer make business value decisions）
- 最小化实现业务价值的成本中隐藏的风险 （Minimize risk hidden in the cost of implementing a piece of business value）
- 运用投资模型控制研发成本 （Control the cost of R&D through the use of an “investment” model）
Tracer Bullet用于将Epic或大的User Story拆分成较小的Epic或者User Story，并对软件产品的Backlog或者New Features产生一定的影响。假设团队在讨论一个User Story时，引入了新的架构元素，那么Tracer Bullet可以实现引入这种新的架构元素到软件产品中，而不需要过度详细的用户接口/UI。例如，如果与我们的Peoplesoft和Siebel 实例，并且希望显示来自两个系统的客户信息，那么我们可以有Tracer Bullet类型的User Story，例如：
- 作为客户服务代表，我想查看客户的姓名和多个系统的标识符
在实现这个用户故事时，我们可能还有许多其他的Backlog/User Story，这些User Story必须从其中一个或两个系统中检索额外的客户信息。这个团队把这些定义和指标放在墙上，作为一个大而漂亮的信息共享单元以供团队成员参考。其他团队也开始在自己的项目中使用这些描述，以帮助阐明与客户的基本工作。
可能有人会写下这样的User Story：
- 作为客户服务代表，我想查看客户的姓名和账号ID
- 作为客户服务代表，我想查看客户的姓名和所在区域、电子邮件、联系电话等
- ……
虽然在前端，每个“作为客户服务代表”的角色希望查看到客户的姓名和其它多种不同的信息；但是在系统设计和实现的后端，可以通过良好的设计（或者接口设计）来实现功能。这就是Tracer Bullet的作用。
