敏捷与Scrum，到底有什么区别？——开发团队实用基础指南

前言

本文将整理敏捷与Scrum的关系，并总结在实际工作中所需的最基本知识。适合即将加入团队的人，或希望更新自学知识的人。

什么是敏捷？

一句话概括

敏捷（Agile）不是一种具体方法论，而是软件开发的"思维方式"和"价值观"。其起点是2001年17位软件开发者聚集发布的"敏捷软件开发宣言（Agile Manifesto）"。

四大价值观

敏捷宣言中表达为：相比左侧，更重视右侧的价值。

需要注意的是，这并非说"左侧没有价值"。两者都有价值，但更重视右侧——这才是敏捷的立场。

12条原则（摘录）

宣言背后有12条原则。不需要全部记住，但以下三条最为常见：

1. 最高优先级是通过尽早、持续地交付有价值的软件来满足客户需求。
2. 欢迎对需求提出变更，即使是在开发后期。
3. 频繁地交付可工作的软件，周期从几周到几个月不等，越短越好。

"以短周期交付可工作的软件"、"欢迎变化"——这两点可以说是敏捷的核心。

什么是Scrum？

与敏捷的关系

这是最容易混淆的地方。用图示来表示如下：

敏捷（思维方式/价值观）
├── Scrum（框架）← 最广泛使用
├── XP（极限编程）
├── 看板（Kanban）
└── 其他...

也就是说，Scrum是实践敏捷的具体框架之一。敏捷 ≠ Scrum，正确的关系是 Scrum ⊂ 敏捷。

Scrum的3-5-3

Scrum由"3个职责（Accountabilities）、5个事件、3个制品"构成。2020年版中，原有的"角色"一词改为"职责"，每个制品也新增了承诺（产品待办列表→产品目标，Sprint待办列表→Sprint目标，增量→完成的定义）。

3个职责

• 产品负责人（PO）：负责最大化产品价值。决定构建什么内容的优先级。
• Scrum Master（SM）：支持Scrum正确运行。是团队的教练，负责消除障碍。
• 开发者（Developers）：实际构建产品的人。包括工程师、设计师、QA等。

5个事件

3个制品

• 产品待办列表（Product Backlog）：按优先级排列的所有待办事项列表。由PO管理。
• Sprint待办列表（Sprint Backlog）：本Sprint要做的工作列表。由开发者管理。
• 增量（Increment）：Sprint中完成的可工作产品。

Sprint的循环

[计划] → [开发 + 每日站会 × N天] → [评审] → [回顾] → 下一个Sprint

在固定时间内重复这个循环是Scrum的基本节奏。

通过具体案例深入理解Scrum

接下来，以虚构产品为例，深入了解仅靠抽象说明难以理解的部分。

深入了解职责

产品负责人（PO）——王芳的一天

PO的工作常被简单描述为"决定优先级"，但实际上要复杂得多。FitLog团队PO王芳的典型日常是这样的：

• 上午：查看近期发布的使用数据，找出跳出率高的页面。整理客服团队反馈的需求。
• 下午：与利益相关者（市场、管理层）开会，对齐Q3业务目标与产品目标。
• 随时：立即回复开发者的询问，如"这个功能，换这种实现方式会轻一些，您觉得怎么样？"
• 每周：梳理待办列表，细化高优先级条目的验收条件。

关键点在于，PO同时承担"用户价值"和"商业价值"两个维度。为了判断"功能A和功能B，哪个先做？"，需要兼顾用户研究、数据分析和管理层会议。

Scrum Master（SM）——李明的干预示例

SM常被认为是"会议主持人"，但其本质是引导团队自律的教练。FitLog团队SM李明实际做的事情如下：

• 在每日站会中发现开发者A每天都说"昨天还是在查这个Bug"，于是私下1对1问道："遇到困难了吗？需要帮助吗？"
• 观察到PO与开发者之间在"需求理解"上每次都有偏差，在回顾会上将这个问题提上议程。
• 阻止其他部门直接向开发者发出"紧急支援请求！"，重申"请求须通过PO"的规则。
• 当团队逐渐熟悉后，提议审视Scrum事件的形式（例如：改变每日站会的形式）。

SM是一个看似什么都没做，实际上却在持续整备团队环境的角色。"最近SM看起来很闲"，有时恰恰是团队开始自律运转的好兆头。

