在Capgemini执行副总裁Steve Jones发表于Medium博客以及配套发布的LinkedIn帖子中,他声称人工智能已经使敏捷宣言失去了意义,这一观点引发了激烈的讨论。Jones指出,那些由人工智能工具来完成大部分开发工作的智能软件开发生命周期系统,从根本上违背了敏捷宣言的四大核心价值观和十二项原则。

Jones指出了将敏捷方法应用于智能软件开发生命周期过程中所面临的一些关键挑战。首先,他认为工具的选择至关重要:

如果你使用的是Replit,那么它的效果会与使用Claude Code时不同;而如果你同时采用多种智能软件开发生命周期模型,那么就必须认真考虑这些工具对开发过程的影响。

这一点显然与敏捷宣言所倡导的“重视个人与人际互动,而非流程和工具”这一理念相矛盾。

速度差异也是另一个核心问题。Jones提到,利用人工智能技术,人们可以在短短几小时内完成应用程序的开发工作,甚至能够一次性迁移整个应用程序系统,他说:

正是这种快速开发模式使得智能软件开发生命周期模型与敏捷原则产生了根本性的冲突,因为这样的开发速度远远超出了敏捷方法所能承受的范围。

当人工智能能够在几分钟内生成可运行的代码时,传统的两周迭代周期就已经显得过时了。

或许最值得关注的是,Jones对“优先开发可运行的软件而非编写详尽的文档”这一原则提出了质疑。他认为,虽然人工智能在创建看似功能完备的软件方面表现出色,但这种开发方式也会导致技术债务以前所未有的速度累积。因此,他强调,在当前环境下,文档编制和架构规划比以往任何时候都更为重要。

人们对这一观点的反应褒贬不一。Sandvik公司的运营优化与敏捷培训负责人Rolf Läderach在LinkedIn上的讨论中反驳道:

敏捷并不等同于敏捷宣言,更与各种开发框架无关。敏捷的核心在于打造能够适应变化并取得实际成果的组织结构,而这一需求永远都不会消失。人工智能恰恰可以为实现这一目标提供有力支持。

Nave公司的首席执行官Sonya Siderova则提出了更为中立的看法:

敏捷并没有死亡,它只是在不断调整那些已经发生变化的限制因素而已。

她认为,虽然传统的站立会议有助于协调人类的开发工作,回顾会议也能帮助人们总结经验教训,但当人工智能能够在几分钟内完成代码编写时,开发过程中的瓶颈就从“人类如何协作进行开发”转变为“人类该如何确定需要开发什么内容,并验证这些内容的可行性”。

Kent Beck作为《敏捷宣言》的签署者之一,一直在探索他所称的“增强型编码”与“氛围编码”的区别。在一篇详细的Substack文章中,Beck将增强型编码描述为在坚持传统软件工程价值观——如代码整洁性、全面测试和精心设计的同时,利用人工智能来完成大部分编码工作。他明确指出,这种编程方式与“氛围编码”不同:在后者中,开发者只是将错误信息反馈给人工智能,期望其自动进行修复,而完全不关心代码的质量。

Beck提出的方法为人们指明了一条中间道路:在保持工程严谨性的同时,利用人工智能作为强大的辅助工具。他报告称,自己使用这种方法用Rust和Python编写了一个可投入实际使用的B+树库,在这个过程中,人工智能在人类严格监督下,并遵循测试驱动开发的原则来生成代码。

整个行业对这一理念的反应远不止个别的评论。Casey West提出了《智能体宣言》,该宣言将原有的敏捷价值观应用于自主型人工智能系统,使关注点从“是否按我的要求完成了任务”转变为“是否实现了我的预期目标”。许多组织也在尝试将传统的软件开发生命周期流程与针对非确定性人工智能行为的新治理模式相结合,形成了所谓的“智能体交付生命周期”。

AWS在其2026年的指导性文件中也表达了这一观点,建议将“冲刺计划”调整为“意图设计”。在这种模式下,架构被视作一种“框架”,用于定义各种角色、约束机制和备用方案,而不是为每一个决策路径都编写详细的脚本。

然而,Forrester在2025年发布的《敏捷开发现状报告》中提出了不同的观点:95%的受访者认为敏捷方法对其工作具有至关重要的意义,其中61%的人表示已经采用敏捷实践超过五年。Forrester的副总裁兼首席分析师Diego Lo Giudice在一篇博客文章中指出,虽然各机构的敏捷应用水平参差不齐,但只有7%的企业达到了完全成熟的运用程度。将敏捷方法与生成式人工智能相结合,为进一步提升敏捷开发的效果提供了新的途径——目前已有近一半的受访者在其敏捷实践中应用了生成式人工智能技术。

Jones本人也承认,并非所有“敏捷”实践都毫无价值,但他强调,那些为人类团队长达数周的开发周期设计的方法,并不适合由智能体来执行。他呼吁制定一份新的宣言和相应的方法体系,这些新体系应该基于这样的假设:智能体会承担开发者之前所负责的大部分工作。

这一争论引发了一些根本性的问题:敏捷究竟是一种与特定实践(如冲刺会议和站立会议)紧密相关的具体方法论,还是一种关于适应性与学习的更广泛的哲学理念?当人工智能能够在几分钟内生成代码时,软件开发过程中真正的瓶颈到底在哪里?我们是需要全新的框架,还是现有的敏捷原则足以指导人类与人工智能之间的协作呢?

正如分析师、顾问兼安全架构师Eric Newcomer在讨论中指出的那样:

我不确定……我们确实需要一份新的宣言,但我认为,在人工智能技术出现之前,官僚主义就已经扼杀了“敏捷开发”这一理念的发展。

显而易见的是,软件开发正进入一个方法论发生重大变革的时期。这种变化究竟意味着“敏捷开发”的终结,还是它将演变成某种新的发展模式,对于整个行业来说,仍然是一个尚未得到解答且日益紧迫的问题。

Comments are closed.