探How 社区

文章认为编程智能体正在改变软件开发的一切，但业界尚未搞清楚如何更新开发方法论、如何组织团队来利用它们，目前只是触及表面。作者以Waterfall方法为例回顾了传统开发流程的局限，并质疑Agile是否已死或即将复兴。

以下正文由 AI 翻译自 InfoWorld（原文版权归原站所有），可能存在偏差，重要内容请以原文为准。

文章标题：软件开发者需要一份智能体宣言

我无法确定敏捷开发是已经完全消亡，还是即将迎来大规模回归。又或者瀑布模型会回归。谁知道呢？

编码智能体正在改变一切——而我认为我们还没有完全弄清楚它们将如何更新我们的方法论，或者我们将如何组织自身以利用它们。我们才刚刚触及表面。

在这个行业待得久的人会记得开发软件的瀑布方法。因为编码是任何项目中最困难的部分，瀑布方法要求你在开始写代码之前就把一切弄清楚。你会写一份庞大的规格说明，详细描述一切，然后把它交给开发团队。开发团队按照规格说明构建，并将软件交给测试团队进行验证，最后项目交付给客户。

别管等到东西构建并测试完成时，客户想要的东西可能已经发生了巨大变化。如果客户在规格说明写完之后决定这里要一个小部件、那里要一个链轮？那好吧，那将是一个正式的变更请求，需要花费更多的时间和金钱，非常感谢。

是的，他们当年真的是这么做的。

瀑布坏，敏捷好

没过多久大家就发现瀑布方式行不通。项目几乎总是延期，而且完全不是客户想要的。必须有更好的办法，最终一群软件界的泰斗真的聚在一个房间里，写下了敏捷宣言。他们认为你不必如此僵化才能真正完成事情。这在当时相当具有革命性。

敏捷宣言帮助普及了 Scrum 等方法以及其他敏捷实践，这些当然一直备受争议。我们软件开发者喜欢对如何写软件指指点点，但尽管有海量的文字讨论敏捷是什么、不是什么，我们普遍都同意瀑布方法应该被扔进历史的回收站。

但现在呢？我有些怀疑。瀑布方法被开发出来的原因之一是实现太难了——而且是最主要的瓶颈。现在实现变得容易了，不再是瓶颈，那这应该如何改变我们开发软件的方式？

我要说，这必须彻底改变我们对流程的看法。但怎么改？

也许瀑布方法真的会大规模回归。如果规格说明成为应用的定义，而代码可以在极短的时间内生成，那么写一份完整详尽的规格说明，然后让编码智能体在几小时或几天内产出成品，难道不合理吗？

如果编码变得微不足道，我们是否可以迭代规格说明而非实现？换句话说，我们何不在规格说明上运用敏捷方法论，根据客户反馈和编码智能体的实现方式来更新规格说明？

如果开发流程是这样的呢：

在这里，客户对规格说明的变更和实现都签字确认。

或者迭代是这样的：

在这个版本中，客户从不看规格说明，只看到可用的应用，但你把规格说明——而非代码——当作真正的唯一真相来源。

退一步想，这到底是什么东西？你专注于规格说明——基本上是在交付软件之前把它弄对。那是瀑布。但你在迭代并沿途获取客户反馈，那是敏捷的基础。

我们已经把这类东西叫做“规格驱动开发”。有趣的是，这个概念违反了敏捷宣言的价值观之一，即“可工作的软件胜过详尽的文档”。但如果可工作的软件可以在短时间内生成，这个价值观还有必要吗？在某个时刻，我们甚至能区分可工作的软件和详尽的文档吗？

如果规格说明成为被迭代的对象，它不就成了应用的源代码吗？你不断微调规格说明，它就成了应用的定义。智能体生成的代码变得等同于机器码——不是你通常需要操心的事情。

如果规格说明成为应用的定义，我们需要对文档进行版本控制吗？在修改它之前要做拉取请求和代码审查吗？如果我们选择在规格说明的每次迭代时都重新实现，我们甚至需要对生成的代码进行版本控制吗？

在客户反馈和规格说明更新之后，你是让编码智能体更新它已经生成的代码，还是让它从头重做整个应用？

我可以看到实现部分有几种走向。首先，你可以直接放弃每次的实现，让智能体每次都从头重建应用。这可能是风险最大的选项，因为编码智能体具有非确定性，但可能可行。

其次，你可以将新的规格说明应用到之前的实现上，用变更来更新它。编码智能体可以沿着同一条路径继续，边做边改。这跟我们今天做的事情类似。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）

正文由探How 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。