AI时代，还需要敏捷开发么？

01. 为什么会有敏捷开发？

软件项目失败的最常见原因，不是技术做不出来，而是做出来的东西没人要。

上世纪八九十年代，软件开发的主流方法是"瀑布模型"。

这套方法从建筑工程里借鉴而来：先做需求分析，再做系统设计，然后编码，测试，最后部署上线。每一步做完，交给下一步，像瀑布一样逐级流下，不可逆。

这套方法听起来很合理，谁盖楼不是先画图纸再施工呢？但软件开发有一个根本性的不同：需求是不确定的。

于是2001 年冬天，十七位软件开发者在犹他州雪鸟滑雪场的一间小屋里，写下了一份只有 68 个字的宣言。

那便是后来影响了整个软件行业二十多年的《敏捷宣言》。

（https://agilemanifesto.org/iso/zhchs/manifesto.html）

它的核心理念很简单：别等做完再给用户看，做一点就给一点，增加沟通和反馈，快速调整。

具体来说，就是把一个大项目拆成很多小的迭代周期（1~4周），每个周期结束都产出一个可用的版本，让用户或利益相关方看到、用到，然后根据反馈调整方向。

举个例子：敏捷开发就像是雕塑，你先大致捏出一个形状，然后不断修整、打磨，直到它变成用户想要的样子。

02. 大厂的敏捷开发是什么样的？

说了敏捷的来由，再看看它在实际中是怎么运作的，下面是我之前在阿里的敏捷开发的流程图。

（敏捷开发时候的迭代图）

核心就是：三个角色 + 四个仪式：

三个角色：产品负责人决定做什么，开发团队负责怎么做，有一个协调人员负责保证流程顺畅（协调人员通常是技术负责人）。

四个仪式：迭代排期会（规划这个周期做什么）、每日站会（每天同步进展）、迭代发布会（展示成果）、迭代回顾会（反思改进）。

听起来好像很清晰，但是执行起来，经常鸡飞狗跳。从需求到代码之间，隔着一层又一层的翻译和转换（需求->产品->设计->前端->后端->测试），每一层都需要对齐认知，各种吵架投诉都是家常便饭。

核心问题主要是两个：

一、沟通成本高

(需求预期和上线结果不一致)

需求和研发侧的衔接，将需求文档翻译成可实现的功能点，存在信息的损失。
研发中（前端->后端->测试），每个环节都需要对接，从接口字段到联调时间，过程中也存在信息的损失。

二、试错成本高

需求存在变动，有些需求上线了才知道不合适，需要改，这通常一个月就过去了。

03. AI时代，有哪些问题可以被优化？

AI能读大量的文档，理解能力强，行业理解深。
AI能精通全栈（前端，服务端，测试）技术能力已经超过 80%以上的程序员，一个人能开发全流程。

基于这些能力，我们再看下之前敏捷开发的痛点：

一、沟通成本降低

AI直接写完全栈代码减少协调沟通。以前程序员的能力有限，通常只够精通一个技术栈。而AI的技术栈更全面，AI 可以快速将产品需求转化成各端代码（前端 + 服务端 + 测试用例），一个人完成全栈开发，所以很大一块的研发间的沟通成本省掉了。
复杂的沟通可以用文档标准化。因为AI能读产品文档（Spec），所以只要文档写清楚，最终上线的结果就能满足文档里的需求，所以把产品文档打磨好，让AI能理解一致。

二、试错成本降低

开发时间短，有更多的试错空间。以前开发基本上要保障1~1.5周进行开发，有些还需要更久。而现在可能一天就开发完了。

04. AI时代，还需要敏捷开发么？

回头再看看敏捷开发要解决的问题：别等做完再给用户看，做一点就给一点，频繁反馈，快速调整。

其实AI时代已经能解决敏捷迭代的核心问题了，迭代成本降低，可以快速满足传统用户的需求，所以敏捷开发其实不需要了。

但是，新阶段，有新问题：

找到用户想要的：用户往往不知道自己想要什么，那就快速实现，全端给用户。通过数据分析反馈，快速找到用户想要什么。
人被弱化：通过产品文档驱动的开发，人与人之间沟通变少，AI读懂文档，人负责执行和担责。渐渐的人会越来越不理解产品。

而产品终究是服务于人的，AI对于人的理解终究是不如真人，所以我觉得AI实现的产品是有上限的。

举个不恰当的例子：AI能做出「钉钉」但做不出「微信」。
技术债增加：快速迭代下，系统会堆积大量的冗余代码，技术债会越积越多，系统风险会越来越大。
没有全局视角：AI上下文有限，会忘记，经常会提供局部最优解，但是并非全局最优解，AI存在幻觉，存在不可控性，在有些场景下可能是致命的。

05. 核心的不再是流程

回想以前，其实很多团队的敏捷本来就是假的，照着敏捷开发的仪式走，但骨子里还是“瀑布”思维。

但是即便如此，这套流程也还是高效的管理和驱动着每一次迭代，让大家高效协作。

同样，即便是AI如此强大的时刻，敏捷开发也不是一无是处，前期从0到1，依然可以沿用敏捷开发流程，只是后续可以更灵活，不用再严格遵循敏捷开发流程，每天都可以有需求的发布。

对于大厂，船大难掉头。也许短期能做的就是精简人员，降低沟通成本，缩短工期或者加大需求量，降本增效。未来再和AI一步步的共同进化。

大厂相对成熟的产品还是要以稳定为主，不仅是系统，还有人。

小厂就灵活很多，一个架构师就能成为一个团队。

06. 个人的思考

敏捷开发是手段而不是目的，产品才是目的。

以前工作都在分前端，后端，产品，测试，未来可预期的时间内，职业要求会变，所有角色都要前进一步，在产品端给出更多的想法和思考。

我记得前不久Anthropic对未来职业有一个想象，分为5种：

原型师：一天试十个想法，允许九个失败，用最低成本排除错误方向。

构建者：把能跑的 Demo 变成用户敢用、公司敢卖的产品，完成从 0.1 到 1。

清理师：删功能、并流程、还技术债。AI 让生产更容易，也会让垃圾膨胀得更快。

增长师：盯着用户行为和商业结果做实验，把“我觉得”变成可验证的假设。

维护者：守住安全、稳定、成本和韧性。产品越成功，越不能只靠“先上线再说”。

这些职责并不是一成不变的，根据产品形态进行适当的配比，所以我建议现阶段不要自我设限，多了解产品，了解用户，给自己更多的全局视角。

回归产品，而不是流程，未来没有标准的迭代流程和岗位，能适应不同产品不同阶段，通过AI随时学习调整，才是最适合的。

作者提示: 个人观点，仅供参考