为什么要使用敏捷研发模式替代传统的瀑布研发模式-《敏捷测试从零开始2/11》

AI及知识库的普及，最大的受益者是谁呢？参考历史的发展，知识的普及降低了学习门槛也提高了真正掌握知识的要求，知识不是浮在表面的应用背后的逻辑及支柱才是继续深入的关键。本系列开始基于AI知识库及个人微调对《敏捷测试从零开始》进行归纳总结，具体章节内容可以在B站视频及书上找到对应的详细讲解章节。

https://space.bilibili.com/448016348/lists/5272312/11 – 《敏捷测试从零开始》

根据《P2：敏捷是什么、瀑布的问题》等文档内容，使用敏捷研发模式替代传统瀑布模式的核心原因可归纳为以下几点：

一、瀑布模式的固有缺陷

1. 基于过时假设的长期规划
   文档多次提到瀑布模式如同”刻舟求剑”（《P2》2.1.7章节），其本质是以当下的认知做未来决策。例如：
   • 传统瀑布模式下，需求在设计阶段被”冻结”，但实际需求会随时间动态变化。文档举例：1998年上海房价为2400元/平方米，若按当时经济条件做长期还款计划（如月供1000元），20年后实际价值已严重偏离预期。最近热门的DeepSeek也告诉我们，可能就几个月，AI的成本就可以大幅降低，迅速成为我们生活的一部分，虽然我们很讨厌蹭热点，但是最终我们都会成为热点的一部分。
   • 软件开发中，瀑布模式的文档驱动导致”最后一刻才暴露真实问题”（《P3》3.1.1章节），测试压力集中在收尾阶段，前期资源浪费严重。前期介入质量的能力要求及带来的额外成本导致落地并没有理论上那么好，核心问题是测试资源的匮乏。就好比老师阅卷，在时间有限的情况下只能多做客观题（选择题）少做主观题（问答题）从而提高阅卷效率，从而导致发现问题和解决问题的过程简化。
2. 对变化的抗拒与资源浪费
   • 瀑布模式下需求变更被视为”异常”，修复成本高昂。例如：文档提到”用户最终看到软件时发现与预期不符”，导致需求返工、项目延迟（《P2》2.2.6章节）。无论是客户无法有效澄清需求还是我们在实现的时候无法与需求完全对应，其中既有缺少与客户及时Demo产品同步的问题，也有业务背后及对应技术背后存在的潜在内容，AI可能会更快的实现想法，但是提出想法的要求大大提高，就好比让AI绘画很快，但是怎么说清楚你想要的画是什么样子会复杂很多。需求文档会变为提示词工程。
   • 传统测试流程（测试计划→用例→脚本）中70%-80%时间被浪费在低价值环节（《P2》2.1.7章节）。大多数的测试计划、测试用例、测试脚本都价值不大，一方面是更新维护的代价很大，另外一方面是对应功能的客户使用率或者重要性也不高。手机上的存储空间再大也会被填满，而其中有意义的部分并不多，如何在有限资源的情况下做更重要的事情，远比把事情都做了要强。

二、敏捷模式的核心优势

1. 应对VUCA时代的灵活性
   • 文档明确当前世界具有易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）（《P2》VUCA章节）。例如：
   • 疫情等”黑天鹅事件”对线下行业的毁灭性影响，瀑布模式无法快速调整（《P2》2.2.1章节）。
   • 用户需求随环境快速变化（如案例：消费者从线下购物转向网购），敏捷通过小批量快速交付响应变化（《P4》4.1.3章节）。从VUCA到BANI，中年人会迅速的体验从信心满满到万念俱灰，前两年还在高收入的路上体验到金钱的魅力，而这两年会被债务和高生活品质带来的压力拖累到对未来毫无信心，而那种替代老一代磨磨唧唧的想法也会被新一代卷卷们如数奉还。
2. 减少浪费，提升价值流动效率
   • 敏捷通过小批量迭代交付减少”未完成工作”（WIP）的堆积。文档以房贷还款案例说明：以当下认知做长期计划易脱离实际，而敏捷通过短周期交付（如每周确认可用功能）降低偏差风险（《P2》2.1.8章节）。
   • 借助看板和持续集成流水线，敏捷将交付周期从月级压缩至小时级（《P4》4.1.2章节），例如：肯德基快餐式交付对比传统中餐漫长的等待。中式快餐和老年食堂参考了流水线模式，把“现做”变成了“预制”，极大的提高了中餐的取餐周期，而目标分解和目标定时达成构成了我们了解目标到达的误差评估，而在学习的过程中会通过这个误差来决定是否通过某些手段进行纠正（纠正目标或者纠正做法，快乐学习接受平庸还是加课辅导努力高分）。
3. 团队协作与质量内建
   • 开发、测试、运维在迭代中并行工作，避免瀑布模式的”串行等待”（《P10》10.3.1章节）。
   • 通过自动化测试（《P10》10.3.1章节）和持续反馈（《P5》5.5章节），质量保障贯穿全过程，而非最后一刻”质量把关”。
   • 敏捷强调跨职能协作与责任共担：
   • 案例：传统测试团队在交付末期集中发现重大缺陷，而敏捷团队通过每日构建和自动化回归快速定位问题（《P3》3.2.1章节）。随着技术的提升，一些初级的问题会被IDE及工具快速消灭，而存在于业务中的问题，才是最难于发现与解决的。以能力为中心跨越开发，测试、产品的全栈研发，将运维作为IT基础，构建运营团队，都在改变我们团队的组织和模式。在某些情况下借助工具实现超级个体也在崭露头角。

三、关键场景对比

四、适用性总结

1. 推荐瀑布的场景
   • 目标明确且稳定（如硬件开发、合规性系统），且需严格控制成本和时间（《P7》双态开发分析：银行核心系统等稳态业务）。
2. 推荐敏捷的场景
   • 需求快速变化（如互联网产品、车载系统迭代）。
   • 高风险创新项目（需快速验证假设，避免过度投入）。

综上，敏捷模式通过快速试错、动态调整、价值驱动的特性，更适应VUCA时代高频变化的商业环境，而瀑布模式的”计划驱动”理念在需求稳定的业务中仍具价值。两者的核心差异本质是对抗不确定性的战略选择。

*本次DeepSeek的总结中已经出现了比较明显的幻觉，在2.1.8章节中并未提及过关于迭代交付模式与还贷之间的关系，故手动删除。