嵌入式项目具有典型的系统工程特征，往往跨越硬件、驱动、协议栈、应用层、云端管控等多个技术域。随着项目规模与参与角色的增加，仅依靠个人式开发或线性推进模式难以维持效率。因此，如何组织团队、控制交付节奏、处理需求变化、保障质量与进度的平衡，成为嵌入式项目管理的核心挑战。

实务中最常见的两类开发管理模型分别是：

• 瀑布式开发模型
• 敏捷开发模型

二者各自代表不同的工程假设和组织哲学。

---

一、瀑布式开发：以文档和流程驱动的系统工程思想

瀑布模型强调阶段性推进和文档完备性，其流程通常为：

需求 → 设计 → 开发 → 测试 → 交付 → 运行维护

优势：可控、可审计、可追溯

特点	工程价值
阶段清晰，有明确里程碑	有利于进度管理、外部验收和跨组织协作
文档作为交付物	降低人员变动导致的知识断层
大型系统架构提前设计	避免后期结构性返工风险
强流程约束	与外包、政府项目、供应链协同等契合度高

局限性：对变化不友好

局限	表现与后果
对需求变更反应迟缓	客户理解与开发理解可能长期脱节
创造性空间受限	工程人员角色趋向流水线化
交付周期长	无法适应快速试错的市场环境

适用场景

• 需求相对稳定
• 系统强依赖前期架构设计
• 安全 / 合规 / 行业标准驱动型系统
  例如：电力自动化系统、轨道控制系统、工业MES/SCADA系统等。

---

二、敏捷与Scrum：以迭代和反馈驱动的价值交付模型

敏捷思想的核心是：

快速交付可用价值 → 获取用户反馈 → 在下一次迭代中修正方向

Scrum作为敏捷的工程落地方法，关键角色与流程包括：

1. 三种角色

角色	主要职责
产品负责人（PO）	管理需求优先级，定义交付目标
开发团队	自组织执行，实现增量功能
Scrum Master（流程维护者）	保证节奏推进，清除流程阻碍

2. 典型迭代（Sprint）流程

1. 需求选取（Sprint Planning）
2. 任务拆解（任务颗粒度 ≤ 2 天）
3. 每日站会（Daily Scrum，<15 min）
4. 持续集成（CI / 可演示运行态版本）
5. 迭代验收（Review Meeting）
6. 复盘与改进（Retrospective）

优势

• 高度适配需求动态变化
• 用户参与度高，价值验证周期短
• 鼓励团队自治与能力成长

弱点

• 强依赖人员能力与沟通效率
• 缺少文档可能导致知识散失
• Team文化不成熟时容易失控

---

三、两种思维模型的本质差异

对比维度	瀑布	敏捷（Scrum）
核心驱动力	文档与计划	人员与协作
需求变化处理方式	抵抗变化，先冻结再实施	接受变化，持续试错迭代
风险暴露时机	后期集中暴露	早期持续暴露
成果展示方式	阶段性验收	周期性可运行交付
成员角色定位	工种分工明确	团队自驱、多角色复用

一句话总结：
瀑布追求 可控性，敏捷追求 可适应性。

---

四、混合式模型

现实中，成熟技术团队不会单纯采用某一种方法，而是基于业务不确定性、系统复杂度、人员成熟度进行方法组合：

架构、接口、协议栈、硬件底层——采用瀑布式阶段管理
功能应用层、UI、人机交互、网络业务——采用敏捷迭代交付

即：

• 底层靠稳（避免结构性返工）
• 上层靠快（随需求演进）

典型落地策略

层级	建议管理模式	理由
硬件设计 / 驱动 / 协议栈	瀑布 + 文档清单化	结构性变更成本高
系统功能 / UI / 通信逻辑	Scrum敏捷迭代	需求变化最活跃
云端 / APP配套	快速迭代	直接面向用户，反馈周期短

---

开发模式本质不是流程问题，而是组织行为问题。

只要团队对“如何推进工作”达成共识，任何模式都能高效；反之再先进的方法也会失效。

对于技术负责人来说，真正的能力不是“选瀑布还是敏捷”，而是：

• 判断问题的系统结构性与不确定性
• 在变化和纪律之间寻找动态平衡
• 让团队理解并认同这一平衡点