敏捷开发落地实战：Scrum vs Kanban 选型与混合实践

郑天祺2026/7/3大约 6 分钟

敏捷开发落地实战：Scrum vs Kanban 选型与混合实践

Scrum 和 Kanban 都是敏捷方法，但适用场景截然不同。强行套用只会水土不服。本文从核心差异到选型决策，从落地实践到混合模式，帮你找到适合团队的敏捷之路。

一、Scrum 与 Kanban 核心差异

1.1 对比矩阵

              Scrum                    Kanban
──────────────────────────────────────────────────────
节奏          固定 Sprint（1-4周）       持续流动（无固定迭代）
计划          Sprint Planning            按需拉取
承诺          Sprint 承诺范围             无承诺，持续交付
角色          SM / PO / Dev Team         无强制角色
仪式          站会/评审/回顾              站会（可选）
变更          Sprint 内不变              随时可变
限制          限制范围（Sprint 容量）      限制 WIP（在制品数）
度量          Velocity（故事点/迭代）     Lead Time（端到端时间）
适用          需求相对明确                需求随机到达
              产品开发                    运维/支持/持续交付

1.2 流程对比

Scrum 流程：

  ┌─────┐   ┌──────────┐   ┌─────────┐   ┌──────┐
  │Backlog│→│Sprint Plan│→│ Sprint  │→│ 评审  │→ 回顾 → 下一个Sprint
  │      │   │           │ │ (2周)   │ │      │
  └─────┘   └──────────┘   └─────────┘ └──────┘
                              │
                          每日站会

Kanban 流程：

  ┌──────┐   ┌──────┐   ┌──────┐   ┌──────┐   ┌──────┐
  │ Backlog │→│ To Do │→│Doing │→│ Done │→│ Live │
  │         │ │ (3)   ││ (2)  ││ (2) ││      │
  └─────────┘ └───────┘└──────┘└──────┘ └──────┘
              ↑ WIP=3  ↑ WIP=2 ↑ WIP=2
              
  持续流动，拉取制，WIP 限制

二、Scrum 落地

2.1 Sprint 规划

Sprint Planning 流程：

  1. 确认 Sprint 容量
     - 团队 5 人，Sprint 2 周 = 10 人天/人
     - 扣除会议/休假/支持 = 7 人天/人
     - 可用容量 = 5 × 7 = 35 人天

  2. 从 Backlog 拉取故事
     按优先级从高到低拉取，直到填满容量

     故事          故事点    累计
     US-001 登录    5        5
     US-002 注册    3        8
     US-003 商品列表 8       16
     US-004 搜索    5        21
     US-005 购物车  8        29
     US-006 订单    5        34  ← 接近容量，停止

  3. 确认 Sprint Goal
     "本 Sprint 完成用户从注册到下单的完整流程"

  4. 任务拆分
     每个 US 拆成子任务（≤ 1 人天）
     US-001 登录：
       - 设计登录接口 (0.5d)
       - 实现后端逻辑 (1d)
       - 前端页面 (1d)
       - 单元测试 (0.5d)
       - 联调 (0.5d)

2.2 故事点估算

故事点估算方法：

  Planning Poker（计划扑克）：

  规则：
    1. 每人一副扑克牌：1, 2, 3, 5, 8, 13, 21, ?
    2. 主持人读出故事
    3. 每人选择一张牌（不展示）
    4. 同时翻牌
    5. 最高和最低解释理由
    6. 再投一轮
    7. 收敛后取众数

  斐波那契数列的含义：
    1  = 非常简单（改文案）
    2  = 简单（加字段）
    3  = 适中（新接口）
    5  = 中等（新功能模块）
    8  = 复杂（涉及多个系统）
    13 = 很复杂（架构调整）
    21 = 拆分！不要做这么大的故事
    ?  = 不确定，需要讨论

  Velocity 计算：
    Sprint 1: 28 点
    Sprint 2: 32 点
    Sprint 3: 30 点
    Sprint 4: 35 点
    平均 Velocity: 31 点 → 下个 Sprint 计划约 31 点

2.3 Scrum 仪式

四大仪式：

  1. Sprint Planning（2-4h）
     目标：确定本 Sprint 做什么和怎么做
     参与：PO + Dev Team + SM
     产出：Sprint Backlog + Sprint Goal

  2. Daily Standup（15min）
     目标：同步进度，暴露风险
     每人回答三个问题：
       - 昨天做了什么？
       - 今天计划做什么？
       - 有什么阻碍？
     ⚠️ 不是汇报会！不讨论解决方案（线下讨论）

  3. Sprint Review（1-2h）
     目标：展示成果，获取反馈
     参与：PO + Dev Team + 利益相关者
     产出：已完成的故事 Demo + 反馈记录

  4. Sprint Retrospective（1h）
     目标：持续改进
     三问题：
       - 做得好的（继续做）
       - 做得不好的（停止做）
       - 可以改进的（开始做）
     产出：1-3 个改进 Action Items

三、Kanban 落地

