一、敏捷开发概述：什么是敏捷开发、敏捷宣言与原则、为什么因子工厂需要敏捷

1.1 什么是敏捷开发？——别把它想得太玄乎

敏捷开发，说白了就是一种「小步快跑、持续交付」的做事方式。

我刚开始接触敏捷时，也觉得它就是个开会方法——每天站一站、两周开个回顾会，完事。后来真正在量化项目里用起来，才发现完全不是这么回事。

传统开发模式，好比你要盖一栋楼。先画好完整图纸，再打地基、砌墙、封顶，最后才能住人。整个过程可能半年、一年，中间客户想改个窗户位置？对不起，得加钱，还得重新审批。

敏捷开发呢？更像是在搭乐高。你先搭个能站住的小模型，给客户看。他说「窗户位置不对」，你当场拆了重搭。两三天后，又一个新版本出来了。就这样，边搭边改，边改边交付。

在因子工厂的场景里，这个「客户」就是量化研究员。他们今天想要一个动量因子，明天发现数据源有问题，后天又觉得计算逻辑要优化。你想想看，如果用传统瀑布模型，等三个月后交付，黄花菜都凉了。

1.2 敏捷宣言与原则——四句话，但字字千金

2001年，17个软件大佬聚在犹他州的滑雪场，聊出了《敏捷宣言》。一共四句话：

注意，不是「不要流程、不要文档」，而是「更看重左边」。我见过很多团队，把敏捷理解成「不用写文档」，结果项目交接时一团糟。嗯，这里要划个重点：右边的东西也有价值，只是左边更优先。

基于这四句话，又衍生出12条原则。我挑几条跟因子工厂最相关的说说：

• 尽早、持续地交付有价值的软件——因子工厂里，哪怕只跑通一个因子计算，也比憋三个月出个大版本强。
• 欢迎需求变化，即使是在开发后期——量化策略迭代快，今天用的因子，下周可能就失效了。你必须有拥抱变化的准备。
• 业务人员和开发人员必须每天在一起工作——我在项目里吃过亏，研究员和开发隔着一道墙，结果做出来的因子计算引擎，研究员根本用不顺手。
• 团队定期反思如何更有效——每两周坐下来聊聊：哪里卡住了？哪里可以优化？别等到项目崩了才复盘。

1.3 为什么因子工厂需要敏捷？——三个血泪教训

你可能觉得，因子工厂不就是写写计算逻辑、调调参数吗？用敏捷是不是小题大做了？

我直接说结论：不用敏捷，因子工厂大概率会做成「一次性工具」。为什么？

传统开发的问题	在因子工厂中的表现	敏捷如何解决
需求不明确	研究员说「我要一个波动率因子」，但具体怎么算？用哪种波动率？数据频率？他可能自己都没想清楚。	先做一个最小可用版本，跑出结果再迭代
数据源频繁变化	今天用Wind数据，明天换聚宽，后天又加了个另类数据。接口、格式、字段全不一样。	短周期迭代，每次只适配一个数据源
计算逻辑复杂	一个因子可能涉及多表关联、时间序列计算、去极值、中性化……写出来容易，跑对难。	持续集成+自动化测试，每次改动都验证

我曾经参与过一个因子工厂项目，团队用了传统瀑布模型。先花两个月写需求文档，再花三个月开发，最后一个月测试。结果呢？交付那天，研究员说：「这个因子我们已经不用了，现在用另一个。」——六个月的投入，打了水漂。

1.4 敏捷在因子工厂中的落地框架

说了这么多理论，来张图直观感受一下。下面这张图展示了因子工厂的敏捷开发核心流程：

1.5 小结：敏捷不是银弹，但它是因子工厂的「氧气」

说了这么多，其实就一句话：因子工厂的本质是「快速实验」，而敏捷开发就是让这个实验能跑起来的机制。

没有敏捷，你可能会陷入「需求永远在变、代码永远在改、交付永远在延期」的泥潭。有了敏捷，至少你能保证：每个版本都是可用的，每次反馈都是有价值的，每个迭代都是向前走的。

我个人习惯，在项目启动时就跟团队说清楚：我们不是在做一件完美的艺术品，而是在做一件能用的工具。先让它能用，再让它好用，最后才让它漂亮。这个顺序，千万别搞反了。

---

公众号:蓝海资料掘金营，微信deep3321