第一章：嵌入式开发的痛点——为什么传统瀑布模型在嵌入式项目中频频失败？

大家好，我是老李。做嵌入式这行快十五年了，踩过的坑比吃过的盐还多。今天咱们聊聊一个老生常谈却又不得不谈的话题——为什么瀑布模型在嵌入式项目里总是水土不服？

说实话，我刚入行那会儿，公司用的就是标准的瀑布模型。需求文档、概要设计、详细设计、编码、测试，一步接一步，看着挺美。结果呢？项目延期是常态，加班到凌晨三点也是家常便饭。为什么会这样？

1.1 硬件依赖——你永远在等一块板子

瀑布模型假设所有需求都能在项目初期明确。但嵌入式项目不一样，你想想看，很多时候硬件还没做出来呢！

核心问题：软硬件开发无法并行

我记得有个项目，硬件团队说两周后给板子。结果呢？六周后才拿到第一版。软件团队干瞪眼，只能写写伪代码，跑跑模拟器。等板子到了，发现硬件有个bug，软件架构得重来。

说白了，瀑布模型假设「所有事情都能提前规划好」。但在嵌入式领域，硬件的不确定性太大了。你没法在芯片还没流片的时候就写好完美的驱动代码，对吧？

1.2 调试困难——出了问题你都不知道在哪

做上层应用开发的朋友，可能很难理解我们的痛苦。他们出bug了，打个断点，看看变量值，改改代码，完事。我们呢？

嵌入式调试的三大噩梦：

1. 硬件问题还是软件问题？ 系统跑飞了，是代码写错了，还是电源纹波太大？我曾经花了一周时间查一个随机死机的问题，最后发现是某颗电容虚焊了。
2. 无法打断点 很多嵌入式环境没有标准调试器。你只能靠串口打印，或者点个LED灯来定位问题。效率低得让人抓狂。
3. 时序问题最难搞 有些bug只在特定时序下出现。你用调试器一停，时序变了，bug就消失了。这种「幽灵bug」最让人头疼。

瀑布模型要求每个阶段「完美交付」后再进入下一阶段。但嵌入式调试的复杂性，决定了你不可能在编码阶段就把所有bug都找出来。有些问题，只有系统集成后才能暴露。

1.3 需求变更频繁——客户永远有新想法

「这个功能很简单，加一下就行。」——这句话我听了不下百遍。

瀑布模型最怕的就是需求变更。因为它把「需求分析」放在最前面，假设后面不会再改。但在嵌入式项目里，需求变更是常态，不是例外。

变更类型	常见原因	对项目的影响
功能需求变更	客户看到竞品有新功能	可能需要改硬件选型
性能需求变更	实测发现响应速度不够	可能需要优化算法或换主控
接口需求变更	对接的第三方改了协议	通信模块要重写
成本需求变更	老板说成本要降20%	换便宜芯片，软件全得适配

你看，每个变更都可能引发连锁反应。瀑布模型那种「一步到位」的思路，在嵌入式项目里根本行不通。

1.4 集成测试太晚——发现问题时已经来不及了

瀑布模型把集成测试放在最后。这在纯软件项目里已经够呛了，在嵌入式项目里更是灾难。

为什么？

• 硬件和软件的接口，只有集成时才能验证
• 实时性、功耗、内存占用这些非功能需求，只有跑在真机上才能测
• 多个模块之间的交互，模拟器永远模拟不出来

我经历过一个项目，所有模块都开发完了，一集成，发现A模块和B模块共用同一个DMA通道，互相抢资源。改吧，牵一发而动全身。不改吧，系统跑起来就死机。

1.5 文档驱动开发——写文档的时间比写代码还多

瀑布模型强调文档。需求文档、设计文档、测试文档、用户手册……每样都不能少。但嵌入式项目节奏快、变化多，文档往往跟不上变化。

「文档写完了，代码还没写。代码写完了，文档已经过时了。」——这是很多嵌入式团队的写照。

我个人习惯是：关键接口和架构要有文档，但具体实现细节，代码注释比文档更靠谱。你想想看，一个函数的行为，是看500字的文档描述快，还是直接看100行的代码快？

1.6 总结：瀑布模型为什么不适合嵌入式？

说了这么多，其实核心就一句话：瀑布模型假设世界是确定的，但嵌入式开发的世界充满了不确定性。

硬件不确定、需求不确定、调试环境不确定……在这种环境下，你还想一步到位？不现实。

那怎么办？我们需要一种能拥抱变化、快速反馈、持续集成的开发方式。这就是敏捷开发的价值所在。

下一章，我会聊聊怎么把敏捷开发的理念，真正落地到嵌入式项目里。不是那种「开个站会就叫敏捷」的表面功夫，而是实实在在能解决问题的实践方法。

嗯，咱们下章见。