3.1 看板设计

Kanban 看板示例：

  ┌─────────┬─────────┬─────────┬─────────┬─────────┐
  │ Backlog │ To Do   │ In      │ Review  │ Done    │
  │         │         │Progress │         │         │
  │  (无限)  │ (WIP=3) │ (WIP=2) │ (WIP=2) │ (无限)   │
  ├─────────┼─────────┼─────────┼─────────┼─────────┤
  │ BUG-045 │ TASK-12 │ TASK-08 │ TASK-05 │ TASK-01 │
  │ BUG-046 │ TASK-13 │ TASK-09 │ TASK-06 │ TASK-02 │
  │ TASK-15 │ TASK-14 │         │         │ TASK-03 │
  │ TASK-16 │         │         │         │ TASK-04 │
  │         │         │         │         │ TASK-07 │
  └─────────┴─────────┴─────────┴─────────┴─────────┘
  
  规则：
    1. WIP 超限时不能拉新任务（必须先完成现有的）
    2. 从右向左拉取（Done ← Review ← Progress ← To Do ← Backlog）
    3. 阻塞的任务标注红色旗帜
    4. 每天更新看板

WIP 限制设定原则：
    - 太低：团队空闲，产能浪费
    - 太高：并行太多，上下文切换成本高
    - 经验值：每人 1-2 个并行任务
    - 5 人团队：WIP = 5-10

3.2 度量指标

Kanban 核心指标：

  1. Lead Time（端到端时间）
     从进入 Backlog 到 Done 的总时间
     目标：越短越好

  2. Cycle Time（开发周期）
     从进入 In Progress 到 Done 的时间
     目标：越短越好

  3. Throughput（吞吐量）
     单位时间完成的任务数
     如：每周完成 15 个任务

  4. WIP（在制品数）
     当前正在进行中的任务数
     控制 WIP → 缩短 Lead Time

  Lead Time 分布图（累计流图）：

  天数
  20 │              ╱─────
  15 │          ╱───╱
  10 │      ╱──╱
   5 │  ╱──╱
   1 ──╱
     └───────────→ 任务数
     1  10  20  30  40

  85% 的任务在 10 天内完成
  P50（中位数）= 5 天
  P85 = 10 天
  → 用 P85 做交付承诺（85% 概率按时）

四、Scrumban 混合模式

4.1 适用场景

Scrumban 适用场景：

  1. 产品开发 + 运维支持混合团队
     Scrum 管 Sprint 计划
     Kanban 管 Bug 和紧急任务

  2. 需求半明确的项目
     大方向用 Scrum 规划
     日常用 Kanban 拉取

  3. 从 Scrum 向 Kanban 过渡
     保留 Scrum 的回顾和改进
     去掉 Sprint 时间盒

实践方式：

  ┌──────────────────────────────────┐
  │  Sprint 容量（70%）                │
  │  - 计划的功能开发                  │
  │  - Sprint Planning + 回顾          │
  ├──────────────────────────────────┤
  │  Kanban 缓冲（30%）                │
  │  - Bug 修复                        │
  │  - 紧急需求                        │
  │  - 技术债                          │
  │  - WIP 限制                        │
  └──────────────────────────────────┘

  紧急任务处理：
    正常 Sprint 任务不动
    从 Kanban 缓冲区处理
    如果缓冲区满了 → 暂停 1 个 Sprint 任务

五、面试要点

Q：Scrum 和 Kanban 怎么选？

选 Scrum：需求相对明确、产品开发类、团队可以承诺 2 周迭代、有 PO 角色配合
选 Kanban：需求随机到达（运维/支持）、任务大小不一、无法固定迭代周期、持续交付
选 Scrumban：既有计划性功能开发又有随机任务（Bug/支持）的团队

Q：故事点和人天有什么区别？

故事点：相对复杂度估算（斐波那契数列），包含工作量+复杂度+不确定性，团队统一标准。人天：绝对时间估算。故事点更好：不与具体人绑定（5 人团队 5 点 = 1 人 1 天但可能 1 人 3 天），Velocity 自动校准（团队效率变化会反映在 Velocity 上），避免「为什么估 3 天实际用了 5 天」的追责。

Q：站会变成汇报会怎么办？

严格控制 15 分钟
只回答三个问题（做了什么/计划什么/有什么阻碍）
讨论问题标记后线下沟通
SM 负责引导，防止发散
站着开（物理提示：这是简短同步）

六、总结

Scrum：固定迭代 + 承诺 + 仪式 → 产品开发
Kanban：持续流动 + WIP 限制 + Lead Time → 运维/支持
Scrumban：Sprint 容量 70% + Kanban 缓冲 30% → 混合团队

Scrum 核心：Sprint Planning / 站会 / 评审 / 回顾 / Velocity
Kanban 核心：看板 / WIP 限制 / Lead Time / Throughput

选型原则：
  需求明确 → Scrum
  需求随机 → Kanban
  混合场景 → Scrumban
  不用纠结「纯不纯」，适合团队最重要