如何做好敏捷技术预研(Spike)?

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

  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、流程图等。还有落地的成本在和现有的逻辑结合,以及老数据的迁移和兼容问题。有一些技术方案还需要增加特性开关,考虑方案失败如何回退。

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

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

评论已关闭