主题
6.1 敏捷开发与 Scrum
引言
在软件行业，"敏捷"（Agile）已经成为最主流的开发方式。作为产品经理，你几乎不可能绕开敏捷开发。无论你加入大厂还是创业公司，团队大概率在使用 Scrum 或 Kanban。理解敏捷不仅是面试加分项，更是日常工作的生存技能。
一、瀑布模型 vs 敏捷开发
1.1 什么是瀑布模型？
瀑布模型（Waterfall Model）是最早的软件开发方法，像瀑布一样从上往下、一步一步推进：
瀑布模型流程图
┌──────────┐
│ 需求分析 │
└────┬─────┘
│
▼
┌──────────┐
│ 系统设计 │
└────┬─────┘
│
▼
┌──────────┐
│ 详细设计 │
└────┬─────┘
│
▼
┌──────────┐
│ 编码实现 │
└────┬─────┘
│
▼
┌──────────┐
│ 系统测试 │
└────┬─────┘
│
▼
┌──────────┐
│ 部署上线 │
└────┬─────┘
│
▼
┌──────────┐
│ 运维维护 │
└──────────┘
特点：每个阶段完成后才进入下一阶段
前期需要非常完整的需求文档
一旦进入开发，需求变更成本极高1.2 什么是敏捷开发？
敏捷开发是一种迭代式、增量式的开发方法，将大项目拆分成多个小迭代，每个迭代都交付可用的产品增量：
敏捷开发流程图
┌─────────────────────────────────────────────────────┐
│ │
│ 迭代1 迭代2 迭代3 ... │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │计划 │ │计划 │ │计划 │ │
│ │设计 │ ──► │设计 │ ──► │设计 │ ──► ... │
│ │开发 │ │开发 │ │开发 │ │
│ │测试 │ │测试 │ │测试 │ │
│ │发布 │ │发布 │ │发布 │ │
│ └──────┘ └──────┘ └──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 可用产品v1 可用产品v2 可用产品v3 │
│ │
│ 每个迭代都交付可工作的软件，持续获取用户反馈 │
└─────────────────────────────────────────────────────┘1.3 瀑布模型 vs 敏捷开发 对比
| 维度 | 瀑布模型 | 敏捷开发 |
|---|---|---|
| 开发方式 | 线性、顺序执行 | 迭代、增量交付 |
| 需求定义 | 项目初期一次性确定 | 持续演进、允许变化 |
| 交付周期 | 数月甚至数年 | 1-4 周一个迭代 |
| 用户反馈 | 项目末期才能获得 | 每个迭代都收集 |
| 文档要求 | 详尽的前期文档 | 够用就好，重视沟通 |
| 变更成本 | 越晚变更成本越高 | 拥抱变化，成本可控 |
| 风险管理 | 风险后期才暴露 | 风险尽早暴露和处理 |
| 团队协作 | 各阶段团队分离 | 跨职能团队紧密协作 |
| 适用场景 | 需求明确、变化少的项目 | 需求不确定、需要快速验证 |
| 典型行业 | 航天、建筑、医疗器械 | 互联网、移动应用、SaaS |
PM 要点：在互联网行业，你遇到的几乎都是敏捷开发。但瀑布思维不是完全没用的——在一些大型项目的前期规划阶段，瀑布式的系统思考仍然有价值。
二、敏捷宣言的四大核心价值观
2001 年，17 位软件开发者在美国犹他州签署了《敏捷软件开发宣言》（Agile Manifesto），提出了四大核心价值观：
┌─────────────────────────────────────────────────────┐
│ │
│ 敏捷宣言四大价值观 │
│ │
│ 个体和互动 > 流程和工具 │
│ │
│ 可工作的软件 > 详尽的文档 │
│ │
│ 客户合作 > 合同谈判 │
│ │
│ 响应变化 > 遵循计划 │
│ │
│ ─────────────────────────────────── │
│ 也就是说，虽然右边的也有价值， │
│ 但我们更重视左边的。 │
│ │
└─────────────────────────────────────────────────────┘逐条解读
| 价值观 | 含义 | PM 实践 |
|---|---|---|
| 个体和互动 > 流程和工具 | 人是最重要的，面对面沟通胜过工具传话 | 遇到问题先找人聊，而不是发邮件等回复 |
| 可工作的软件 > 详尽的文档 | 能跑的产品比100页文档更有说服力 | PRD 够用就好，快速出原型验证 |
| 客户合作 > 合同谈判 | 与客户/用户建立持续合作关系 | 和用户保持沟通，而非甲方乙方对立 |
| 响应变化 > 遵循计划 | 需求一定会变，计划也要灵活调整 | 不要死守最初的方案，根据反馈及时调整 |
三、Scrum 框架详解
Scrum 是敏捷开发中最流行的框架，名字来源于橄榄球中的"争球"，强调团队紧密协作。
3.1 三大角色
┌─────────────────────────────────────────────────┐
│ Scrum 三大角色 │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌────────┐ │
│ │ Product │ │ Scrum │ │ Dev │ │
│ │ Owner │ │ Master │ │ Team │ │
│ │ (产品负责人) │ │ (敏捷教练) │ │(开发团队)│ │
│ └──────┬──────┘ └──────┬───────┘ └───┬────┘ │
│ │ │ │ │
│ 决定做什么 保障流程顺畅 执行开发 │
│ 管理 Backlog 移除障碍 自组织 │
│ 定义优先级 引导团队 跨职能 │
│ 代表用户利益 守护 Scrum 规则 对质量负责 │
│ │
└─────────────────────────────────────────────────┘Product Owner（PO / 产品负责人）
- 核心职责：定义产品方向，管理 Product Backlog
- 在国内：通常就是产品经理承担这个角色
- 关键能力：优先级判断、业务理解、用户代言
Scrum Master（SM / 敏捷教练）
- 核心职责：确保团队遵循 Scrum 流程，移除障碍
- 注意：SM 不是"项目经理"，也不是"老板"，而是"服务型领导"
- 关键能力：引导、教练、冲突调解
Development Team（开发团队）
- 核心特点：跨职能、自组织
- 规模建议：3-9 人（太小没有足够技能覆盖，太大沟通成本太高）
- 包含角色：前端、后端、测试、设计师等
3.2 五大事件
| 事件 | 时间 | 参与者 | 目标 |
|---|---|---|---|
| Sprint | 1-4 周（固定） | 全员 | 一个完整的开发迭代周期 |
| Sprint Planning | 2-8 小时 | PO + SM + Dev | 规划本次 Sprint 要做的内容 |
| Daily Standup | 每天 15 分钟 | SM + Dev（PO 可选） | 同步进度、暴露问题 |
| Sprint Review | 1-4 小时 | 全员 + 利益相关者 | 演示成果，收集反馈 |
| Sprint Retro | 1-3 小时 | PO + SM + Dev | 回顾改进，持续优化流程 |
Sprint Planning（冲刺规划会）
Sprint Planning 流程
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ PO 讲解 │ ──► │ 团队讨论 │ ──► │ 确定 Sprint │
│ 优先级 │ │ 拆分任务 │ │ Backlog │
│ 最高的 │ │ 评估工作量 │ │ 制定目标 │
│ 需求 │ │ │ │ │
└──────────┘ └──────────────┘ └──────────────┘
输入：Product Backlog（已排序）
输出：Sprint Backlog + Sprint GoalPM 实操要点：
- 提前准备好需求，确保 Backlog 排好优先级
- 需求描述清晰，减少规划会上的扯皮时间
- 不要承诺过多，留 20% 的 buffer 应对意外
Daily Standup（每日站会）
每人回答三个问题：
- 昨天做了什么？
- 今天计划做什么？
- 遇到了什么障碍？
┌─────────── Daily Standup ─────────────┐
│ │
│ 时间：每天固定时间，15分钟以内 │
│ 形式：站着开（防止拖延） │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 昨天 │ │ 今天 │ │ 障碍 │ │
│ │ 完成了 │ │ 计划做 │ │ 需要 │ │
│ │ 什么？ │ │ 什么？ │ │ 帮助？ │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ 注意：不是汇报会！是同步信息会！ │
│ 详细讨论请会后单独沟通 │
└───────────────────────────────────────┘PM 实操要点：
- 站会不是汇报会，不要让它变成逐个质问进度
- 关注"障碍"栏，这是你需要帮忙解决的
- 如果某个话题讨论超过 2 分钟，记下来会后单聊
Sprint Review（冲刺评审会）
- 团队演示本次 Sprint 完成的功能
- 利益相关者（老板、运营等）参与并给反馈
- 基于反馈调整后续 Backlog 优先级
Sprint Retrospective（冲刺回顾会）
经典问法：
- 做得好的（继续保持）
- 做得不好的（需要改进）
- 下次要尝试的（行动计划）
Sprint Retro 看板
┌──────────────┬──────────────┬──────────────┐
│ 做得好 :) │ 做得不好 :( │ 改进行动 │
├──────────────┼──────────────┼──────────────┤
│ 沟通比上次 │ 需求变更太 │ 需求冻结时间 │
│ 更顺畅 │ 频繁 │ 提前到周三 │
│ │ │ │
│ 提测质量 │ 站会经常 │ 站会设闹钟 │
│ 有提升 │ 超时 │ 严格15分钟 │
│ │ │ │
│ 文档更规范 │ 上线前才 │ 建立 Code │
│ │ 发现 Bug │ Review 机制 │
└──────────────┴──────────────┴──────────────┘3.3 三大工件
三大工件的关系
┌────────────────────────────────────────────┐
│ Product Backlog（产品待办列表） │
│ ┌──────────────────────────────────────┐ │
│ │ 需求A (优先级: 高) │ │
│ │ 需求B (优先级: 高) ──┐ │ │
│ │ 需求C (优先级: 中) ──┤ 被选入本次 │ │
│ │ 需求D (优先级: 中) ──┘ Sprint │ │
│ │ 需求E (优先级: 低) │ │
│ │ 需求F (优先级: 低) │ │
│ │ ... │ │
│ └──────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Sprint Backlog（冲刺待办列表） │
│ ┌──────────────────────────────────────┐ │
│ │ 需求B → 任务1, 任务2, 任务3 │ │
│ │ 需求C → 任务4, 任务5 │ │
│ │ 需求D → 任务6, 任务7, 任务8 │ │
│ └──────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Increment（增量 / 可交付产品） │
│ ┌──────────────────────────────────────┐ │
│ │ 满足 "完成定义(DoD)" 的可工作软件 │ │
│ │ 可以上线或演示给用户 │ │
│ └──────────────────────────────────────┘ │
└────────────────────────────────────────────┘- Product Backlog：产品所有待做事项的有序列表，由 PO 负责维护
- Sprint Backlog：本次 Sprint 要完成的子集 + 具体任务拆分
- Increment：Sprint 结束时交付的可工作软件增量
3.4 Scrum 完整流程图
┌──────────────── Scrum 完整流程 ────────────────────────┐
│ │
│ Product Sprint Sprint 进行中 │
│ Backlog Planning (1-4 周) │
│ │
│ ┌──────┐ ┌──────┐ ┌──────────────────────┐ │
│ │需求列│ │ │ │ │ │
│ │表 │──►│规划会│──►│ 每日站会 (15min) │ │
│ │(PO │ │ │ │ │ │
│ │维护) │ └──────┘ │ Day1 Day2 Day3 .. │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ │ │ ▼ ▼ ▼ │ │
│ │ │ ▼ │ 开发 + 测试 + 集成 │ │
│ │ │ Sprint │ │ │
│ │ │ Backlog └──────────┬───────────┘ │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ ┌───────────┐ │
│ │ │ │ Sprint │ │
│ │ │◄───── 反馈 ───────│ Review │ │
│ │ │ │ 评审会 │ │
│ └──────┘ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ ┌────────────┐ │ Sprint │ │
│ │ 可交付的 │◄───────────│ Retro │ │
│ │ 产品增量 │ │ 回顾会 │ │
│ │(Increment) │ └───────────┘ │
│ └────────────┘ │
│ │
└────────────────────────────────────────────────────────┘四、Sprint 的时间管理
4.1 Sprint 时长选择
| Sprint 时长 | 适用场景 | 优缺点 |
|---|---|---|
| 1 周 | 需求变化极快、初创团队 | 节奏快，但规划会频繁，overhead 大 |
| 2 周 | 最常见，大多数互联网团队 | 平衡了灵活性和效率，推荐新手选用 |
| 3 周 | 较复杂的产品线 | 有足够时间完成较大特性 |
| 4 周 | 企业级软件、变化较少 | 接近小型瀑布，灵活性较差 |
建议：如果你是新手 PM，推荐从 2 周一个 Sprint 开始。
4.2 Sprint 日历示例（2 周）
Week 1 Week 2
Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri
┌────┬────┬────┬────┬────┐ ┌────┬────┬────┬────┬────┐
│规划│开发│开发│开发│开发│ │开发│开发│测试│评审│回顾│
│会 │ │ │ │ │ │ │ │修复│会 │会 │
└────┴────┴────┴────┴────┘ └────┴────┴────┴────┴────┘
▲ ▲
│ │
Sprint 开始 Sprint 结束
每天 15 分钟站会贯穿始终五、用户故事（User Story）
5.1 什么是用户故事？
用户故事是敏捷开发中描述需求的标准格式，它从用户角度出发，描述用户想要什么、为什么想要。
5.2 标准格式
┌─────────────────────────────────────────────┐
│ │
│ As a [角色/用户类型], │
│ I want [功能/行为], │
│ So that [价值/目的]. │
│ │
│ 作为一个 [角色], │
│ 我想要 [功能], │
│ 以便 [价值]。 │
│ │
└─────────────────────────────────────────────┘5.3 用户故事示例
| 用户故事 | 角色 | 功能 | 价值 |
|---|---|---|---|
| 作为一个普通用户，我想要通过手机号注册账号，以便我能使用平台的功能 | 普通用户 | 手机号注册 | 使用平台功能 |
| 作为一个卖家，我想要查看商品的销售数据，以便我能优化运营策略 | 卖家 | 查看销售数据 | 优化运营 |
| 作为一个管理员，我想要批量导出用户数据，以便我能进行数据分析 | 管理员 | 批量导出 | 数据分析 |
5.4 好的用户故事标准（INVEST 原则）
| 原则 | 英文 | 含义 |
|---|---|---|
| I | Independent | 故事之间尽量独立 |
| N | Negotiable | 可以协商细节 |
| V | Valuable | 对用户有价值 |
| E | Estimable | 可以估算工作量 |
| S | Small | 足够小，一个 Sprint 能完成 |
| T | Testable | 有明确的验收标准 |
5.5 验收标准（Acceptance Criteria）
每个用户故事都应该有验收标准，例如：
用户故事：作为一个用户，我想要通过手机号注册
验收标准（AC）：
┌──────────────────────────────────────────────┐
│ AC1: 输入11位有效手机号，点击获取验证码 │
│ -> 60秒内收到6位数字验证码 │
│ │
│ AC2: 输入正确验证码，点击注册 │
│ -> 注册成功，自动登录进入首页 │
│ │
│ AC3: 输入已注册手机号 │
│ -> 提示"该手机号已注册，请直接登录" │
│ │
│ AC4: 验证码输错3次 │
│ -> 锁定5分钟，提示"操作过于频繁" │
└──────────────────────────────────────────────┘六、故事点估算
6.1 什么是故事点？
故事点（Story Point）是一种相对估算方法，不是按"小时"或"天"来估算工作量，而是用一个相对数字来表示任务的复杂度、工作量和不确定性。
6.2 斐波那契数列
常用的故事点取值来自斐波那契数列：
1, 2, 3, 5, 8, 13, 21, ...
┌───┬───┬───┬───┬───┬────┬────┐
│ 1 │ 2 │ 3 │ 5 │ 8 │ 13 │ 21 │
├───┼───┼───┼───┼───┼────┼────┤
│极 │小 │中 │中 │大 │很 │巨 │
│小 │ │小 │等 │ │大 │大 │
└───┴───┴───┴───┴───┴────┴────┘
│ │
简单的文案修改 需要拆分成更小的故事6.3 估算示例
| 用户故事 | 故事点 | 理由 |
|---|---|---|
| 修改按钮颜色 | 1 | 纯前端改动，几行代码 |
| 添加用户头像上传 | 5 | 前后端联调，需要图片处理 |
| 实现第三方登录（微信+支付宝） | 13 | 涉及多个第三方 API，联调复杂 |
| 搭建完整的支付系统 | 21+ | 太大了！需要拆分成多个故事 |
6.4 Planning Poker（计划扑克）
Planning Poker 是最常用的估算方式：
┌───────────── Planning Poker 流程 ─────────────┐
│ │
│ 1. PO 讲解用户故事 │
│ 2. 团队提问、讨论 │
│ 3. 每人同时亮出估算卡片 │
│ 4. 如果数字差异大 -> 讨论 -> 重新投票 │
│ 5. 达成一致 -> 记录故事点 │
│ │
│ 示例： │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ 3 │ │ 5 │ │ 5 │ │ 8 │ │ 5 │ │
│ └───┘ └───┘ └───┘ └───┘ └───┘ │
│ 小明 小红 小刚 小李 小王 │
│ │
│ 小李估8，其他人估3-5 -> 请小李说明理由 │
│ 可能是小李发现了其他人忽略的技术风险 │
└────────────────────────────────────────────────┘七、看板（Kanban）
7.1 什么是看板？
看板（Kanban）源于丰田生产系统，核心思想是可视化工作流程、限制在制品数量（WIP Limit）。
7.2 基础看板
┌──────────────────────────────────────────────────────────────┐
│ 看 板 (Kanban) │
├──────────────┬──────────────┬──────────────┬────────────────┤
│ Backlog │ To Do │ In Progress │ Done │
│ (待办池) │ (本期待做) │ (进行中) │ (已完成) │
│ │ │ WIP Limit:3 │ │
├──────────────┼──────────────┼──────────────┼────────────────┤
│ │ │ │ │
│ ┌──────────┐│ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │
│ │ 需求G ││ │ 需求E │ │ │ 需求B │ │ │ 需求A │ │
│ │ (5 pts) ││ │ (3 pts) │ │ │ [小明] │ │ │ [已上线] │ │
│ └──────────┘│ └──────────┘ │ └──────────┘ │ └──────────┘ │
│ │ │ │ │
│ ┌──────────┐│ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │
│ │ 需求H ││ │ 需求F │ │ │ 需求C │ │ │ ... │ │
│ │ (8 pts) ││ │ (5 pts) │ │ │ [小红] │ │ │ │ │
│ └──────────┘│ └──────────┘ │ └──────────┘ │ └──────────┘ │
│ │ │ │ │
│ ┌──────────┐│ │ ┌──────────┐ │ │
│ │ 需求I ││ │ │ 需求D │ │ │
│ │ (3 pts) ││ │ │ [小刚] │ │ │
│ └──────────┘│ │ └──────────┘ │ │
│ │ │ │ │
└──────────────┴──────────────┴──────────────┴────────────────┘
WIP Limit = 3：进行中的任务不超过3个，避免多任务并行导致效率低下7.3 进阶看板（增加更多列）
┌─────────┬─────────┬──────────┬──────────┬─────────┬────────┐
│ Backlog │ To Do │ Dev │ Testing │ Review │ Done │
│ 待办 │ 待开发 │ 开发中 │ 测试中 │ 评审中 │ 已完成 │
├─────────┼─────────┼──────────┼──────────┼─────────┼────────┤
│ ... │ ... │ ... │ ... │ ... │ ... │
└─────────┴─────────┴──────────┴──────────┴─────────┴────────┘八、Scrum vs Kanban 对比
| 维度 | Scrum | Kanban |
|---|---|---|
| 迭代周期 | 固定周期（Sprint） | 无固定周期，持续流动 |
| 角色 | PO / SM / Dev Team | 无规定角色 |
| 计划 | Sprint Planning 提前规划 | 按需拉取，无需提前规划 |
| 变更 | Sprint 内尽量不变更 | 随时可以调整优先级 |
| 度量 | 速率（Velocity） | 前置时间（Lead Time） |
| 会议 | 有固定的5个事件 | 无固定会议要求 |
| 适用场景 | 需求相对可预测的产品开发 | 需求频繁变化的运维/支持 |
| 学习曲线 | 较高，规则较多 | 较低，容易上手 |
| WIP 限制 | 通过 Sprint 容量间接限制 | 显式限制在制品数量 |
如何选择？
┌─────────────────────────────────────────────┐
│ 选择 Scrum 还是 Kanban？ │
│ │
│ 需求是否可预测？ │
│ │ │
│ ┌──┴──┐ │
│ ▼ ▼ │
│ 是 否 │
│ │ │ │
│ │ 团队是否经常处理紧急任务？ │
│ │ │ │
│ │ ┌──┴──┐ │
│ │ ▼ ▼ │
│ │ 是 否 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Scrum Kanban 可以先试 Scrum │
│ 不适应再转 Kanban │
└─────────────────────────────────────────────┘实际中：很多团队会把 Scrum 和 Kanban 结合起来使用（称为 Scrumban），取两者之长。比如保持 Sprint 的节奏，但在看板上可视化工作流。
本节小结
| 知识点 | 关键要记住的 |
|---|---|
| 瀑布 vs 敏捷 | 互联网行业几乎都用敏捷 |
| 敏捷宣言 | 四大价值观：个体互动、可工作软件、客户合作、响应变化 |
| Scrum 角色 | PO（产品负责人）、SM（敏捷教练）、Dev Team（开发团队） |
| Scrum 事件 | 5 个事件保证团队节奏 |
| Scrum 工件 | Product Backlog → Sprint Backlog → Increment |
| 用户故事 | As a..., I want..., So that... |
| 故事点 | 斐波那契数列，相对估算 |
| 看板 | 可视化工作流 + WIP 限制 |
| Scrum vs Kanban | 按团队特点选择，也可以结合使用 |