项目管理基础：嵌入式项目生命周期、敏捷开发与瀑布模型、需求分析与文档管理
做嵌入式开发久了，你会发现一个有意思的现象：很多技术牛人带项目，最后却栽在管理上。代码写得再漂亮，需求三天两头变，文档一塌糊涂，团队沟通全靠吼——这项目迟早要炸。我这些年踩过的坑，十有八九都不是技术问题，而是项目管理没跟上。
这一章，咱们就聊聊嵌入式项目管理的那些基本功。说白了，就是怎么把一件事从头到尾理清楚，让团队不白干、不返工、不背锅。
嵌入式项目的生命周期
一个嵌入式项目，从想法到量产，大致会经历这么几个阶段。我习惯把它分成六步：
| 阶段 | 核心产出 | 常见坑点 |
|---|---|---|
| 概念与可行性 | 技术选型报告、成本估算 | 低估硬件选型风险 |
| 需求分析 | 需求规格说明书（SRS） | 需求模糊、遗漏边界条件 |
| 系统设计 | 架构设计文档、接口定义 | 软硬件接口没对齐 |
| 实现与单元测试 | 代码、单元测试报告 | 硬件未就绪，软件空转 |
| 集成与系统测试 | 测试报告、缺陷清单 | 集成环境与现场环境不一致 |
| 量产与维护 | 生产指导书、固件基线 | 版本管理混乱，无法追溯 |
每个阶段都有明确的入口和出口。我见过最惨的项目，需求还没冻结就开始写代码，结果硬件改版三次，软件推倒重来两回。嗯，那个项目的项目经理后来转行了。
瀑布模型 vs 敏捷开发
嵌入式圈子里，瀑布和敏捷的争论从来没停过。我的看法是：别迷信，看场景。
瀑布模型
瀑布模型讲究的是「先想清楚，再动手」。每个阶段做完，评审通过，才进入下一阶段。适合需求稳定、硬件确定、安全要求高的项目。比如医疗设备、汽车电子、航空航天——这些领域，你敢在飞行控制软件上搞迭代？
瀑布的优点是文档完整、可追溯性强。缺点是太死板，客户看到成品时往往已经晚了。
敏捷开发
敏捷强调快速迭代、持续交付、拥抱变化。在嵌入式领域，敏捷更多是「Scrum + 看板」的变体。适合消费电子、IoT设备、原型验证阶段。
但要注意，嵌入式敏捷和纯软件敏捷不一样。你想想看，硬件打样周期摆在那里，你不可能每周都改PCB。所以嵌入式敏捷通常采用「硬件驱动节奏」——硬件版本定了，软件才进入冲刺。
怎么选？一张表说清楚
| 因素 | 适合瀑布 | 适合敏捷 |
|---|---|---|
| 需求稳定性 | 需求明确、变更少 | 需求模糊、频繁变更 |
| 硬件成熟度 | 硬件已定型 | 硬件仍在迭代 |
| 安全认证要求 | 高（如ISO 26262） | 低 |
| 团队规模 | 大团队、多部门 | 小团队、跨职能 |
| 交付周期 | 长（6个月以上） | 短（3个月以内） |
其实很多项目是混合模式。我建议：核心安全模块用瀑布，应用层功能用敏捷。这叫「双模开发」，很多大厂都在用。
需求分析与文档管理
需求分析是项目管理的起点，也是大多数项目翻车的根源。我见过太多「我以为你懂了」的悲剧。
需求分析的三个层次
- 业务需求：客户想要什么？比如「设备能在-20°C环境下正常工作」。
- 系统需求：系统该怎么做？比如「MCU工作温度范围需支持-40°C~85°C」。
- 软件需求：代码该怎么写？比如「温度传感器采样周期为100ms，超时重试3次」。
每一层都要可验证。我曾经遇到一个需求写着「系统响应要快」。快是多少？100ms还是1s？后来我们改成「从按键按下到LED亮起，延迟不超过50ms」。这才算一个合格的需求。
文档管理——别让文档成为摆设
很多工程师讨厌写文档，觉得浪费时间。但你知道吗？项目后期80%的沟通成本，都来自文档缺失或过时。
我建议嵌入式项目至少维护这几份文档：
- 需求规格说明书（SRS）： 项目启动时写，需求变更时更新。
- 软件架构设计文档（SAD）： 描述模块划分、接口定义、任务调度。
- 测试用例与测试报告： 每个功能点都要有对应的测试用例。
- 版本发布说明： 每次发版记录变更内容、已知问题、兼容性信息。
文档不用写成长篇大论。我习惯用「模板+关键信息」的方式。比如需求文档，一个表格搞定：ID、描述、优先级、来源、状态。够用了。
知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作项目管理的地图：
这张图把生命周期、开发模型、需求分析、文档管理串成了一条线。你从左上角开始看，顺着箭头走，就是一个完整项目的管理路径。
最后说一句：项目管理不是束缚，而是让团队少走弯路。工具和方法都是死的，关键是你能不能根据项目特点灵活调整。我见过用Excel管好大项目的，也见过用JIRA把团队管崩溃的。记住，管理是为了服务交付，不是为了管理而管理。