在敏捷开发中，有时会出现下面的一些问题：

1. 迭代前工作量不好估计。
2. 敏捷开发造成技术方案破碎，无整体规划。
3. 迭代中方案变化，交付风险大。

在敏捷实践中，往往会有 Spike 这个实践，可以在一定程度解决这些问题。Spike 的目的是收集信息和寻找一个问题的答案，而不是交付具体产品。

我一直找不到一个好的中文词汇，有些书籍翻译为“探针”，通俗的来说就是研发人员正式开始启动一个大的技术方案前。提前“摸一下”，摸的好不好直接决定了后面的工作是否能很好的开展。

在我国的五代战斗机 J20 首飞 10 年的新闻中学到了一个新词 —— “技术预研”，其实能很好的描述 Spike 这实践，技术预研的价值在软件工程中同样明显。

技术预研的价值

工作量估算。工作量估算不准的原因是信息不够，技术预研可以提供这些信息，提前知道有哪些坑。工作量的评估对业务、产品规划极其重要，尤其是多个团队工作在一个项目上时。
人员能力培养。有一些团队技术预研工作往往被技术 leader 默认做了，这种做法有利有弊。不好的地方是团队成员得不到锻炼，只能实现一些预研好的内容，造成团队做方案的能力低。同时，也会消耗技术 leader 的工作时间，无关注其他工作。提前设计预研让团队来做，让技术 leader 评审即可。

输出技术方案。技术预研可以提前输出技术方案，避免在迭代开始后再进行设计工作，如果多个人在一类工作上，没要技术方案会各自为政。敏捷开发让这种情况放大，减低开发效率。

减低风险和减少浪费。一些技术方案可能客观上就不能实现，如果放入迭代交付可能在花费了时间分析后，结论是无法实现，造成浪费和交付风险。有可能因为这一个任务影响其他被依赖的工作内容。

预研工作规划

“生产一代、试制一代、预研一代、探索一代” ，这是我国航空工业尤其是军用飞机的发展计划。 J20 在 2011 年于成都黄田坝军用机场首飞 距今 10 年，但 1997 就开始立项，且比在之前就开始规划了。

结合敏捷工作方式，我们可以用类似的思路规划技术预研工作。

这里个“代”可以粗暴的设定为一个迭代，也就是 2 周，让策略更好落地实施。对于敏捷工作方式，如果进入迭代才开始验证技术方案的可行性、给出方案等工作，会给任务的拆分带来麻烦。

规划一代。提前两个迭代规划，这时候业务需要给出粗的业务目标，如果业务明显不合理，技术 leader 可以第一时间提出建议。这个阶段需要业务方准备相对大粒度的业务需求（非常细也不现实），计划好需要技术预研的工作内容。这个阶段的参与人为业务需求方和技术 leader 即可，技术 leader 可以通过经验得出能否实现，是否有价值预研，但是不知道细节和工作量。

技术预研一代。提前一个迭代预研，给出技术方案，并给业务方反馈。这个阶段就是预研的阶段，技术 leader 得到需要预研的工作后，可以通过兴趣让团队成员领取。这个阶段的预研工作通过空余的时间，通过兴趣驱动，需要设点一个时间范围（Time Box），截止时间一般在下个迭代的计划工作之前。技术阶段需要给出结果，这个结果可能是肯定的，也可能是否定的，还有可能需修改业务需求。总之，业务方可以拿到这个结论进行下个迭代的计划。

实现一代 。如果预研结果表明方案可行，进入迭代开始交付，开始前需要技术 leader 组织团队评审，并进一步得到更为细致的方案，比如：数据库设计、API 设计、数据迁移方案等。预研工作和实现工作最好是同一个人，如果无法做到，可以在实现过程中由预研工作的人指导。

技术预研的输出

技术预研往往可以看出一个开发者的专业性，不好的输出在人的脑子中，只要一个影子，而好的方案需要考虑到方方面面。

下面有一个清单供输出技术预研结果时使用，推荐使用 Markdown 文档记录。

demo 原型。原型的意义在于可以快速实现，没有当前项目的包袱，比较灵活。原型法是一个比较好的工程方法，业务原型有 Axure 线框图，技术原型则需要做一些小的 demo 去验证可行性。比如支付、人脸识别等，集成到业务代码中需要的成本和 demo 完全不同。
落地方案。需要考虑如何将原型落地到业务代码中，需要设计数据库、API、流程图等。还有落地的成本在和现有的逻辑结合，以及老数据的迁移和兼容问题。有一些技术方案还需要增加特性开关，考虑方案失败如何回退。

工作量。 需要给出具体的工作量，用于迭代排期。
风险点。在预研时，原型毕竟不能考虑所有的情形，可以给出一些风险点，便于团队决策，如果有备选方案就更好了。

任务拆分。 用于在实施中如何分布实现，好的任务拆分也可以工作量估算更准确，风险更小。