开发者——"自管理"意味着什么？

2020年版Scrum指南中，整个Scrum团队被定义为自管理型（self-managing）。具体到开发者的自管理，体现在以下几个方面：

• Sprint中"做什么"与PO商量决定，但"怎么做"由开发者决定。
• 任务不是从上面分配下来的，而是由开发者自己认领。
• 估算由开发者进行（不是PO或上司）。
• 维护质量标准（完成的定义）是开发者的责任。

当iOS开发者张伟发现"这个API响应慢，用户体验差"时，直接找后端开发者杨帆商量改进——这种横向协作自然发生的团队，就是健康的Scrum团队。

深入了解事件

Sprint计划会——实际进行流程示例

FitLog团队的2周Sprint计划会大致如下进行（用时约4小时）。

第1部分：为什么这个Sprint有价值？（设定Sprint目标）

PO王芳："我希望本Sprint的目标是'让用户能够通过图表查看过去30天的训练进展'。上个月的调研发现，留存率高的用户更多地使用了图表功能。"

Sprint目标的关键是用要实现的状态来表达，而不是功能列表。

第2部分：本Sprint能做什么？（选择待办列表条目）

针对PO提出的高优先级条目，开发者通过计划扑克进行估算，选择在自己产能范围内的工作量。

第3部分：如何完成选定的工作？（任务拆解）

开发者将选定的待办条目拆解为具体任务。

开发者张伟："拆解'图表展示界面'这个条目，得到4个任务：API设计、iOS实现、Android实现、E2E测试。不完成API设计就无法并行，所以第一天专注让杨帆来做。"

每日站会——好与坏的对比

❌ 不好的每日站会（变成汇报会）

"昨天做了API实现。今天写测试。没有问题。"
"我在推进界面实现。今天继续。"
……（15分钟单调地进行下去）

这只是进度汇报，并非检查与适应。

✅ 好的每日站会（检查与适应）

开发者张伟："图表渲染库比预期要重。为了达成Sprint目标，我想考虑切换到其他库。计划会后需要2小时做进一步调查。"
开发者杨帆："那我可以把API实现提前一天，然后来支援你。"
开发者张伟："那我们这之后30分钟两人一起确认细节吧。"

每日站会的本质是针对Sprint目标重新规划今天如何行动的场合。

Sprint评审会——不只是演示

评审会常见的误解是"演示可工作的产品就结束了"。真正的评审会是邀请利益相关者参与的对话场合。

• 开发者演示可工作的增量
• 利益相关者试用并给出反馈
• 分享外部信息，如"市场情况发生了变化"、"目标用户的反应与预期不同"
• 以此为基础调整产品待办列表，为下一步做准备

也就是说，评审会不仅是"对过去的检查"，也是"对未来计划的输入"。

Sprint回顾会——避免流于形式的技巧

回顾会常被认为是"用KPT（Keep/Problem/Try）进行"，但任何形式都可以。根据团队情况变换形式是有效的，但那只是手段，不是目的。

FitLog团队尝试的变体：

并且将Try严格限定为一个，在下个Sprint开始时就着手。"全都要做"等同于什么都不做。

深入了解制品

产品待办列表——合适的条目粒度

产品待办列表条目（PBI）常以用户故事格式编写：

作为[什么类型的用户]
我想要[做什么]
这样[为什么这样做]

FitLog的好PBI示例：

标题：展示过去30天的训练进展图表

作为一个坚持慢跑的用户，我想看过去30天跑步距离的趋势图，因为我想通过可视化自己的努力来保持动力。

验收条件：

• 主页面新增"进展"标签
• 以折线图显示过去30天每日跑步距离
• 数据为0的日期在图表上显示为空白
• 点击图表跳转至该日的详情页面

❌ 不好的PBI示例："实现图表功能" ← 不清楚是为谁、为什么做

PBI最好满足INVEST原则（Independent独立/Negotiable可协商/Valuable有价值/Estimable可估算/Small小/Testable可测试）。

Sprint待办列表——与产品目标的连接

Sprint待办列表不是"任务清单"，而是由三个要素构成的计划：

1. Sprint目标（为什么）：本Sprint要实现的状态
2. 选定的PBI（做什么）：从产品待办列表中选出的条目
3. 执行计划（怎么做）：任务拆解与推进方式

