先说结论：Scrum Master不是“管 Scrum 的人”，是拆组织摩擦力的人
我 2019 年到 2021 年在杭州一家 70 多人的 SaaS 公司做 SM，前后带过 4 个团队：一个 7 人，一个 8 人，一个 9 人，还有一个临时拼的 5 人数据组。刚接手时我也以为 SM 就是主持站会、更新 Jira、催 Retro 行动项。结果第一个月，团队 Sprint 目标完成率只有 43%，站会平均开 28 分钟，Daily Scrum 变成逐人汇报。后来我把 Scrum Guide 2020 翻了几遍，里面写得很硬：Daily Scrum 是 15 分钟，Sprint 不超过 4 周，通常 2 周，SM 要确保 Scrum 被理解并实施。注意，是“确保有效”，不是“替团队做决定”。
我做的第一件事不是买白板，也不是换工具。我拿 Jira 导出了前 6 个 Sprint 的 issue 历史，发现 8 人团队平均同时在办 11.3 个故事，Code Review 列经常堆 6 到 8 张卡。站会为什么长？因为每个人都在解释自己为什么没做完。于是我先把站会问题改成：离 Sprint Goal 还差什么？今天你准备收尾哪一张？谁被卡住了？三周后站会中位数降到 11 分钟，不是因为我厉害，是因为障碍被摆到台面上了。
招聘 JD 里 90% 的“Scrum Master”其实是项目经理
我统计过 2023 年某招聘网站 50 条“Scrum Master”JD，杭州加上海，其中 37 条要求“负责项目排期、分配任务、考核成员、控制预算”。这些是 PM 的活。Scrum Master 没有优先级决定权，Product Owner 才有。SM 不能替团队分任务，否则自管理是假的。面试时你可以问三个问题：谁拥有 Product Backlog 排序权？Sprint 中谁可以改范围？Retro 行动项谁跟进？如果回答是“老板/项目经理/SM”，说明他们招的是 PM，只是套了 Scrum 的壳。
我见过最离谱的 JD：要求 Scrum Master 盯代码提交量、统计加班时长、给成员打绩效。这不是 SM，这是监工加 HRBP。Scrum Master 的权限通常不来自人事任命，而来自你能否把系统问题讲清楚。比如测试环境每周挂 3 次，每次恢复 40 分钟，团队等待时间就上去了。你要做的不是骂运维，而是拿数据找有权限的人改流程。
三个指标：别盯 velocity，盯等待时间和障碍解决时间
Velocity 是预测工具，不是 KPI。2020 年我见过一个 8 人团队，velocity 从 34 点涨到 61 点，上线缺陷从 4 个涨到 17 个，因为大家学会把 1 点故事拆成 3 点。后来我们改用：前置时间中位数、WIP 超限次数、障碍平均解决时间。用 Little's Law 粗略算：前置时间约等于 WIP 除以吞吐量。团队每周吞吐量 8 个，WIP 从 11.3 降到 5，理论前置时间从约 9.9 天降到约 4.4 天；实际因为有评审等待，中位数从 9.5 天降到 6.2 天。
这里有个反直觉的地方：限制 WIP 短期会让吞吐量看起来降一点。因为大家被迫先收尾，而不是同时开新坑。我们做实验时，第一周 Done 列只多了 2 张卡，第二周开始 Review 等待从 1.8 天降到 0.6 天。SM 要能忍住，不要一看数字不好就取消限制。你要看的是流动效率，不是谁最忙。
落地步骤：SM 入职前 30 天我会做的 4 件事
- 第 1-3 天只旁听，记录时间盒和发言分布。示例：8 人站会 28 分钟，PO 说 9 分钟，SM 说 6 分钟，7 个人在念 Jira。
- 第 4-10 天画价值流。用 Jira 状态进入/离开时间，算等待占比。一个需求 Ready 到 Done 中位数 12 天，实际动手 3.5 天，等待 8.5 天，等待占比 70.8%。
- 第 11-20 天重写 DoD。至少写清：代码评审 1 人、CI 通过、关键路径单测、产品验收、监控埋点、文档更新。没有 DoD，Sprint Review 就是 Demo 表演。
- 第 21-30 天做 WIP 限制实验。看板列：Ready(3)、In Progress(4)、Review(2)、QA(2)、Done。超限不许开新卡。两周后复盘，用数据决定继续还是调整。
别一上来改考核。我吃过亏。有一次我建议把“按时上线”从绩效里拿掉，结果部门经理直接问我：那谁负责？后来我改成先做两周 WIP 实验，只谈前置时间和缺陷逃逸率，不谈奖金。数据出来后再推动，阻力小很多。
对比表：Scrum Master、项目经理、敏捷教练、Product Owner
| 角色 | 关注点 | 能否决定优先级 | 常见指标 | 常见误用 |
|---|---|---|---|---|
| Scrum Master | Scrum 有效性、障碍、自管理 | 不能 | 障碍解决时间、事件时间盒、WIP 超限次数 | 变成会议主持人 |
| 项目经理 | 范围、预算、进度、资源 | 通常能影响 | 里程碑、成本偏差、进度偏差 | 套 Scrum 壳，继续派活 |
| 敏捷教练 | 多团队系统、组织变革 | 通常不能 | 团队数、实践采纳、流动效率 | 只培训，不落地 |
| Product Owner | 价值、Backlog 排序 | 能 | 价值交付、Outcome、Backlog 健康度 | 变成需求传话筒 |
这张表我面试时也用。如果面试官说“我们 SM 要管进度、管人、管优先级”，你可以礼貌问：那 PO 管什么？这不是抬杠，是判断这个岗位到底是 SM 还是 PM。
面试题：团队不写单元测试怎么办？
别答“加强培训”。先看系统。如果管理层按上线数量发奖金，单元测试一定被挤掉。SM 要问：需求压力多大？测试环境稳不稳？CI 多久跑一次？如果 CI 要 40 分钟，没人愿意等。可以试：把单元测试写进 DoD、CI 超过 10 分钟算障碍、每个故事留 15% 时间还技术债。连续 3 个 Sprint 看缺陷逃逸率，从 17 个降到 6 个再谈扩大。
另一个高频题是“团队不发言怎么办”。我通常会先看会议人数。9 人站会围一圈，内向的人根本插不上话。改成 3 到 4 人小组，每天 10 分钟，再回大群同步障碍。不是所有问题都靠教练技术解决，物理布局和会议设计也算系统。
我的独立观点：SM 的价值是降低组织摩擦成本
Scrum Master 不是团队保姆，也不是敏捷警察。他是系统观察员：看见等待、返工、信息孤岛，然后推动有权限的人改系统。认证有用，PSM I 或 CSM 可以帮你过 HR 筛，但 PSM II/III 更考实践。真正面试时，拿一个你解决过的障碍讲清楚：背景、数据、动作、结果、学到什么。别背“我善于沟通”。如果组织让 SM 兼项目经理，两个目标会打架：一个要保护团队，一个要压进度。能分开就分开，分不开就至少把优先级权还给 PO。
如果只能记一句话：Scrum Master 的 KPI 不该是团队 velocity，而该是“障碍平均解决时间”和“跨职能等待时间”。前者说明你能不能拆路障，后者说明组织愿不愿意让团队流动。这两个数字降下来，Sprint 目标完成率通常自己会上去。