Scrum框架入门指南
# Scrum 框架入门指南
角色/仪式/工件、Sprint节奏——Scrum 三个角色的真实协作
# 一、Scrum 三个角色——不是职称，是职责
Product Owner（PO） → 决定"做什么"——对产品价值负责
Scrum Master（SM） → 保证"流程顺畅"——对团队效能负责
Development Team → 决定"怎么做"——对交付质量负责
1
2
3
2
3
角色之间不是上下级。PO 不能命令开发团队"必须怎么做"，开发团队不能拒绝 PO "我们不做"。三方互相制约又互相依赖。
# 工程师在这个三角里的真实处境
PO 说："这个 Sprint 必须做完这 5 个功能。"
开发团队说："做不完，顶多做 3 个。"
SM 说："我们来讨论——哪 3 个对 Sprint Goal 最重要？"
→ 这不是争吵，这是 Scrum 的正常运转。
→ 如果每次都是 PO 赢了——Scrum 形同虚设，变成了需求压榨。
→ 如果每次都是开发团队赢了——PO 没有在推动价值交付。
1
2
3
4
5
6
7
2
3
4
5
6
7
# 二、Sprint 的完整节奏——两周一个循环
# 2.1 两周 Sprint 的真实日历
第 1 天（周一）：
上午：Sprint Planning（2 小时）——定 Goal + 拆任务 + 估点
下午：开始开发
第 2-8 天（周二～下周一）：
每天 15 分钟站会
持续开发 + 随时测试
第 9 天（周二）：
上午：Sprint Review（1 小时）——给 PO 和 stakeholders 演示本 Sprint 完成的功能
下午：修 Review 中发现的小问题
第 10 天（周三）：
上午：Retro（回顾会，1 小时）
下午：缓冲时间——修 bug / 还技术债 / 准备下个 Sprint
第 11 天（周四）：
下一个 Sprint 开始
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 2.2 Story Point 估算——不懂别瞎估
Story Point 是最被滥用也最被误解的 Scrum 工件。
❌ "1 个 Story Point = 1 天"
→ 如果是这样，为什么不直接用"人天"？
→ Story Point 衡量的是"复杂度 + 不确定性 + 工作量"的综合体，不是时间
✅ 正确用法：先找一个最简单的 story 作为基准 = 1 点
然后其他所有 story 跟这个对比："这个比基准复杂多少？"
例：
改一个文案 = 1 点（基准）
加一个字段 = 2 点（差不多，但需要前后端）
做一个新页面 = 5 点（明显复杂很多）
设计一个支付流程 = 13 点（不确定性很大，拆了再估）
关键：13 点以上的 story 必须拆，说明你还没想清楚。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
你为什么需要估算：不是让 PO 拿来压工时——是让团队知道"我们的 Sprint 容量大概多少"。三个 Sprint 后，你就知道团队平均能消化 20 点还是 30 点——下个 Sprint 就不会超载。
# 三、Scrum 三大工件
Product Backlog → PO 维护。所有想做的功能排优先级，按需调整
Sprint Backlog → 开发团队维护。本 Sprint 承诺交付的 story
Increment → 每个 Sprint 结束时的"可交付产品增量"
1
2
3
2
3
# 工程师最需要关注的是 Sprint Backlog
你的 Sprint Backlog 应该满足三个条件：
1. 每一个 story 都有 "完成" 的标准（DoD, Definition of Done）
例："用户能用手机号注册"的 DoD：
□ 前后端代码合入 master
□ 单元测试 + 集成测试通过
□ 在 staging 环境手动验证通过
□ 异常路径（重复注册/错误手机号）有对应处理
→ DoD 不写清楚，Sprint 结束时你说"做完了"，PO 说"这也能叫做完？"
2. 每一个 story 都有人认领（不要"大家共同负责"——等于没人负责）
3. 每日进度可见——燃尽图不是给 SM 看的，是给你自己看的：
第 5 天如果燃尽线和标准线比偏高——说明进度慢了，要么砍 scope 要么找人帮忙
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
# 四、Scrum 最常见的死亡方式
# 4.1 SM 变成了"秘书"
SM 帮你订会议室、记会议纪要、催你更新 Jira——
这不是 SM 该做的事。SM 的核心职责是消除流程障碍。
真正的 SM 在做的事：
"每次部署到 staging 要 20 分钟——我找运维聊把流程自动化了。"
"隔壁组每次改 API 都不通知我们——我去和对面的 TL 谈一个约定。"
1
2
3
4
5
6
2
3
4
5
6
# 4.2 Sprint 变成"微型瀑布"
Sprint 第一天：开发写代码（不能测试，因为还没写完）
Sprint 最后两天：测试开始测 → 一堆 bug → 延期到下一个 Sprint
→ 这不是 Scrum，是两周的瀑布。
正确方式：开发写完一个 story 就转测试，不要等到 Sprint 末尾。
目标：第 5 天至少有一个 story 完全 Done。
1
2
3
4
5
6
2
3
4
5
6
# 4.3 Velocity 被当做考核指标
PO："上个月 Velocity 是 30，这个月怎么才 25？"
→ 一旦 Velocity 变成 KPI，团队就会开始虚报点数。
本来 3 点的写成 5 点——"进度慢"的问题没有解决，但报表好看了。
Velocity 只在一种情况下有用：团队自己看，用来规划 Sprint 容量。
永远不要跨团队比较 Velocity——每个团队的 1 点完全不一样。
1
2
3
4
5
6
2
3
4
5
6
# 五、小结
Scrum 不是管理工具——是团队的协作节奏。
三个角色 → PO（价值）、SM（流程）、Dev Team（质量）
五个仪式 → Planning / 站会 / Review / Retro / Backlog Refinement
三个工件 → Product Backlog / Sprint Backlog / Increment
对工程师最关键的：
1. Sprint Planning 前看 Product Backlog——你对哪些 story 有发言权？提前想好
2. 站会上暴露阻碍——"卡住了"不丢人，"默默卡到延期"才丢人
3. 每个 story 写好 DoD——"做完了"的标准和 PO 提前对齐
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
行动清单：
- [ ] 找你们 SM 确认：当前团队每个 story 的 DoD 写了吗？
- [ ] 下次 Planning 找一个 8 点以上的 story，试着拆成两个 3-5 点的
- [ ] Retro 上提一条具体的流程改进建议——与其抱怨"流程好烦"，不如提"这个环节可以去掉"
上次更新: 2026/06/15, 14:32:53