Sprint目标：让用户能够通过图表查看过去30天的训练进展
├─ PBI 1：进展图表展示界面 [8 pt]
│   ├─ Task：API端点设计
│   ├─ Task：iOS实现
│   ├─ Task：Android实现
│   └─ Task：E2E测试
├─ PBI 2：点击图表跳转详情 [3 pt]
│   └─ ...
└─ PBI 3：无数据时的展示优化 [2 pt]
    └─ ...

增量——"完成的定义（DoD）"

增量被描述为"可工作的产品"，但以什么为完成需要团队明确定义。这就是完成的定义（Definition of Done, DoD）。

FitLog团队的DoD示例：

• 代码评审获得2人以上Approve
• 单元测试覆盖率80%以上
• E2E测试通过
• 无障碍检查完成（VoiceOver / TalkBack）
• PM确认验收条件并OK
• 创建发布说明草稿

未满足DoD的内容视为"未完成"，顺延至下个Sprint。完成5个100%完成的功能，胜过积累10个80%完成的功能——这是Scrum的思维方式。

速度（Velocity）——衡量团队的"节奏"

读到这里，你可能会疑惑："PBI旁边的[8 pt]是什么？"这就引出了Scrum实务运营中重要的速度（Velocity） 话题。

定义

速度是团队每个Sprint完成的待办条目规模的总和。通常定义如下：

速度 = 本Sprint中满足完成定义的PBI故事点合计

重要的是：

• 只计算已完成的PBI（完成了八成 = 计为0）
• 单位通常为故事点（SP）（不是小时）
• 以Sprint为单位计量，常取多个Sprint的移动平均

什么是故事点？

故事点是表示工作相对大小的单位。不是"人天"或"小时"这样的绝对值，而是与基准任务相比"大概有多大"的相对比较估算。

常用的是斐波那契数列（1, 2, 3, 5, 8, 13, 21...）。数字越大间隔越宽，反映了"任务越大，不确定性越高，细分区别意义不大"的思想。

FitLog团队的估算基准示例：

具体示例：FitLog团队的速度变化

来看FitLog团队近6个Sprint的实绩：

Sprint 1: 18 pt（已完成PBI: 5 + 5 + 3 + 3 + 2）
Sprint 2: 22 pt（已完成PBI: 8 + 5 + 5 + 2 + 2）
Sprint 3: 25 pt（已完成PBI: 8 + 8 + 5 + 3 + 1）
Sprint 4: 23 pt
Sprint 5: 26 pt
Sprint 6: 24 pt
─────────────────────
近3个Sprint平均：24.3 pt ← 当前速度

可以看出，这个团队每个Sprint能处理约24点的工作量。

速度的用途

速度稳定后，可以有以下用法：

1. 把握Sprint计划会的产能

PO王芳："下个Sprint的候选PBI合计32点。"
开发者张伟："近期平均24点，现实上承接排名靠前的26点（8+8+5+3+2）比较合适。"

不是"靠干劲撑过去"，而是能基于实绩达成共识，这是很大的价值。

2. 预测发布计划

产品待办列表整体180点，速度24点，则剩余180 ÷ 24 ≈ 7.5个Sprint可完成的预测就可以建立起来。

有了这个，就能有理有据地向利益相关者解释"大约Q3末能发布"。

3. 持续改进估算精度

当能看到"预估5点，实际花了10点力气"这样的偏差时，就成为回顾会的讨论素材。

常见反模式

速度虽然方便，但若使用不当，会毁掉团队。

❌ 反模式1：将速度设为KPI

"本月速度必须高于上月"、"比其他团队低就是在偷懒"——这是最糟糕的用法。

速度是各团队特有的相对值，跨团队比较毫无意义。而且对团队施压"提升速度"，团队只会虚报估算，实际生产力不变（甚至会下降）。

❌ 反模式2：故事点 = 时间

固定使用"1点 = 4小时"后，故事点就失去了意义。相对估算的优点（表达不确定性、提高讨论效率）消失，退化为单纯的工时估算。

❌ 反模式3：对未完成PBI计算部分得分

"8点的PBI完成了七成，就计为5.6点"——这是不可以的。未满足完成定义的PBI计为0点是原则。

原因：速度是用于预测"下个Sprint能完成多少"的指标。将进行中的工作计入会导致预测偏差。

