我盯着屏幕上Claude帮我写完的第三个微服务，突然想起十年前第一次参加Scrum培训时的兴奋。那时候，敏捷像一道光，照进了瀑布模式的黑暗森林。我们贴便利贴，开站会，两周一个Sprint，感觉自己站在了软件工程的最前沿。

现在想想，有点像当年用诺基亚N95时觉得自己很潮的感觉。

最近的一次迭代评审会上，产品经理展示了这个Sprint的成果——三个新功能。我默默算了一下，如果用AI辅助，这些功能我一个下午就能搞定。突然间，那块写满User Story的看板显得有些滑稽，像是蒸汽时代的人在讨论如何优化马车的轮子。

你可能不信，但我真的开始怀疑：当"写代码"这件事的时间成本趋近于零时，我们还需要Sprint吗？

从两周到两小时

上个月，我们团队接到一个紧急需求：给系统加个数据导出功能。按照敏捷流程，产品写Story，开发估点，测试写用例，一套流程下来，排到下个Sprint。客户等不及，我晚上回家用Cursor写了个原型，第二天早上就上线了。

整个过程中，我意识到一个可怕的事实：敏捷方法论的核心假设——“开发是瓶颈”——正在崩塌。

记得以前估算Story Point时，我们会掰着手指头算：这个接口要两天，那个页面要三天。现在呢？我问AI："帮我实现一个支持Excel和CSV导出的REST API，要有进度条。"三分钟后，代码就躺在那里，连单元测试都写好了。

这让我想起一个段子：程序员最讨厌两件事，一是写文档，二是别人不写文档。现在AI把这两件事都包了，我们是不是该讨厌点别的了？

需求如流水，代码如呼吸

前天，老板突然说想在首页加个AI客服。要是以前，这种需求足够我们开个需求评审会，画个技术架构图，再争论两天用WebSocket还是长轮询。

现在？我直接让Claude生成了一个集成方案，包括前端组件、后端接口、数据库设计。老板看了效果，说："按钮能不能改成蓝色？"我说："稍等。"三十秒后，“改好了。”

“那个欢迎语能不能更活泼一点？”
“改好了。”
“支持语音输入吗？”
“现在支持了。”

这种"流式开发"的感觉很奇妙，像是需求和实现之间的时差被抹平了。产品经理还没想好下一句话，功能已经上线了。Sprint Planning？那是什么，能吃吗？

当敏捷遇上光速

我开始思考一个问题：敏捷方法论诞生于一个"改代码很贵"的时代。每一行代码都是程序员的心血，每一次修改都可能引入新的bug。所以我们需要计划，需要评审，需要回顾。

但如果改代码变得像改PPT一样简单呢？

上周，我们的测试同学还在纠结一个边界条件的测试用例怎么写。我说："让AI跑个property-based testing，它会自动生成一万个边界条件。"她愣了一下，说：“那我的KPI怎么办？”

这可能是个玩笑，但也可能不是。

当AI可以在几秒内生成代码、编写测试、部署上线，我们还需要那些为了"管理复杂度"而设计的流程吗？Daily Standup是为了同步进度，但如果进度以分钟计算，站会还没开完，功能已经上线三轮了。

新世界的轮廓

昨天和一个创业的朋友聊天，他说他们公司没有Sprint，没有迭代，只有一个原则：有想法就试。早上想到的功能，下午就能看到用户反馈。他们管这个叫"呼吸式开发"——像呼吸一样自然、持续、不需要思考。

我问：“那怎么保证质量？”
他笑了：“AI写的代码bug比人少。真出问题了，回滚比修复还快。”

这让我想起写第一行Hello World时的感觉——原来编程可以这么简单。只是这次，简单的不是语法，而是整个软件生产的过程。

晚上回家的路上，我路过那家常去的咖啡店。老板娘说她想做个小程序，问我要多少钱。要是以前，我会心算一下人月，报个五位数。现在，我说：“你请我喝杯咖啡，我教你自己做。”

她以为我在开玩笑。

其实我也不确定，这到底是玩笑，还是预言。

当潮水退去，我们才知道谁在裸泳。当AI的浪潮涌来，我们才发现，原来我们一直在用工业时代的方法论，管理信息时代的生产力。而现在，一个新的时代正在到来，它不需要Sprint，不需要看板，甚至可能不需要团队。

它需要的，也许只是一个有想法的人，和一个懂他的AI。

至于敏捷是否真的已死，我不知道。但我知道，当我们还在讨论是否要把Sprint从两周改成一周时，有人已经在按小时发布了。当我们还在优化站会流程时，有人已经取消了所有会议。

这个行业最有趣的地方就在这里——你永远不知道，明天醒来，哪些"最佳实践"会变成"历史包袱"。就像你永远不知道，下一个让你的代码过时的，是框架升级，还是整个范式的改变。

夜深了，我看着窗外的灯火，想起一句老话：唯一不变的，就是变化本身。只是这次的变化，快得让人来不及告别。