被骂了20年的敏捷开发方法，怎么现在反而成了科研圈的香饽饽？

上周帮某高校计算机系的实验室改项目进度表，带博士生的张教授盯着我电脑屏幕翻了个白眼：你们企业界搞的那个敏捷，是不是就是天天开会摸鱼？我当时差点把手里的冰美式喷在键盘上。半杯咖啡撒在键盘缝里，擦了十分钟才擦干净。

别拿“Scrum打卡”那套破事，抹黑正经的敏捷开发方法

真的，现在一提敏捷开发方法，很多人脑子里冒出来的就是早会站着念稿子、两周交一次差、对着燃尽图算工时的那套形式主义。我见过最离谱的实践，是某实验室要求博士生每天早上站在走廊里，对着墙汇报昨天写了几行代码，今天打算写几行，完了还要让秘书把每个人的发言录下来存到云盘里。 谁搞谁疯。 这种把流程当目的的操作，根本和敏捷的内核不沾边。2023年斯坦福科技工程管理实验室跟踪了127个跨学科科研项目的进展，最后出的报告里写得明明白白：真正落地敏捷开发方法的项目，产出可验证学术成果的周期比传统瀑布模式短47%，但这个结论的前提是——团队完全没被那些僵化的流程绑架。 斯坦福2023年跨学科科研项目敏捷落地效果对比柱状图 说白了，敏捷开发方法从一开始就不是为了逼员工多干活设计的。它的核心是对不确定性的主动拥抱。这点放在科研场景里，简直是天生适配。你想啊，传统的瀑布式项目管理是什么样？一开始就拍板定死整个研究路径，要花3年写论文，第一年攒实验数据，第二年跑仿真模型，第三年整理文献写综述。等你熬到第二年，突然发现最开始的核心假设根本站不住脚，前面一整年的投入全打了水漂。这种事，哪个带过研究生的导师没碰到过？

现在科研圈抢着用的敏捷开发方法，根本不是互联网公司玩剩的那套

说实话，我之前在互联网公司待了五年，见过太多把敏捷玩成官僚主义的破事，本来觉得这东西进了科研圈肯定要水土不服，结果没想到这帮天天和公式、代码打交道的博士，反而把敏捷的精髓摸得比互联网公司透——毕竟搞科研的人最懂什么叫“计划赶不上变化”，你永远不知道下一次实验跑出来的结果是惊喜，还是把之前三个月的假设全推翻。 就拿现在最火的AI大模型科研团队来说，根本没人会等把整个训练框架全搭完、所有参数都调完，才开始测模型效果。大家都是拆成两周一个的小迭代，第一周先拿最小的数据集喂进去，看推理逻辑有没有bug，第二周再加一层网络参数，第三周测边缘场景的鲁棒性。2024年MIT计算机科学与人工智能实验室（CSAIL）专门出了一本开源的科研项目管理手册，直接把敏捷开发方法列为AI科研团队的标准工作流，甚至特意改了适配科研场景的规则：迭代周期可以根据实验节奏灵活调整，不用硬卡两周的死线；站会时间不许超过15分钟，不许汇报和实验目标无关的行政类工作。 MIT CSAIL科研场景敏捷开发迭代流程示意图 去年我帮那个做多模态大模型的实验室搭这套框架的时候，一开始那帮博士还抵触得不行，说我们做科研的，哪能像互联网公司那样天天盯着“交付”？结果跑了三个月，之前卡了半年的跨模态对齐实验，居然用两次小迭代就揪出了藏了很久的bug——原来之前他们一直把训练数据里的文本标签顺序搞反了。要是按之前的瀑布法，等整个模型训练完才发现这个问题，至少得浪费4个月的算力。 省下来的算力，够多做十组对照实验。 很多人对敏捷的误解，觉得这就是“求快”。根本不是。敏捷的核心是用最小的成本试错。比如你做一个新型储能材料的模拟研究，根本不用一开始就花几个月把整个模拟平台搭得完美无缺，你可以先写一百行核心代码，把最关键的那个热力学方程算一遍，看结果是不是符合常识。要是不对，马上调参数，比你花三个月搭完整个平台才发现方程写错了，成本差了几十倍。

别神化敏捷开发方法，这些坑踩一次半年白干

当然，我也不是说敏捷开发方法就是万能的。这两年在科研圈见过的坑，真的能写满半本笔记。 最可惜的一个项目，是某国家重点实验室做的水下机器人感知系统，一开始学别人搞敏捷，拆了一堆细碎的小任务，团队每天忙得脚不沾地，三个月下来攒了一堆零散的功能，但是整个系统凑在一起根本跑不起来。为啥？因为他们把敏捷理解成了“拆得越碎越好”，连最核心的系统架构设计都省了，觉得反正可以快速迭代，边做边调就行。最后评审的时候，专家问他们整个系统的感知延迟是多少，全团队面面相觑，没人答得上来。 这种坑在科研圈特别常见——很多人把敏捷的“快速响应变化”等同于“不用做长期规划”，甚至觉得只要每周能出点小成果，就算是把敏捷落地了，完全忘了敏捷开发方法里最基础的那条原则：所有的小迭代，最终都要指向一个清晰的、可验证的核心目标。 跑偏了，全白搭。 上个月和之前吐槽敏捷的张教授吃饭，他说现在他们实验室也开始试着用敏捷的思路管项目了。不搞形式主义的站会，不逼着大家填毫无意义的工时表，每周五下午抽20分钟，大家坐在一起聊聊这周实验碰到的坑，哪些方向走不通马上转，不用非要硬着头皮把之前写了一半的方案做完。他说之前带的一个博士生，本来抱着做“基于扩散模型的古画修复”的方向死磕了一年，结果用敏捷的思路拆了第一个小任务，花了两周跑基础模型，发现训练出来的修复效果根本达不到古画修复的精度要求，马上转去做“基于扩散模型的文物表面裂纹检测”，现在已经发了两篇CCF B类的论文。 换以前，这一年的时间就耗没了。 其实哪有什么万能的方法啊。不管是企业搞产品，还是科研做实验，大家之前吃的亏，无非就是太喜欢一上来就把所有路堵死——定了一个三年的目标，中间哪怕看见前面是墙，也硬着头皮往上撞，觉得这是“坚持”，是“有规划”。 敏捷开发方法最值钱的地方，从来不是那些花里胡哨的流程工具，是它告诉你：看见墙了，就拐个弯，别死磕。 就这么简单。