别再把敏捷开发方法当万能膏药：踩过3年坑后我攒的实操干货

上周跟一个做生物医药科研项目的负责人吃饭，他拍着桌子骂，说花了20万报了所谓的敏捷咨询课，团队从早到晚开站会，写用户故事，三个月过去了，本该出的细胞实验数据平台连个像样的导出功能都没做出来。

我当时夹了一筷子烤串，差点笑出声。

这太常见了。

被误解了20年的敏捷开发方法，根本不是让你天天开会

很多人对敏捷的印象，就是墙上贴满彩色便签，所有人站在会议室里轮流说“我昨天做了啥，今天要做啥，碰到了啥阻碍”，每两周搞一次评审会，把攒了俩星期的代码拿出来演示。

但真不是。

那些从2001年就开始在一线做敏捷实践的老工程师都知道，最初的敏捷宣言四条核心原则，本质上是在反对当年那种花半年时间写几百页需求文档、改一个需求就要走三层审批的僵化流程，根本不是让你把所有精力都花在凑会议时长、填流程模板上。

MIT斯隆管理学院2022年做了一个覆盖1200个研发团队的长期跟踪研究，结论挺扎心的：那些把敏捷流程搞成教条主义的团队，交付效率比沿用传统瀑布模型的团队还低23%。原因很简单——他们把所有时间都花在维护流程的完整性上，根本没腾出手来解决实际问题。

我第一次看到这个数据的时候一点都不意外。

就拿我之前碰到的那个生物科研团队来说，他们硬套通用互联网公司的敏捷流程，要求所有任务必须拆成不超过8小时的工作量，每个sprint严格卡2周周期，哪怕是做需要连续观察7天的细胞染色实验，也要硬拆成两个迭代的任务。结果呢？做实验的学生每天要花20分钟填进度表，每周要开3次固定评审会，本来3个月能做完的实验，硬生生拖到了半年。

说白了，很多团队学敏捷，学的是皮，不是骨。他们以为贴几张便签、开几次站会就是敏捷了，根本没搞懂敏捷的核心是“快速拿到反馈，少做无用功”，不是为了走流程而走流程。

真的适配科研场景的敏捷开发方法，要敢把流程拆得稀碎

之前接触过一个做流域生态监测的科研团队，他们的敏捷实践说出来可能很多人觉得“不正规”——没有固定的sprint周期，没有强制要求的站会，甚至连墙上的便签墙都拆了。

就这么个“不正规”的团队，最后把原来要做18个月的监测数据平台，8个月就上线了，而且科研人员的满意度比之前用瀑布做的版本高了三倍。

他们是怎么做到的？

首先把原来每季度一次的大版本交付，拆成每3天就能跑通的最小可运行单元。比如做水质监测数据的可视化模块，第一个3天就先把传感器传上来的原始数据在屏幕上显示出来，不用做精美的图表，不用做多维度筛选，哪怕是一串乱跳的数字都行。第二个3天，加个按时间排序的功能。第三个3天，做个最简单的折线图。每做完一个小版本，就拉负责采样的科研人员过来看看，哪里不对马上改，根本不等攒到最后一次性交付。

别觉得这事儿小儿科。

之前他们用瀑布方法做第一版系统的时候，整个可视化模块攒了4个月，最后交上去才发现，科研人员要的是能直接导出符合SCI论文格式的矢量坐标图，结果他们做的是给普通公众看的炫彩大屏，颜色晃得人眼睛疼，连个导出按钮都没有。

他们还把原来固定频率的会议，全改成了“按需召集”。有问题就拉个15分钟的群语音，没问题就谁也别打扰谁写代码、跑实验、出去采样。毕竟很多做野外工作的同事根本不在办公室，你让他每天固定时间上线开站会，纯纯折腾人。

中科院软件所2024年做的国内科研软件项目调研显示，37%的科研类项目在去掉形式主义的轻量敏捷流程之后，需求匹配度从原来的42%提升到了89%。说白了，大家要的根本不是一套完美的流程，是能在做的过程中随时调整方向，别等走到头了才发现走岔了。

敏捷开发方法最容易踩的三个坑，踩中一个就白忙活

说真的，我现在特别烦那些把敏捷吹成万能解药的培训师。敏捷从来不是什么能解决所有问题的银弹，用不好的话，反而比僵化的瀑布流程还浪费时间。

第一个坑，就是把“响应变化”当成“随便改需求”。

之前碰到一个做农业遥感的项目组，今天负责的老师说要加个土壤湿度数据同步功能，明天说要把界面换成深色模式，后天又说要把导出格式从Excel改成PDF。团队天天追着零散的需求跑，根本没有时间沉淀核心功能，最后做了半年，系统里堆了一堆零散的小功能，连最基础的遥感影像加载都卡得要死。

MIT的跟踪研究里提过，健康的敏捷团队，每个迭代的需求变更比例应该控制在20%以内。超过这个数，就说明你一开始的优先级排序完全乱了，不是真的在响应变化，是被零散的需求牵着鼻子走。

第二个坑，就是把“团队自组织”当成“没人管”。

很多团队学敏捷，说要给团队充分授权，取消固定的进度检查，结果项目负责人天天看不到人，进度到了一半才发现，几个开发把精力都花在做炫酷的页面转场动画上了，核心的数据校验功能全是bug，等要交付的时候急得上火。

我之前带的一个研究生小团队，一开始搞纯自组织，两周后查进度，好家伙，有人花了一周时间给系统加了个猫爪印的鼠标指针，说能提升使用体验，但是最核心的实验数据加密功能一行代码都没写。当时我差点把手里的冰美式喷在屏幕上。

第三个坑，就是把快速交付当成可以跳过质量管控的借口。

很多团队说敏捷要快，所以测试环节能省就省，结果交付的版本满是bug，科研人员用的时候，好不容易跑了一周的实验数据因为系统崩溃丢了，那谁还敢用？2023年IEEE软件工程顶会收录的一篇论文里提到，那些在敏捷流程里嵌入了持续自动化测试的科研软件项目，后期的bug修复成本比不做测试的团队低76%。快不是瞎快，是在保证核心质量的前提下，尽可能早的拿到用户反馈。

不过话说回来，你要是做那种需求极其明确的项目，比如给学院官网做个静态展示页，或者做个参数完全固定的零件应力分析模块，根本没必要硬套敏捷流程。你哪怕用最笨的方法，按部就班做完，也比硬凑敏捷流程效率高。

上周跟那个拍桌子骂敏捷的生物科研负责人聊，他回去之后把之前的流程改了，取消了所有固定时间的无效会议，把每个迭代的交付目标从“完成一个大模块”改成“每两天出一个能跑的小功能”。上周他给我发消息，说终于把细胞实验数据的导出功能跑通了，负责实验的老师看到的时候连说三个好。

你看。

根本不需要什么复杂的流程。

能把事儿做对，比什么形式都强。