AI 杀死了敏捷宣言

敏捷宣言 试图为存在的各种不同敏捷方法和途径创建整体哲学，它提出了一个非常不错的四条重点定义:

个体和互动 高于流程和工具
可工作的软件 高于详尽的文档
客户协作 高于合同谈判
响应变化 高于遵循计划

也就是说，虽然右项也有价值，但我们更重视左项的价值。

然而，AI 挑战了这些要素中的每一个，我认为实际上，在企业内或大规模软件开发工作中大规模使用代理性 SDLC 时，敏捷宣言是一个导致大规模搞砸的好方法，这归结为一个非常简单的点:

AI 在构建看起来能够工作的软件方面是惊人的，或者至少是为了它被给予的非常具体的指令而工作

这意味着它可以以普通开发者绝对无法的速度创建技术债务。我们还需要考虑一些更多的挑战，但首先让我们看看为什么四个陈述的重点不适用于代理性 SDLC。

1、流程和工具很重要— 它们是你对 AI 的控制

所以第一个巨大的部分是，在代理性 SDLC 中，工具绝对重要，这实际上是一个绝对的基础方面，如果你使用 Replit，那么它的运作方式与使用 Claude Code 不同，如果你打算使用代理性 SDLC 的混合，那么你绝对需要考虑这一点，这意味着你也需要对流程有清晰的了解。你需要能够向所使用的代理性 SDLC 工具描述你的流程，以确保它们一致并正常工作。基本上，在代理性 SDLC 中，工具和流程是绝对根本的。

2、可工作的软件很好，但你需要理解它

在与代理性 SDLC 合作时，文档真的很重要，因为文档是与代理"协商"你想要构建的内容的更好方式，而且它还提供了一个"独立"点来审查代码。我会使用的比喻是，在今天的 99.999% 的项目中，你实际上并不审查"可工作的软件"，最终一切都会变成机器代码，你审查开发者创建的"源代码"。使用代理性 SDLC，那个"源"应该更多是文档而不是"技术"代码，我有项目将代码从 Python 切换到 Go，出于性能原因，拥有该设计并对照文档审查执行是关键，但通常，文档确实有助于让代理 SDLC 承担责任。

3、协作很好，但 AI 需要边界

客户协作很好，但使用 AI，你需要对边界非常清楚，例如，我正在更新我的动物识别软件，即使我已经为我的 YOLO 第一遍解决方案创建了 MCP 版本，Claude 和 Gemini 都想编写自己的版本（通常使用较旧的 YOLO 实现）。

当"氛围编码"并且你打算代码在未来实际上是功能性和可维护的时，这变得更加重要，如果你"只是协作"和"只是氛围"，那么你将"只是创建大量的技术债务"。

4、在上下文中适应变化是好的

显然瀑布是胡说八道，但使用代理性 SDLC 进入重构周期通常会导致"腐败上下文"，因此上下文（那个文件 CLAUDE.md 或类似）包含了"重构之前"的信息。如果你正在构建大型解决方案，那么对项目中不同上下文区域的清晰是至关重要的，如果你不希望代理性 SDLC 开始产生幻觉，那么理解你希望单个代理上下文在其中工作的边界是你应该早期考虑一些事情，否则实际进行你想要的更改会变得非常困难。

这是最适用的规则，但它对其他要素有戏剧性的影响，简单地说，能够在规模上使用代理性 SDLC 驱动变化需要你在前端做更多工作，以便能够在上下文内处理该变化。

5、YAGNI 和代理，你可能真的需要它

在我们前进之前我们应该杀掉的最后一件事，"YAGNI"的概念——你不需要它——它说不应该编码直到你需要它。使用代理性 SDLC，规划一些（不是全部）这些未来元素是一个非常好的主意，以确保当你确实需要它时，你不是处于一个巨大的兔子洞中。

6、原则已经改变

因此，除了宣言之外还有 12 条原则，值得识别其中哪些也改变了。

我们的最高首要任务是满足客户 通过早期和持续交付 有价值的软件。

这似乎可以保留

欢迎变化的要求，即使在后期 发展中。敏捷过程利用变化来 客户的竞争优势。

当然为什么不呢。

从几周到几个月，以较短的时间尺度为优先，频繁交付可工作的软件。

哦，你这个甜美的夏天孩子，几周？我在几个小时内创建可工作的应用程序，我在一次飞行中迁移整个应用程序。这是代理性 SDLC 与敏捷原则产生根本性破坏的地方，因为代理性 SDLC 对敏捷来说太快了。

业务人员和开发人员必须在整个项目中每天一起工作。

你什么时候不需要开发人员？哪里不需要他们？哪里代理性 SDLC 足够直接与业务合作？我们如何拆分这些不同的部分。

围绕有动力的个人构建项目。 给他们所需的环境和支持， 并信任他们完成工作。

这是空洞的，它是一个很好的原则，但"信任"在代理性 SDLC 中不是被动的。

向和向内传达信息的最有效和有效的方法 开发团队是面对面对话。

当你与代理性 SDLC 通信时并非如此，当然对人们来说这可能很好，但现在你必须考虑如何向代理性 SDLC 传达你想要什么。

可工作的软件是进步的主要衡量标准。

这可能是绝对改变的一个，因为"可工作的"软件太容易了，就像你可以快速获得看起来能够工作的东西，但这样做的方式要么有根本性的缺陷，要么无法扩展到目的地。

敏捷过程促进可持续发展。 赞助商、开发人员和用户应该能够 无限期地保持持续的步伐。

这不太像一个原则，更像是一个愿望清单项目，所以当然它可以保留，但它实际上意味着什么？

持续关注技术卓越 和良好的设计增强了敏捷性。

完全同意这一点，但它有点违反 YAGNI 和有点违反流程和工具，所以在代理性 SDLC 中这绝对是至关重要的。

简单性——不做工作的最大化艺术——是必不可少的。

在代理性 SDLC 中也完全至关重要，非常清楚什么不应该做与应该做的事情一样重要。

最佳架构、需求和设计 出现自自组织团队。

我会质疑这是否作为陈述是真的，而且当团队的大部分是代理性 SDLC 时，什么是"自组织团队"？

定期，团队反思如何 变得更加有效，然后调整和调整 其相应行为。

我再次同意这一点，但同样它是关于工具和流程作为"团队"的核心部分，反思将如何改进代理性 SDLC。

7、新代理性 SDLC 宣言的考虑因素

那么代理性 SDLC 的宣言应该是什么？我认为我们应该从我们的几个约束开始

• 你选择的工具很重要，你选择的每个工具工作方式都不同
• 模型在库的"遗留"版本上训练，所以通常会创建过时的代码，特别是在基于库正在快速更新的领域
• 模型有上下文限制，200k 到 1M，这不是没有，但这确实意味着对于较大的项目它不是所有内容
• 上下文可以被"腐败"，这通常发生在重构时，上下文"记住"遗留方法，或者回到使用库的旧版本。更糟糕的是，当上下文满了时，它可能会导致一些超级奇怪的行为
• "全能"上下文往往比特定目的上下文效果更差，例如，单独的"测试"和"开发"上下文比单个"DevOps"上下文效果更好。
• 代理性 SDLC 中子代理的兴起意味着思考给定上下文或挑战的代理"团队"
• 模型可能会产生幻觉，所以验证是至关重要的

我确信还有更多，并且欢迎提出建议，但在使用代理性 SDLC 6 个月并在团队中使用代理性 SDLC 后，我发现旧的用于人类开发的敏捷方法不能很好地扩展到我们的代理软件未来。

原文链接：AI killed the Agile Manifesto

汇智网翻译整理，转载请标明出处