敏捷开发实践指南
# 敏捷开发实践指南
Agile vs Waterfall、Scrum vs Kanban——敏捷不是站会就完事了
# 一、敏捷的真相：不是更快，是不做错的东西
很多团队说"我们搞敏捷"——然后每天早晨多了个站会，其他一切照旧。这不是敏捷，这是在瀑布模型上贴了个敏捷标签。
瀑布模型 ｜ 敏捷模型
需求 → 设计 → 开发 → 测试 → 上线 ｜ 小循环 × N 次
（6 个月后用户第一次看到产品） ｜ （2 周后用户就能看到一部分）
↑ ｜ ↑
最大风险 ｜ 最大优势
交付时发现做的不是用户想要的 ｜ 快速发现"做错了"，及时掉头
1
2
3
4
5
6
2
3
4
5
6
敏捷的本质不是"更快的开发速度"——是"更快的反馈循环"。 你每 2 周就能验证一次"我做的方向对不对"，而不是等到 6 个月后才验证。
# 工程师在敏捷中的角色
❌ 被动角色：
站会上说"昨天写代码，今天继续写" → 沦为报流水账
Sprint Planning 上等分配任务 → 没有参与感
✅ 主动角色：
站会上说"昨天解决了 XX 问题，今天打算做 YY，卡在 ZZ 需要帮忙" → 这不是报流水账，是直接暴露风险和寻求帮助
Sprint Planning 前先看 Product Backlog → 你对哪几个 item 有话说？提前准备
1
2
3
4
5
6
7
2
3
4
5
6
7
# 二、Scrum vs Kanban——选哪个
| 维度 | Scrum | Kanban |
|---|---|---|
| 节奏 | 固定 Sprint（通常 2 周） | 持续流动，无固定周期 |
| 计划 | Sprint Planning 确定本周期做什么 | 从 Backlog 按优先级拉取 |
| 变更 | Sprint 进行中不建议改需求 | 随时可以插新任务 |
| WIP 限制 | 隐含在 Sprint 容量里 | 每个阶段有明确的 WIP 上限 |
| 适合场景 | 有明确方向的产品开发 | 运维/oncall/紧急需求多的团队 |
判断标准：如果你的需求 80% 可以提前一周计划 → Scrum。如果你的需求 50% 以上是当天冒出来的 → Kanban。很多团队实际上在 Scrum 里夹杂了 Kanban 的模式——这不丢人，混用比硬套要好。
实战建议：
用 Scrum 做产品开发（有 Sprint 节奏）
用 Kanban 做线上问题处理（来了就排优先级，不设 Sprint）
两个看板共存——但每个工程师一次只在一个看板上
1
2
3
4
2
3
4
# 三、被做烂了的三个敏捷实践，正确做法
# 3.1 站会——15 分钟，不是听你讲故事的
❌ "昨天我在写用户模块，写了一半，然后产品经理找我说了一个新需求……"
→ 讲了一分钟还在铺垫，大家已经走神了。
✅ 每个站会只三句话（30 秒/人）：
1. 昨天做了什么（一句话）
2. 今天打算做什么（一句话）
3. 有什么阻碍（如果没有就说"没有阻碍"）
1
2
3
4
5
6
7
2
3
4
5
6
7
站会的听众不是 Scrum Master——是你旁边的工程师。 你听到他说"卡在数据库迁移"——站会结束后你可能直接去帮他。这叫协作，不叫报流水账。
# 3.2 Sprint Planning——先定目标，再拉任务
❌ 看板上一堆任务，从上往下拉，"看看我们这周能做多少"
→ 做了一堆孤立的任务，Sprint 结束不知道交付了什么
✅ 先确定 Sprint Goal（一句话）：
"本 Sprint 的目标是：用户可以用手机号注册并下单。"
→ 然后往前倒推：为了达成这个目标，最少需要哪些 story？
→ 目标以外的 story 都不进这个 Sprint
1
2
3
4
5
6
7
2
3
4
5
6
7
没有 Sprint Goal 的 Sprint 就是一堆散装任务。
# 3.3 Retro（回顾会）——别变成批斗会或鸡汤会
❌ "这次 Sprint 大家都很努力，继续加油！"
→ 没错，但没用。
✅ 固定格式：Start / Stop / Continue
每人至少各写一条便利贴：
Start（开始做）：我们没做但该做的 → "代码合入前做一次自动化回归"
Stop（停止做）：我们在做但不该做的 → "测试环境手动部署——改为自动"
Continue（保持做）：我们做了且效果好的 → "PR 24 小时内 review"
选 1-2 条 Start/Stop 作为下个 Sprint 的改进项——写进 Sprint Backlog，下次 Retro 验收。
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
改进项不被跟踪的 Retro 就是团队团建。
# 四、工程师如何推动敏捷落地
敏捷推行不下去最常见的原因：Scrum Master 推，工程师不买账。
# 4.1 从"减少痛苦"开始
不要对团队说："我们要搞敏捷了。"
要说："我发现上次部署挂了一下午，原因是没做自动化验证。
我们这个 Sprint 能不能花半天把这步自动化了？以后每次上线都省半天。"
1
2
3
2
3
推动流程改进不靠"敏捷圣经"，靠"这个改变能帮你少加班"。
# 4.2 少即是多——每次只改一点
❌ 一次性引入：站会 + Sprint + Retro + Story Point + 燃尽图 + 看板 + …
→ 团队不堪重负，反感油然而生
✅ 渐进引入：
第 1 个月：只开站会（用 2 周养成习惯）
第 2 个月：加入 Sprint Planning + Retro
第 3 个月：引入 Story Point 估算
第 4 个月：看数据——Sprint 是否越来越稳定？Velocity 是否可预测？
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
# 五、小结
敏捷不是一套流程——是"通过快速反馈避免做出用户不需要的东西"的思维模式。
核心三个改进：
1. 缩短反馈周期 → 从 6 个月到 2 周。不要怕"功能不完整"，只怕"方向错了"
2. 减少在制品 → 一个人同时做的任务不超过 2 个（Scrum：整个 Sprint 的任务量；Kanban：WIP 限制）
3. Retro 产出行动项 → 每次回顾至少一个"Start"和一个"Stop"，下个 Sprint 跟踪
1
2
3
4
5
6
7
2
3
4
5
6
7
行动清单：
- [ ] 下次站会：每个人严格 30 秒，超时 Scrum Master 打断
- [ ] 下次 Sprint Planning：先写 Sprint Goal 再拉任务——Goal 写不满一句话说明你没想清楚
- [ ] 下次 Retro：只讨论 Start/Stop/Continue，产出 1-2 个可跟踪的改进项
上次更新: 2026/06/15, 14:32:53