❌ 反模式4：相信团队变动后的速度

成员增减或技术栈变化后，速度会重置。建立新体制后，需先跑3~4个Sprint，再重新计算平均值。

不使用速度的选项

近年来，越来越多的团队选择"不追求速度"。替代指标有：

• 吞吐量（Throughput）：完成的PBI数量（不赋予点数，统一PBI粒度后只数数量）
• 周期时间（Cycle Time）：PBI从开始到完成所花的时间
• 前置时间（Lead Time）：PBI从创建到完成所花的时间

特别是与看板结合使用，或对于希望降低估算成本的成熟团队，这些指标往往更有效。

必须掌握的术语表

Scrum/敏捷有很多独特术语，掌握与否对团队内的沟通效率影响很大。结合实例深入了解。

计划扑克（Planning Poker）

做什么

计划扑克是团队全员为PBI估算故事点的手法。不是由一位经验丰富的工程师决定"这是5点"，而是全体成员同时亮牌，共同达成共识。

为什么要用"扑克"形式？

为了防止"锚定效应"——被声音最大或经验最丰富的人的意见所左右。如果有人先说"这是8点吧？"，其他成员就很难说"我觉得是3"。全员同时亮牌就是为了防止这种情况。

进行方式（FitLog团队示例）

牌使用斐波那契数列（0, 1, 2, 3, 5, 8, 13, 21, ?, ☕）。"?"表示不知道，"☕"表示需要休息。

第1步：说明PBI

PO王芳："下一个是'通过推送通知发送提醒'。如果用户设定了时间但当天没有训练记录，就发送通知。"

第2步：提问与解答

开发者张伟："通知的文案可以自定义吗？"
PO王芳："不，固定文案就可以。"
开发者杨帆："服务器端的通知基础设施是用现有的吗？"
PO王芳："是的，前提是使用现有基础设施。"

第3步：全员同时亮牌

第4步：请最高分和最低分的人说明理由

最低分杨帆："后端只是在现有通知基础设施上增加调用，所以是3。"
最高分赵磊："Android端需要实现3件事：保存用户设置、定时任务、通知处理。上次做类似的事情费了不少力气，所以给了13。"

第5步：讨论后重新投票

讨论后，所有人收敛到"8"附近。最终8点达成共识。

注意点

• 不要急于投票：在提问解答对齐前提后再亮牌
• 不要责怪出牌不同的人：差异源于信息不同，分享信息才是目的
• 不要花太多时间：每个PBI目标5~10分钟。无法决定的PBI退回梳理

待办列表梳理（Refinement）

做什么

梳理是持续维护产品待办列表的活动。具体包括：

• 拆分过大的PBI
• 具体化高优先级PBI的验收条件
• 删除过时的PBI
• 进行估算（常作为计划扑克的场合使用）

何时进行

Scrum指南未将其定义为独立事件，但多数团队会每周安排1~2小时的专用时间。多数团队安排在Sprint中间左右。

就绪的定义（Definition of Ready）

实务中有时与DoD对比讨论的概念是就绪的定义（Definition of Ready）。其思路是：PBI通过梳理达到Ready状态后，才能带入计划会。

FitLog团队的Ready定义示例：

• 以用户故事格式编写
• 有3个以上验收条件
• 团队所有成员理解内容
• 已拆分至8点以下
• 如有外部依赖，已与相关方确认

INVEST原则（深入了解）

好的PBI应满足的6个特性。各自举例说明。

用户故事的层级——主题、Epic、Story、Task

产品待办列表是一维列表，但实务中常用4层结构来思考。

主题（Theme）：提升用户参与度
└─ Epic：促进训练坚持的机制
   ├─ 用户故事：能通过图表查看过去30天的进展 [8 pt]
   │  ├─ Task：API实现
   │  ├─ Task：iOS UI实现
   │  └─ Task：Android UI实现
   ├─ 用户故事：能接收提醒通知 [8 pt]
   └─ 用户故事：展示连续记录天数 [3 pt]

出现在待办列表中的PBI主要是Epic和用户故事。

燃尽图 / 燃起图

燃尽图（Burndown Chart）

可视化Sprint中剩余工作进展的图表。观察实际进度相对于理想线（均匀减少的线）的变化。

