第一章：敏捷开发基础
大家好，我是你们的老朋友。今天咱们聊聊敏捷开发。
说实话，我刚开始做嵌入式那会儿，压根儿没听过「敏捷」这个词。那时候我们做项目，就是典型的瀑布流——需求写三个月，开发干半年，测试再折腾两个月。结果呢？产品出来，市场早变了。后来我转到一家做物联网设备的公司，才真正接触了敏捷开发。嗯，这一接触，就再也回不去了。
1.1 敏捷宣言：四个核心价值观
2001年，17位软件大佬聚在一起，搞了个「敏捷宣言」。说白了，就是四个对比关系：
- 个体和互动 高于 流程和工具
- 可工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
你可能会问：「那流程和工具就不重要了？」当然不是。敏捷宣言说的是「高于」，不是「代替」。流程要有，但别被流程绑死。我个人习惯是：该写的文档一个字不少，但别为了写文档而写文档。
我的经验： 有一次我们团队花了两周写了一份60页的需求文档，结果客户看完说「这不是我要的」。从那以后，我宁愿先做个原型给客户看，哪怕只有几个核心功能。可工作的软件，比任何文档都有说服力。
1.2 Scrum框架：三个核心概念
Scrum是目前最流行的敏捷框架。我把它拆成三个核心概念来讲。
Sprint（冲刺）
Sprint就是一个固定时间周期，一般是1到4周。在这个周期里，团队要完成一组预先承诺的任务。
为什么要有Sprint？说白了，就是给团队一个「截止日期」的感觉。我见过太多项目，没有时间边界，做着做着就失控了。
避坑指南： 我曾经把一个Sprint设成6周，觉得时间充裕。结果前两周大家慢悠悠，后四周疯狂加班。后来我改成2周一个Sprint，节奏感好多了。记住：Sprint越短，反馈越快。
Daily Standup（每日站会）
每天固定时间，15分钟，站着开。每个人回答三个问题：
- 昨天我做了什么？
- 今天我要做什么？
- 我遇到了什么障碍？
注意，这不是汇报工作，是同步信息。我见过有些团队把站会开成了「批斗会」，那就变味了。
警告： 站会不要超过15分钟。如果某个问题需要深入讨论，会后拉个小会单独聊。我曾经犯过这个错——站会开了40分钟，大家腿都站麻了，效率反而更低。
Retrospective（回顾会议）
每个Sprint结束后，团队坐下来复盘。不是找谁背锅，而是找改进点。
我常用的格式是：
| 做得好的 | 需要改进的 | 下一步行动 |
|---|---|---|
| 代码审查及时 | 测试覆盖率不够 | 下个Sprint增加单元测试 |
| 沟通顺畅 | 需求变更频繁 | 和产品经理约定变更流程 |
你想想看，如果每个Sprint都能改进一点点，一年下来就是质的飞跃。
1.3 看板方法：可视化你的工作流
看板方法比Scrum更轻量。它不要求固定Sprint，也不要求特定角色。核心就三样东西：
- 看板：一块白板，或者一个电子面板
- 列：代表工作流的各个阶段（待办、进行中、测试中、已完成）
- 卡片：代表一个任务
我最早用看板是在一个嵌入式项目中。我们把硬件调试、固件开发、测试验证分成三列。每个人每天上班第一件事，就是移动自己的卡片。
关键原则： 限制在制品数量（WIP Limit）。比如「进行中」这一列最多只能有3张卡片。为什么？因为多任务切换是效率杀手。我见过有人同时开5个任务，结果一个都没完成。专注，才是最快的。
看板的好处是「透明」。谁在做什么，卡在哪里，一眼就能看出来。我记得有一次，测试列堆了10张卡片，开发列却还在不断加新任务。老板一看就明白了——测试资源不够，赶紧加人。
1.4 敏捷在嵌入式中的特殊挑战
你可能会说：「敏捷是软件开发的，嵌入式有硬件，怎么敏捷？」
嗯，这是个好问题。我踩过不少坑，总结几点：
- 硬件迭代慢：PCB打样要两周，没法像软件那样快速迭代。我的做法是：硬件用「里程碑」节奏，软件用「Sprint」节奏，两者对齐。
- 测试依赖硬件：没有硬件，软件怎么测？我建议用模拟器或开发板先跑核心逻辑，等硬件回来再集成测试。
- 固件烧录耗时：每次改代码都要烧录，很烦。我习惯用OTA（空中升级）或者JTAG调试器，能省不少时间。
我的小技巧： 在嵌入式项目中，我经常把「硬件可用」作为一个里程碑。硬件没到之前，软件团队做单元测试和模拟测试。硬件一到，立刻集成。这样既不浪费等待时间，又能快速发现问题。
1.5 总结
敏捷开发不是银弹，但它确实能帮嵌入式团队提高效率。核心就三点：
- 迭代：别想一口吃成胖子，小步快跑
- 反馈：尽早发现问题，别等到最后
- 改进：每个周期都复盘，持续优化
下一章，咱们聊聊怎么把CI/CD（持续集成/持续交付）嵌入到嵌入式开发中。到时候我会分享一些具体的工具链和实战案例。敬请期待。
公众号:蓝海资料掘金营，微信deep3321