敏捷开发实践指南
# 敏捷开发实践指南
Agile vs Waterfall、Scrum vs Kanban——敏捷不是站会就完事了
# 一、敏捷的真相：不是更快，是不做错的东西
很多团队说"我们搞敏捷"——然后每天早晨多了个站会，其他一切照旧。这不是敏捷，这是在瀑布模型上贴了个敏捷标签。
瀑布模型 ｜ 敏捷模型
需求 → 设计 → 开发 → 测试 → 上线 ｜ 小循环 × N 次
（6 个月后用户第一次看到产品） ｜ （2 周后用户就能看到一部分）
↑ ｜ ↑
最大风险 ｜ 最大优势
交付时发现做的不是用户想要的 ｜ 快速发现"做错了"，及时掉头
敏捷的本质不是"更快的开发速度"——是"更快的反馈循环"。 你每 2 周就能验证一次"我做的方向对不对"，而不是等到 6 个月后才验证。
# 工程师在敏捷中的角色
❌ 被动角色：
站会上说"昨天写代码，今天继续写" → 沦为报流水账
Sprint Planning 上等分配任务 → 没有参与感
✅ 主动角色：
站会上说"昨天解决了 XX 问题，今天打算做 YY，卡在 ZZ 需要帮忙" → 这不是报流水账，是直接暴露风险和寻求帮助
Sprint Planning 前先看 Product Backlog → 你对哪几个 item 有话说？提前准备
# 二、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）
两个看板共存——但每个工程师一次只在一个看板上
# 三、被做烂了的三个敏捷实践，正确做法
# 3.1 站会——15 分钟，不是听你讲故事的
❌ "昨天我在写用户模块，写了一半，然后产品经理找我说了一个新需求……"
→ 讲了一分钟还在铺垫，大家已经走神了。
✅ 每个站会只三句话（30 秒/人）：
1. 昨天做了什么（一句话）
2. 今天打算做什么（一句话）
3. 有什么阻碍（如果没有就说"没有阻碍"）
站会的听众不是 Scrum Master——是你旁边的工程师。 你听到他说"卡在数据库迁移"——站会结束后你可能直接去帮他。这叫协作，不叫报流水账。
# 3.2 Sprint Planning——先定目标，再拉任务
❌ 看板上一堆任务，从上往下拉，"看看我们这周能做多少"
→ 做了一堆孤立的任务，Sprint 结束不知道交付了什么
✅ 先确定 Sprint Goal（一句话）：
"本 Sprint 的目标是：用户可以用手机号注册并下单。"
→ 然后往前倒推：为了达成这个目标，最少需要哪些 story？
→ 目标以外的 story 都不进这个 Sprint
没有 Sprint Goal 的 Sprint 就是一堆散装任务。
# 3.3 Retro（回顾会）——别变成批斗会或鸡汤会
❌ "这次 Sprint 大家都很努力，继续加油！"
→ 没错，但没用。
✅ 固定格式：Start / Stop / Continue
每人至少各写一条便利贴：
Start（开始做）：我们没做但该做的 → "代码合入前做一次自动化回归"
Stop（停止做）：我们在做但不该做的 → "测试环境手动部署——改为自动"
Continue（保持做）：我们做了且效果好的 → "PR 24 小时内 review"
选 1-2 条 Start/Stop 作为下个 Sprint 的改进项——写进 Sprint Backlog，下次 Retro 验收。
改进项不被跟踪的 Retro 就是团队团建。
# 四、工程师如何推动敏捷落地
敏捷推行不下去最常见的原因：Scrum Master 推，工程师不买账。
# 4.1 从"减少痛苦"开始
不要对团队说："我们要搞敏捷了。"
要说："我发现上次部署挂了一下午，原因是没做自动化验证。
我们这个 Sprint 能不能花半天把这步自动化了？以后每次上线都省半天。"
推动流程改进不靠"敏捷圣经"，靠"这个改变能帮你少加班"。
# 4.2 少即是多——每次只改一点
❌ 一次性引入：站会 + Sprint + Retro + Story Point + 燃尽图 + 看板 + …
→ 团队不堪重负，反感油然而生
✅ 渐进引入：
第 1 个月：只开站会（用 2 周养成习惯）
第 2 个月：加入 Sprint Planning + Retro
第 3 个月：引入 Story Point 估算
第 4 个月：看数据——Sprint 是否越来越稳定？Velocity 是否可预测？
# 五、敏捷的常见反模式
# 5.1 站会变汇报会
症状：每个人对着 Scrum Master 汇报昨天做了什么——Scrum Master 成了项目经理。
修正：站会是团队成员之间互相同步，不是向上级汇报。说话的对象是其他工程师，不是 SM。
# 5.2 Retro 产出"鸡汤"
症状：Retro 产出"沟通要加强""质量要提升"——毫无操作性。
修正：每一条 Action 必须满足——谁、做什么、什么时候完成、怎么验证。四要素缺一不可。
❌ "提高单测覆盖率"
✅ "小王在下次 Sprint 结束前把支付模块单测覆盖率从 40% 提升到 65%，用 JaCoCo 报告验证"
# 5.3 Velocity 当 KPI
症状：Leader 盯着 Velocity 曲线——"这个 Sprint 只有 28 点，上个月可是 32 点"。
修正：Velocity 是团队的产能参考，不是个人考核指标。一旦和个人绩效挂钩——Story Point 会通货膨胀到你无法想象。
# 六、远程/分布式团队的敏捷适配
| 仪式 | 线下做法 | 远程做法 | 坑 |
|---|---|---|---|
| 站会 | 围在白板前 | 视频会议，每个人共享屏幕 | 有人在开车/通勤中参加——听不到、说不出 |
| Planning | 会议室投屏 | Miro/Jira 在线看板 | 看板更新不及时，远程的人看到的是过时信息 |
| Retro | 贴便利贴 | Miro/Retrium | 没人开摄像头 → 参与度断崖下跌 |
远程敏捷的核心原则：异步优先、文档先行、重要决策留文字。
# 七、小结
敏捷不是一套流程——是"通过快速反馈避免做出用户不需要的东西"的思维模式。
核心三个改进：
1. 缩短反馈周期 → 从 6 个月到 2 周
2. 减少在制品 → 一个人同时做不超过 2 个任务
3. Retro 产出行动项 → 每次至少一个 Start + 一个 Stop，下个 Sprint 跟踪
行动清单：
- [ ] 下次站会：每人严格 30 秒
- [ ] Sprint Planning：先写 Sprint Goal 再拉任务
- [ ] Retro：只讨论 Start/Stop/Continue，产出可跟踪的改进项
- [ ] 检查最近一次 Retro 的 Action——完成了吗？没完成的原因是什么？