剩余pt
24┤●
22┤  ●
20┤    ●─ 理想线 ────
18┤      ╲╲
16┤        ●（实际，略有延迟）
14┤          ●
12┤            ╲
 0┤──────────────●
    Day1 Day3 Day5 Day7 Day10

实际线一直高于理想线 → Sprint目标完成危险的信号。考虑尽早应对（缩减范围、请求支援）。

燃起图（Burnup Chart）

将完成量和范围分别用不同线条展示的图表。当范围变化时，比燃尽图更容易看清情况，因此常用于追踪发布计划。

MVP与MMP

MVP（最小可行产品）

验证假设所需的最小产品。Eric Ries的《精益创业》使这一概念广为人知。

FitLog的MVP示例："用户打开应用，手动记录跑步距离，能查看过去记录的列表。"没有图表、通知和社交功能。用这个来验证"人们会为训练记录应用付费吗？"这一假设。

MMP（最小可销售产品）

能在市场上销售的最小产品。比MVP更丰富一层。MVP面向内部/限定用户，MMP面向一般公众，大致是这样的形象。

时间盒（Timebox）

Scrum事件有最长时间限制，这就是时间盒。

时间盒的效果：

• 防止讨论发散：时间有限，迫使集中于本质
• 防止会议膨胀：允许延长就会无限延长
• 提前结束也可以：达成目的后缩短也没问题

Spike

为技术调研或消除不确定性而进行的有时间盒限制的工作。源自XP但在Scrum中也广泛使用。

应使用的场景：

• "不清楚能否用新库实现这一功能" → 设1天时间盒验证
• "搞不清楚现有代码这部分的重构成本" → 半天调研
• "不清楚API响应速度是否满足要求" → 制作原型

Spike的成果是知识，而非代码。为验证而写的代码基本上会被丢弃。

WIP限制（在制品限制）

限制同时进行工作数量的规则。源自看板，但在Scrum团队中的采用也在增加。

示例："In Progress列同时最多3个"

效果：

• 专注于完成：将3个完成比半途推进5个更能产生价值
• 瓶颈变得可见：堵塞的地方变得明确
• 减少多任务的成本：上下文切换会大幅降低生产力

技术债（Technical Debt）

Ward Cunningham提出的概念，用债务比喻因走捷径牺牲未来可维护性而在后期需要支付利息（额外成本）的状态。

种类：

• 有意为之的债务：明知"以deadline优先粗糙实现，之后再重构"而产生
• 无意为之的债务：因知识不足或设计失误而产生
• 环境性债务：随周边技术老化而相对产生（遗留化）

其他需要了解的术语

常见误解与陷阱

"不写文档"是错误的

曲解敏捷宣言的"可工作的软件胜于详尽的文档"，有些团队零文档冲刺。正确的理解是写运行所需的必要文档。

"不做计划"也是错误的

以"响应变化"为由放弃计划也是不对的。Scrum有多层计划（产品目标、Sprint目标、每日计划）。不是不做计划，而是自适应地计划，这才是敏捷。

每日站会变成"汇报会"

变成向PM或管理层汇报进度的每日站会，已经失去了其本来目的。每日站会是开发者的、由开发者进行的检查与适应的场合。

Sprint时长频繁变化

"这次比较忙，改为3周"、"下次试试1周"这样的变化，会导致速度（团队节奏）无法计量。Sprint时长必须固定。

敏捷/Scrum不适用的情形

它并非万能。在以下情况下，可能其他方法更为适合：

• 需求完全固定，几乎不会发生变更（例如：法规合规）
• 安全性极为重要，不允许分阶段发布的领域
• 团队规模极大，协调成本更高的情况

但由于大规模Scrum（LeSS、SAFe等）的扩展方法也存在，"规模大就不行"的结论下得过于草率。

总结

• 敏捷是思维方式和价值观。核心是"以短周期交付可工作的软件"和"欢迎变化"
• Scrum是实践敏捷的代表性框架
• Scrum由"3个职责、5个事件、3个制品"构成，重复固定时长的Sprint
• 只模仿形式会流于形式。先理解价值观，再运用框架

目的不是"做Scrum"，而是"持续交付有价值的产品"。将框架视为达成目的的工具，我认为这是长久相处的秘诀。

参考文献

• 敏捷软件开发宣言
• Scrum指南 2020
• Jeff Sutherland《Scrum：用一半的时间做两倍的事》