产品经理课程 · 第三阶段：项目管理
⚡ 11 - 敏捷开发
Scrum仪式+故事点+燃尽图
📋 本章导读
敏捷不是一种流程，而是一种思维方式——拥抱变化、快速交付、持续改进。本章将深入Scrum的核心仪式、故事点估算和燃尽图，让你真正理解"敏捷"而非只是"走流程"。
🎯 学习目标
- 理解敏捷宣言4条价值观和12条原则的本质
- 掌握Scrum的5个仪式及其PM角色
- 学会故事点估算和规划扑克
- 能阅读和使用燃尽图进行进度追踪
一、敏捷宣言：4条价值观的本质
| 价值观 | 更重视 | 并非不要 | PM实践 |
|---|
| 个体和互动 | 面对面的沟通 | 流程和工具 | 站会聊天而非只看JIRA |
| 可工作的软件 | 交付可用的功能 | 详尽的文档 | PRD够用即可，别写论文 |
| 客户合作 | 与用户共创 | 合同谈判 | 每周与用户沟通而非季度 |
| 响应变化 | 拥抱不确定性 | 遵循计划 | 路线图灵活调整而非死守 |
⚠️ 最大的误解：敏捷≠没有文档、没有计划、没有流程。敏捷是"够用的文档、灵活的计划、轻量的流程"。如果团队连用户故事都写不清楚就说"我们敏捷"，那不叫敏捷，叫混乱。
二、Scrum五大仪式：PM的角色和职责
📅 1. Sprint Planning（迭代规划会）
- 时长：2-4小时（2周Sprint）
- PM职责：讲解用户故事和验收标准，回答"为什么做"和"做成什么样"
- 关键产出：Sprint Backlog + Sprint Goal
- PM避坑：不要在规划会上改需求！需求变更应该在Sprint之间讨论
🌞 2. Daily Standup（每日站会）
- 时长：15分钟，严格限时
- 三个问题：昨天完成了什么？今天计划做什么？有什么阻碍？
- PM职责：回答疑问、消除阻碍、不在站会上讨论细节
- PM避坑：站会不是汇报会，不是讨论会。需要深入讨论的，会后单独聊
🎉 3. Sprint Review（迭代评审会）
- 时长：1-2小时
- PM职责：演示产品增量，邀请利益相关方，收集反馈
- 关键产出：已完成功能确认 + 新的反馈和需求
- PM避坑：Review不是PPT汇报，是可工作软件的现场演示。能点击、能操作、能体验
🔄 4. Sprint Retrospective（迭代回顾会）
- 时长：1-1.5小时
- 三个问题：什么做得好？什么需要改进？下一步行动是什么？
- PM职责：作为团队一员参与反思，不只是指出别人的问题
- PM避坑：回顾会不是批斗会。聚焦流程和协作，不针对个人
📚 5. Backlog Refinement（需求梳理会）
- 时长：每周1小时
- PM职责：拆分大型用户故事、补充验收标准、调整优先级
- 关键产出：Ready for Sprint的用户故事
- PM避坑：梳理会不是规划会，只是把故事准备到"可规划"状态
三、故事点估算：规划扑克实战
故事点衡量的不是时间，而是复杂度——包含工作量、不确定性和风险的综合评估。
🃏 规划扑克流程
- PM讲解故事：读用户故事+验收标准，团队提问
- 每人独立出牌：用斐波那契数列（1/2/3/5/8/13/21）打分
- 同时亮牌：避免锚定效应
- 讨论差异：最高分和最低分的人解释理由
- 重新出牌：通常1-2轮就能收敛
- 记录结果：故事点写入Backlog
💡 故事点速查：1点=简单文字改动；2点=小UI调整；3点=标准功能；5点=复杂功能含边界；8点=需技术预研；13点=应拆分；21点=太大必须拆。
四、燃尽图：进度可视化的利器
燃尽图是Sprint进度的体温计——一眼看出是正常、延期还是超前。
📈 燃尽图三种状态
- 理想线：从总故事点到0的直线——匀速完成的理想情况
- 实际线在理想线下方：超前——但别高兴太早，可能估算太保守
- 实际线在理想线上方：延期——需要讨论：砍范围？加人？延长时间？
- 实际线不降反升：严重问题——范围蔓延或估算严重不足，立即召开讨论
五、案例深度拆解：Spotify的敏捷模型
🎵 Spotify：Squad/Tribe/Chapter/Guild
Spotify没有照搬Scrum，而是创造了自家的敏捷模型——至今仍是行业标杆。
- Squad（小队）：6-12人的跨职能团队，拥有端到端的产品自主权，像一个迷你创业公司
- Tribe（部落）：40-150人，相关Squad的集合，共享业务领域
- Chapter（分会）：同一Tribe内相同职能的人（如所有前端），保证专业成长
- Guild（公会）：跨Tribe的兴趣社区，分享最佳实践
💡 Spotify模型的核心：自治而非控制。每个Squad有自己的Backlog、自己的节奏、自己的技术选择。PM的角色不是指挥，而是提供上下文——让团队理解"为什么"，他们自己能找到"怎么做"。
🧪 练习1：Sprint Planning模拟
假设你的Sprint容量是30点，当前Backlog有8个故事（3/5/8/2/13/5/3/8点），请按优先级选出Sprint Backlog，确定Sprint Goal，列出可能的风险。
🧪 练习2：故事点估算实践
邀请3位同事，用规划扑克对5个用户故事进行估算。记录每轮的出牌差异和讨论要点，观察1-2轮后是否收敛。
🧪 练习3：燃尽图分析
找一个正在进行的Sprint，连续5天记录剩余故事点，画出燃尽图。与理想线对比，判断Sprint健康状态，提出调整建议。
🏆 本章成就
- ✅ Scrum实践者 — 掌握5个仪式的PM角色和最佳实践
- ✅ 估算高手 — 用规划扑克达成团队共识的故事点
- ✅ 燃尽图阅读者 — 从图表中识别进度风险并提前干预
- ✅ 敏捷思维者 — 理解敏捷本质而非只是走流程
六、敏捷反模式：看似敏捷实则混乱
⚠️ 7种敏捷反模式
| 反模式 | 症状 | 根因 | 修正方法 |
|---|
| 假敏捷 | 每日站会但无Sprint目标 | 只学了仪式没理解精神 | 每个Sprint必须有Goal |
| 瀑布敏捷 | 设计→开发→测试串行 | 跨职能协作没建立 | 团队内必须有设计和测试 |
| Sprint填充 | 什么都往Sprint里塞 | 无法说不 | 基于速率做承诺 |
| 需求银行 | Backlog无限膨胀 | 从不清理 | 每季度Backlog Grooming |
| 回顾无效 | 回顾会开了但没行动 | 行动项无人负责 | 每项指定负责人 |
| 产品Owner缺位 | PM不参加规划/评审 | PM角色不清 | PM必须是PO |
| 速度崇拜 | 追求速率数字 | 速率是预测工具非KPI | 聚焦交付价值非故事点 |
📚 敏捷开发推荐阅读
- 《Scrum Guide》Schwaber & Sutherland — Scrum官方指南（免费）
- 《User Stories Applied》strong>Mike Cohn — 用户故事的实操手册
- 《Agile Estimating and Planning》strong>Mike Cohn — 敏捷估算和规划
💡 敏捷的核心心法：敏捷不是一种流程，是一种思维——拥抱变化、快速交付、持续改进。如果你团队"走敏捷流程"但依然延期、质量差、团队疲惫，那不是敏捷有问题，是你们没有真正理解敏捷。
七、Kanban vs Scrum：选择适合你的
📋 Scrum
- 固定Sprint长度（2周）
- Sprint承诺+Sprint Goal
li>角色：PO/SM/Team
- 适合：产品开发、功能迭代
- 优点：节奏感强、交付可预测
- 缺点：切换成本高、Sprint内变更困难
📊 Kanban
- 持续流动，无固定迭代
- 限制WIP（在制品数量）
- 无固定角色
- 适合：运维、Bug修复、维护
- 优点：灵活、可视化、瓶颈可见
- 缺点：缺乏节奏感、交付时间不确定
八、产品经理在Scrum中的3种角色误区
❌ PM角色误区
| 误区 | 表现 | 正确做法 |
|---|
| 项目经理式PM | 分配任务、催进度、盯人 | PM=Product Owner，关注"做什么"而非"怎么做" |
| 需求搬运工 | 只传达业务方需求不加判断 | PM要过滤、排序、说"不" |
| 甩手掌柜 | 规划完就消失，评审才出现 | 全程参与，每日可联系，随时答疑 |
✅ Product Owner的核心职责
- 维护Product Backlog：排序、拆分、补充验收标准——Backlog是PM最重要的交付物
- Sprint Planning讲解需求：每个用户故事的背景、用户价值、验收标准
- Sprint Review验收交付：确认每个故事是否符合预期，不符合就打回
- 每日可联系：开发有问题能随时找到PM——不要让团队等
- 说不：对不合理的需求说不，对Sprint中途加需求说不，对"先做再说"说不