Agile 相对于 Waterfall 的虚假承诺
Source: Dev.to
请提供您希望翻译的完整文本内容（除代码块和 URL 之外），我将为您翻译成简体中文并保持原有的 Markdown 格式。
瀑布模型与敏捷的神话
二十年来，我们一直相信 Waterfall 是一种过时的遗物——僵硬、官僚、根本失效。与此同时，Agile 已经升格为一种宗教式的地位，配备了认证、顾问以及不容置疑的教条。
我在两种方法论下各工作了十五年，构建系统。 我目睹团队在冲刺中把自己推向架构灾难。 我也看到本来很优秀的工程师因为每四十八小时就要拥抱变化而燃尽。
为什么在某些项目上瀑布模型能胜过敏捷
具有深层架构依赖的复杂系统
瀑布模型备受诟病的顺序式方法往往能产生比敏捷碎片化、增量开发更好的软件。
敏捷的“诱人故事”
敏捷宣传小迭代、持续反馈和自适应计划的故事。实际呢？戏剧。
- Planning poker 示例 – 你估算一个简单的 API 接口为三点，大家都同意。没有人讨论该接口将如何与下个冲刺计划重构的认证系统交互。
- 短期关注 – 敏捷奖励在周五交付某些东西，而不是考虑六周后的情况。
三个月后，该接口阻碍了正确的缓存，迫使移动团队进行三次独立的 API 调用，而不是一次。
Source: …
开发者的真实工作方式
程序员并不像 Agile 所建议的那样编写程序。我们会：
- 思考问题
- 勾勒架构
- 了解依赖关系
- 然后动手实现
瀑布模型将这种自然的认知过程形式化。Agile 打破了它——并把这种打破称为“进步”。
- 上下文切换成本 – 切换任务大约会导致 20–25 分钟的注意力丢失。在为期两周的冲刺中，如果每天都有站会并且冲刺中期会更改优先级，你并没有在进行深度工作，而是在进行被中断驱动的开发。
- 阶段连贯性 – 瀑布模型为你提供了明确的阶段（分析、设计、实现、测试）。每个阶段让你一次只专注于一个问题空间，从而实现深度专注。
持续迭代会导致 架构近视：两周的计划视野只能优化两周内的问题。要在冲刺中完成能够节省六个月技术债务的重构根本容不下。
一个真实案例
公司： 构建金融报告平台。
敏捷教练的建议： “从小做起，构建一个可运行的骨架。”
| Sprint | 已交付 | 结果 |
|---|---|---|
| 1 | 基本登录 | – |
| 2 | 集成一个银行 API | – |
| 4 | 发现数据模型在区块链结算流程下无法处理，需要进行大幅重构 | 需要进行重大重写，这不适合在 Sprint 中完成 → 只能采用临时变通方案 |
结果：技术债务的累积速度快于偿还速度，因为该方法论优化了短期功能交付速度，而牺牲了长期的架构一致性。
Waterfall’s Counterpoint
- Analysis (3 weeks) – 定义需求，设计一个从第一天起即可处理传统和区块链结算的数据模型。
- Design → Implementation → Testing – 在坚实的基础上顺序构建。
是的，第一个功能会稍后发布，但它建立在一个无需在第 4 个月重新开挖的基础之上。
Architectural Erosion in Agile
Agile 假装架构并不重要。其结果是系统一致性缓慢下降——一次冲刺一次。
- Innocent shortcut – 开发者为了快速交付功能，从控制器直接调用数据库。
- Pattern copying – 下一次冲刺时，其他人看到这种模式并复制它。
- Six months later – 分层架构的漏洞比瑞士奶酪还多。
在执行良好的瀑布项目中，架构边界会在实现开始前 with intention 地创建。实现是对设计的落地，而不是一次又一次冲刺中即兴“发明”。
当瀑布模型（或其结构优势）有意义时
| 情境 | 为什么瀑布模型有帮助 |
|---|---|
| 需要深度集成的复杂系统 | 在协调多个遗留系统、监管框架和第三方 API 时，前期分析至关重要。 |
| 安全关键或合规要求高的领域（医疗设备、金融系统、航空软件） | 需要完整的文档和可追溯性。 |
| 需求固定且明确的项目（重建遗留系统） | 你不需要去发现 要做什么；只需一次性正确地进行架构设计，然后执行。 |
| 大型分布式团队（例如，跨六个时区的 50 位工程师） | 敏捷难以大规模扩展；基于阶段的协作更为合理。 |
你不能简单地宣布“我们现在采用瀑布模型”，但可以 重新整合其结构优势。
如何将瀑布式的优势融入你的流程
- 创建真实的设计阶段 – 在重大项目之前，暂停进行设计：需求分析、架构设计、设计评审。
- 保护不受干扰的实现时间 – 分配实现窗口，使开发人员免受会议打扰。
- 将探索与执行分离 – 一些冲刺应为探索性；其他则应纯粹执行已验证的设计。不要混合。
- 将技术债务显示为架构违规 – 跟踪实现偏离预期设计的具体实例。
- 在冲刺前编写规格 – 对涉及核心架构的功能，先编写规格。
- 在架构评审后才发布 – 在重大发布之前，审查架构健康状况。
结束语
瀑布模型的顺序结构并不是一个缺陷；对于需要深度架构一致性的复杂系统，它是一项特性。
- 在构建之前思考并不是浪费——它是基础。
- 在实现之前进行设计并不是僵化——它是负责任的。
敏捷为我们提供了有价值的工具：紧密的反馈循环、利益相关者协作、经验性适应。但它 过度宣传迭代而低估了架构。
通过借鉴两者的优势——敏捷的响应性和瀑布的纪律性规划，我们可以在不牺牲速度的前提下交付稳健、可维护的系统。
前进的方向既不是敏捷也不是瀑布。
关键是了解各自的优化目标，并构建融合两者优势的混合方法。
摆动的钟摆已经摆得太远， 更好的软件就在中间的某处。