Spike 回顾

起因

在当前的项目已经快一年了，当初团队成员的一句要求，给大家换来了定期的Innovation Week。在这一周里可以不用专注于当前手上乱七八糟的各种问题和令人有喜有忧的新功能，而是专注于另一项自己感兴趣的小工具、特定使用场景，也可以是某个疑难杂症。而在一周结束之后，团队成员汇聚一堂做简单的成果分享，然后结束这个过程。所以我们的做法本质上还不是Spike，但相互之间却有很多值得借鉴的地方。

这样做的好处显而易见，给成员留足了时间去学习新工具、新技术，也可以看作是一种变向的自我学习周期。当然，从管理者角度出发，无疑燃烧了经费成本，但却不一定对项目有明显的效果。偶然之后才意思到这个Spike的过程是个专业术语，前人早就有了较好的模式和实践流程，而自身尽然摸爬滚打野路子出家弄了半年。好在回过头来看，并没有走 太多的错路，弄出一些奇怪的实践。但却是时候回顾这个Spike原本的样子，然后理解它，免得日后张冠李戴。

什么是Spike?

Spike 常见的英文翻译是“长钉或者刺穿”，作为名词，也可以作为动词。 Spike 一词来源于攀岩中的比喻， 在攀岩过程中，攀岩的人在没有办法落脚的情况下选择使用岩钉作为锚点来保护自己，从而避免跌倒或协助后续的辅助攀登。其次，这个词来源于 Extreme Programming (XP)

而这个词在软件开发中来源于 Extreme Programming

“A spike solution is a very simple program to explore potential solutions.”

来到敏捷开发过程中，由于敏捷中强调不确定性、拥抱变化，那么在日常开发过程中，也会遇到一些任务。比如技术方案或者未知的探索，于是敏捷中的 Spike 是一项技术调研。通过简答的调查、设计、demo 来快速验证，这样说起来和 POC(prove of concept) 是不是很像。

特殊的 “Spike”：起源于客户一次偶然提出的建议，希望在完成项目要求的任务同时，能够有一些自由一些的时间去完成自己感兴趣的技术主题的研究，来提高自身的能力。所以我们把那一小段时间也看成是 Innovation Week，用于去探索新的、未曾使用过的技术。但我们一直用 “Spike” 来描述这样的事情，似乎也解释得通。

较之于 Extreme Programming（极限编程）中的解释最大的不同，我个人认为是对开发人员的自由度。毕竟前者是项目中存在的不确定性和问题亟待解决，而后者 让开发人员有较大的自由度去选择一个新的技术主题进行任意的探索。

为什么要做Spike?

对于极限编程中的 Spike，虽然 Spike 本身没有完成相应的功能，没有交付业务功能，但是为后续可能遇到的难题扫除了障碍、降低了不确定性，从而保障最终业务价值的交付、减少延期的风险，好处已经人人皆知了。

而对亲历的项目中的 “Spike” 而言，从个人角度而非项目的角度有以下几个优点：

• 激励个人创新，大胆尝试
• 学习新的技术栈，提升个人能力，拓宽视野
• 作为紧张的迭代中的一个缓冲期，得以缓和情绪和整理心情

Spike与故事卡的区别？

Spike 在某种程度上可以是一种特殊的user story，区别在于用户故事交付产品业务功能，需求目标相对明确；二spike本身不交付产品功能，问题明确，但在实际做的过程中可能有很多的不确定性。

如何来做Spike?

已经“巧立名目”了，那么接下来就是大展身手，做出点小小的成果的时候了。

第一步: 选定主题

可以是你已经了解的技术栈，但是没有深入研究的某一部分；

也可以是你从其他项目偶然听到的新名词，但是你从来没有实际上手接触过；

另外，如果你想“讨好”项目，那么从技术债中选择一块硬骨头也是一个不错的选择；

亦或是未雨绸缪，率先走入即将被项目采用的新技术中去“探探路”，为项目减少一些隐藏的风险；

如果实在没有头绪，不妨翻阅往期的技术雷达（都是大佬们已经帮你筛选过了的技术条目，又新又好）；

或者交给网络，用搜索引擎搜一下类似的关键字 Top 10 New Technology Trends for 2023。

第二步: 初步了解

万般开头难，进入这一步也是真正的开始研究了。既然手中掌握着最关键的线索了，那么以下几个搜索资料的渠道不妨试试：

• 官方网站 （历史起源、安装/使用方法、功能模块、Roadmap 等等
• Github 源码 （查看它的开发语言进一步了解特性，Star数量，Issue数量和常见问题
• 论坛 （避坑指南，踩坑大全，也许有一些最佳实践）
• Youtube 上的大会视频 （看看视频，听听作者或布道师的理解）
• …

第三步：罗列大纲

为了避免漫无目的，在进行了初步的之后相信你应该大概知道自己想要做些什么，可以在有限的时间内完成哪些任务了。那么把他们按优先级罗列出来或许能时刻提醒自己，也是帮助进一步缩小范围。用一些简要的关键字描述即可，毕竟咱们可是“新手”。

第四步：总结归纳

完成了大部分的任务也别忘了留一点时间，做一下简单的回顾，反思在哪些地方浪费了时间以及踩过的坑，某个问题是否值得关注；或者对比自己用过的同类型工具做一个快速的优劣势分析。

第五步：展示成果

以上如果通通做完了，那么不妨把你的成果和发现给团队成员展示一下，也可以适当邀请其他小组对该主题感兴趣的同学。当然如果能够邀请到客户或者 PO 莅临效果更加，别忘了做一个稍微美观一些的 PPT 。或许有一些意想不到的问题出现，也会有经验丰富的同学给予一些好的建议，帮助我们下次考虑得更周到，做得更好。

回顾一下

在适当的时间开启 Innovation Week，并鼓励团队成员大胆自由地尝试新技术栈和工具，起初或许非常的新鲜。但这一过程也不是总是一帆风顺的，可能灵感枯竭找不到合适的主题，可能忙活了3-5天也没能产出一个好的成功的Demo，又或者辛苦做出来的成果不完全被他人认可…

Reference:

• https://en.wikipedia.org/wiki/Spike_(software_development)
• http://agiledictionary.com/209/spike/
• https://www.leadingagile.com/2016/09/whats-an-agile-spike-who-should-enter-it-how-to-word-it/