敏捷开发方法到底适不适合科研团队？我们踩过的坑比你看过的论文还多

敏捷？别逗了，科研也能敏捷？

说实话，第一次听到“科研团队用敏捷开发方法”这句话的时候，我嘴里的一口咖啡差点喷在显示器上。搞科研的，谁不知道一个实验要重复多少次、一个模型要调试多久？你告诉我每两周交付一个可工作的软件？开什么玩笑。 但后来我发现，我错了。错得离谱。 科研团队看板墙实拍 事情得从三年前说起。我们实验室接了一个国家级项目，目标是开发一套模拟蛋白质折叠的软件。需求嘛，一开始说得天花乱坠：要支持多种力场，要能可视化分子轨迹，还要有机器学习加速模块。团队里三个博士、两个硕士，外加我一个写代码的。老板一拍脑袋：“先按传统瀑布模型来，需求写清楚，设计完再开发。” 结果呢？需求文档写了200页，设计文档画了无数UML，等到真正写代码的时候，发现一个致命问题：生物学家们根本说不清他们到底要什么！他们今天觉得可视化用三维旋转就行，明天又觉得必须支持VR。我们就在那反复改，最后第一版出来已经过去18个月——而且大部分功能根本没人用。 这就是为什么我后来成了敏捷的狂热信徒。尽管一开始我满肚子怀疑。

那个差点被瀑布模型搞死的项目

我至今记得那个星期六的深夜。实验室只剩我一个人，盯着屏幕上的错误日志，心里想：这他妈的到底哪里出了问题？我们明明按照设计文档一行一行写的，为什么数据一跑就崩？根源其实特简单：设计文档假设输入文件格式是PDB，但合作单位给的全是 mmCIF。瀑布模型把这种东西前置固定死了，根本没有回旋余地。 然后我们开始尝试 Scrum——对，就是那种每天站会、迭代评审的玩意儿。起初所有人都觉得滑稽。一个生物学博士站那儿说：“昨天我在养细胞，今天打算提取蛋白，没有障碍。” 这算什么开发？但神奇的事情发生了：当产品待办列表里出现“蛋白质可视化组件”时，用户（也就是我们组里做实验的那帮人）突然能给出即时反馈了。他们说：“这个旋转角度限制太死，我们想看侧链内部。” 我们三小时后就改好，第二天评审，他们又说：“嗯，现在好多了，但能不能加个氢键显示？” 两周一个冲刺，居然在第四周就搞出了一个能用的原型。虽然丑，虽然 bug 一堆，但用户眼睛亮了。那种感觉——怎么说呢，就像你终于憋出论文的初稿，虽然导师肯定要骂，但至少有个东西可以骂了。 敏捷开发迭代计划白板示意图 不过话说回来，敏捷也不是万能药。我们踩的坑比喜马拉雅山还高。比如有一次冲刺评审，用户提了三十几条修改意见，下一个冲刺我们拼命全做完了，结果人家说：“我随便说说的，你们还真改啊？” 浪费了整整两周。后来才学会：评审时抓住最痛的三个点，其他扔进 backlog，爱谁谁。 还有就是文档问题。科研项目最后要验收的，没有详细设计文档，专家能让你过？我们妥协的办法是：每个冲刺结束，写两页轻量级的技术报告，把决策理由和 API 变化记下来。不是那种八股文设计文档，而是像日志一样：为什么这个函数要改参数？因为分子模拟库升级了，不兼容旧接口。就这么简单。够用。

我们为什么又恨又爱Scrum

Scrum 的那个“每日站会”——艹，有时候真想把它炸了。特别是项目紧的时候，谁有心情每天早上汇报啊？有段时间我故意迟到，就为了躲开会。结果团队其他人也开始迟到，站会从九点半拖到十点，最后不了了之。 后来我们改良了。站会允许坐着，而且只说三句话：昨天做了什么推进项目的事？今天打算做什么？有什么事情卡住了需要别人帮忙？如果没事，直接说“没事，pass”。平均两分钟结束。爽。 还有一个痛点是任务估算。科研任务的不确定性太高了，你让我估“优化分子对接算法”需要几个小时？可能一小时搞定，可能一个月找不到门道。我们后来用故事点，而且引入了一个“研究 spike”的概念：如果某个任务完全未知，先给一个时间盒子（比如两天）去探索，到点必须写个小结，再决定下一步。这招是从极限编程那里偷的，好用。 不得不提看板。我们实验室墙上有一块巨大的白板，贴满了便利贴：待办、进行中、评审、完成。有次校外专家来参观，看了半天，说：“你们这个挺好，能不能给我拍张照？” 我心里想：这玩意儿又不是原创，网上到处都有。但它就是能减少沟通成本。谁在做什么，一目了然。博士们再也不用到处抓着我问：“那个算法你改好了没？” 自己看板上去。 蛋白质折叠软件迭代界面截图 当然，我最烦的是那些敏捷教练的教条主义。有回一个外聘顾问来给我们培训，张口闭口“Scrum 指南说”、“必须这样做”。他坚持要求我们写用户故事必须用“作为…我希望…以便…”的格式。我一个写分子模拟的，怎么写？“作为赖氨酸残基，我希望被正确地质子化，以便能量最小化不报错”？开什么玩笑。后来我们把这套格式扔了，爱怎么写怎么写，只要团队懂就行。

科研敏捷的真相：不是快，而是少做无用功

科研敏捷的真相：不是快，而是少做无用功 很多人误会敏捷开发方法就是快。错。大错特错。科研里面，快往往意味着乱。敏捷的真正价值是：让你别在错误的方向上狂奔。 举个例子。我们那个蛋白质折叠软件，最开始规划了一个“量子化学精度模块”，准备做从头算。光调研就花了一个月。后来在第一次迭代评审时，用户说：“我们要的不是绝对精确，是能快速筛化合物库。” 好吧，量子化学模块砍掉，换成半经验方法。如果没有那次两周的评审反馈，我们可能埋头六个月，最后做出一堆没人用的东西。 这就是“快速失败”的价值。科研本来就是在失败中前进，但传统方法把失败推迟到最后一刻，成本高得吓人。敏捷把失败拆散，变成一个个小教训。疼还是疼，但不致命。 不过，我必须吐槽一点：学术界对敏捷的接受度还是太低。顶级期刊论文里，你见过哪个作者写“我们采用了 Scrum 管理方法”？没有。大家还是认为科研管理就是甘特图和里程碑。但事实是，越来越多的工业界实验室（比如 DeepMind、罗氏）在用敏捷。他们发 Nature 的时候，背后难道没有看板？我猜一定有。 最后说个真事。去年我们投了一篇论文，审稿人要求补充一组实验数据。传统做法是：等人齐了，设计实验，做，分析，来回折腾两个月。我们用了一个冲刺：两个人专门负责这个实验，三天出方案，一周做实验，中间每天碰一次进度，两周后数据就出来了。论文顺利接收。老板说：“你们这次怎么这么快？” 我笑笑没说话，指指墙上的看板。 所以，如果你还在犹豫科研团队要不要搞敏捷——别想那么多。先拿个小白板，划几列，把一周的任务贴上去。然后每天花五分钟同步一下。你会看到变化的。至少，你会知道我当初为什么喷咖啡。