第3章：Scrum框架速览：Sprint、Daily Standup、Review、Retrospective
好，咱们直接进入正题。Scrum 这玩意儿，说白了就四个核心活动：Sprint、Daily Standup、Sprint Review、Sprint Retrospective。很多嵌入式团队一听「敏捷」就觉得是互联网那套，不适合硬件。我当年也这么想，直到真的踩了坑才明白——不是框架不行，是你没找到落地的姿势。
3.1 Sprint：别搞一个月，两周刚刚好
Sprint 就是迭代周期。互联网团队喜欢两周，嵌入式呢？我个人建议也是两周。为什么？
你想想看，嵌入式项目里，硬件打板、固件烧录、测试验证，这些环节天然就有延迟。一个月太长了，团队容易迷失方向。两周刚好——既能让硬件组有个明确的目标，又不会让软件组等太久。
关键点：Sprint 长度要固定
别今天两周，明天三周。固定节奏才能形成习惯。我在项目中遇到过团队想「这周任务重，延到三周吧」——结果一延再延，最后变成了瀑布流。
Sprint 里要做什么？三个东西必须定死：
- Sprint Goal：这周我们要让哪个模块跑起来？比如「实现 I2C 驱动并能在开发板上点亮 LED」
- Product Backlog 条目：从需求池里挑出优先级最高的任务
- Definition of Done：什么叫「做完」？代码写完？编译通过？烧录验证？我建议至少包括「通过单元测试 + 硬件联调通过」
我的习惯：Sprint 第一天上午开计划会，下午就动手。别拖到第二天，否则节奏就乱了。
3.2 Daily Standup：站着说，别坐着聊
Daily Standup，每日站会。15 分钟，站着开。三个问题：
- 昨天我做了什么？
- 今天我要做什么？
- 有什么阻碍？
听起来简单吧？但嵌入式团队最容易犯的错是——变成「进度汇报会」。我曾经见过一个团队，站会开了 40 分钟，每个人都在讲技术细节，什么寄存器配置、中断优先级……停！这不是站会该干的事。
避坑指南：站会不是给领导汇报的，是给队友同步信息的。我曾经带过一个项目，硬件工程师在站会上说「我昨天在调电源模块，发现纹波有点大」——然后软件团队一脸懵。后来我要求：只说跟 Sprint Goal 相关的事，技术细节私下聊。
嵌入式团队站会怎么开？我建议这样：
- 时间固定：每天早上 9:15，雷打不动
- 地点固定：白板前，或者开发台旁边
- 工具辅助：用物理看板或者电子看板（Jira、Trello 都行），把任务卡片挪一挪
- 硬件问题单独拎出来：如果硬件组有阻塞，站会后立刻拉个小会解决
说白了，站会的核心是「对齐」和「暴露问题」。不是让你做技术答辩。
3.3 Sprint Review：别只给领导看，给团队看
Sprint Review，评审会。很多人以为这是「验收会」——错了。这是「展示会」+「反馈会」。
嵌入式项目的 Review 怎么做？我见过最糟糕的做法：项目经理打开 PPT，念一遍需求文档。嗯，那还不如不开。
我的做法是：
- 现场演示：把代码烧到开发板上，跑起来给大家看。比如「这周我们实现了温度传感器读取，来，我现场测一下室温」
- 邀请利益相关者：产品经理、测试、甚至客户代表。让他们亲手摸一摸开发板，按一按按钮
- 收集反馈：别只报喜不报忧。如果某个功能没做完，直接说「这个还在调，下周 Sprint 继续」
重要提醒：Review 不是「审判会」。别让领导在会上问「为什么没做完？」——那是 Retrospective 该聊的事。
我记得有一次，我们做智能家居网关项目。Sprint Review 上，硬件工程师直接拿了个面包板，现场演示 Zigbee 组网。产品经理一看，说「这个指示灯闪烁频率太慢了，用户会以为没连上」——当场就改了需求。你看，这就是 Review 的价值。
3.4 Sprint Retrospective：别走过场，真反思
Retrospective，回顾会。这是 Scrum 里最有价值、但也最容易被忽视的环节。
很多嵌入式团队觉得「活都干完了，还开什么会？」——嗯，我刚开始也这么想。直到有一次项目延期两个月，复盘时才发现：原来每个 Sprint 都在重复同样的错误。
Retrospective 怎么做？我推荐「Start-Stop-Continue」模型：
| 类别 | 含义 | 嵌入式团队常见例子 |
|---|---|---|
| Start | 开始做 | 「每次烧录前先跑一遍静态检查」 |
| Stop | 停止做 | 「不要在周五下午提交代码合并请求」 |
| Continue | 继续做 | 「每天下班前更新看板状态」 |
具体操作：
- 时间：Sprint 最后一天下午，1-2 小时
- 氛围：轻松点，买点零食饮料。别搞成批斗会
- 输出：至少 1-2 个 actionable 的改进项，下个 Sprint 必须执行
我的经验：Retrospective 上最容易出现的问题是「大家不敢说真话」。我习惯用匿名投票的方式收集意见——每人写 3 个问题，投到箱子里，然后一起讨论。效果比当面说好得多。
举个例子。有一次 Retro 上，团队提出「硬件组和软件组沟通太少，经常等对方做完才发现接口对不上」。于是我们定了一个改进项：每个 Sprint 开始前，硬件和软件工程师必须一起过一遍接口文档。就这么简单一件事，后面几个 Sprint 的联调时间直接缩短了 30%。
3.5 嵌入式团队落地的三个关键点
说了这么多，总结一下。Scrum 在嵌入式团队落地，有三个坑必须避开：
- 别照搬互联网模板：嵌入式有硬件周期、烧录时间、测试环境限制。Sprint 计划时要留出「硬件等待时间」
- 别让站会变成技术讨论：15 分钟就是 15 分钟。技术问题会后拉小群聊
- 别把 Retro 当形式：改进项要落实到人、落实到时间。我见过最差的 Retro——开完会，改进项写在白板上，然后没人管了
最后一句真心话：Scrum 不是银弹。它只是帮你暴露问题的工具。真正让团队变强的，是你们愿意面对问题、持续改进的态度。嗯，这话听起来有点鸡汤，但我在十几个项目里验证过——真的管用。
下一章，咱们聊聊 Product Backlog 怎么管理。嵌入式项目的需求池，可比互联网的乱多了……到时候我教你一招「三层过滤法」。