Scrum落地避坑指南：一个技术负责人踩过的5个流程管理深坑与解法

2019 年，我在一个 25 人的技术团队第一次推 Scrum。

结果是——三个月后，团队对 Scrum 的评价出奇一致：“又多了一套形式主义的东西。”

当时我很沮丧。Scrum Guide 读了不下三遍，Sprint 仪式一个没少，为什么团队反而觉得被拖累了？

后来我才明白：Scrum Guide 是一本 13 页的框架说明书，它告诉你要做什么、什么时候做，但没有告诉你人的惯性会让这些东西在实际执行中变成什么样子。

这篇文章里聊的 5 个坑，是我用了六年 Scrum、带过四个不同团队之后才真正想明白的。每个坑都配了非常具体的解法，不是什么"加强沟通""拥抱变化"这种正确的废话——是可以明天就照着做的那种。

顺便提一句：本文涉及的工具举例使用了禅道——国内目前使用最广泛的国产开源项目管理工具之一——因为它是我在实际带团队时真正深度使用过的。不是广告，是实战记录。

坑 1：Sprint Planning 变成"分任务大会"，没人知道"做完"是什么意思

场景

Sprint Planning 开了一个半小时，Backlog 里拖了 20 个 Story 进 Sprint，每个都估了 Story Point。会议结束，大家干劲十足。

一周之后，Sprint 过半，看板上的"进行中"列堆了 15 张卡片，"已完成"只拖过去 2 张。

再一看——有个开发把一个 Story 的代码写完了，PR 提了，状态还挂在"开发中"，因为他觉得"没合并就不算做完"。另一个开发把 Story 拖到了"已完成"，但实际上单元测试一个没写，理由是"这个 Story 没提到要写测试"。

根因：团队没有对"Done"达成共识。每个人脑子里"做完"的标准不一样，有的人做到 A 就算完，有的人要走到 C 才敢标记完成。Sprint Planning 花了大量时间估算"要多久"，却没花时间定义"做到什么程度算完"。

解法：在每个 Sprint 的第一个 Story 上定义 DOD（Definition of Done）

DOD 不需要高大上，不需要贴满整面墙。中小团队最简单的 DOD 就是一张 Checklist，挂在每个 Sprint 的第一个 Story 上：

本 Sprint 的 Done = 以下全部满足： □ 代码已提交并合并到 main 分支 □ 单元测试覆盖率不低于当前基线 □ 核心场景的集成测试已通过 □ Code Review 至少一人 Approve □ 相关文档/接口说明已更新 □ 已在测试环境验证通过

注意——DOD 是团队自己定的，不是技术负责人一个人拍板的。第一次 Sprint Planning 抽 15 分钟让大家讨论"我们认为一个 Story 做到什么程度可以被叫做 Done"，列出 5-7 条，写到看板的顶部。以后每次回顾可以修改，但 Sprint 进行中不改。

在禅道里，你可以把 DOD 做成一个任务模板——新建 Sprint 时自动创建一张"DOD Checklist"类型的任务挂在第一个 Story 下面，整个团队共享。每次拖 Story 到"已完成"之前，对着这条 Checklist 勾一遍。

一句话总结：没有 DOD 的 Sprint，不是 Sprint，是二十个没有终点线的长跑。

实际效果对比：我带的第二个团队引入 DOD 之前，Sprint 末尾"已完成但未合并"和"合并了但未部署到测试环境"的 Story 平均每个 Sprint 有 5-6 个。引入 DOD Checklist 并强制"勾完才算 Done"之后，第一个 Sprint 降到了 1 个，第三个 Sprint 之后归零。合并前置的扯皮时间从每个 Story 约 20 分钟降到几乎没有。

坑 2：Daily Standup 变成了"每日汇报大会"

场景

每天早上 9:30，15 个人围成一圈（或者挤在一个视频会议里）。每个人花 3 分钟讲"我昨天做了什么、今天要做什么、有什么阻塞"。

15 × 3 = 45 分钟。

开完站会，团队脸上写着的不是"方向清晰了"，而是"终于解脱了"。

更致命的是——大部分人在讲的时候，其他人根本没在听。每个人只是在排队等着轮到自己说话，然后在别人讲话的时候偷偷回群消息。

根因：Standup 的本质是"团队自我同步"，不是"向上汇报给 Leader"。当站会变成了"每个人轮流给技术负责人做进度报告"，它的灵魂就已经死了。

解法：把 Standup 从"对人汇报"扭成"对看板说话"

具体操作很简单——站会时，不要按人头轮流发言，而是对着看板从右往左走。

1. 先看"已完成"列——过去 24 小时有什么完成了？（快速过，3 分钟）
2. 再看"阻塞/有问题"列——有什么卡住了？需要谁帮忙？（重点讨论，8 分钟）
3. 最后扫一眼"进行中"——有没有哪个任务在这列待了超过两天，但没人注意到？（查漏补缺，2 分钟）

这样改之后，站会时间从 45 分钟压到了 15 分钟以内。而且讨论焦点从"张三做了什么"变成了"哪些任务需要关注"——主角从人变成了事。

另有一个配套做法：超过 10 人的团队，站会限制每人发言不超过 60 秒，细节会后"一对一"解决。站会的目标是暴露问题，不是解决问题。

坑 3：Story Point 从估算工具变成了绩效指标

场景

到了季度末，技术总监拉了一张表——“这个季度，张三完成了 32 个 Story Point，李四完成了 21 个。李四的效率是不是有问题？”

李四知道这件事之后，下个 Sprint 的第一件事就是给自己每个 Story 多估 3 个 Point。

然后 Story Point 的估算彻底变成了一个博弈游戏。没人再认真思考"这个 Story 到底有多复杂"——每个人在想的是"我怎么估才能让自己的季度数据好看"。

根因：Story Point 是一个相对复杂度的估算工具，不是产出度量。它衡量的是"这个任务比那个任务复杂多少倍"，而不是"你这个人干了多少活"。一旦 Story Point 和绩效挂钩，它的度量功能就瞬间崩溃——古德哈特定律在敏捷管理中的完美诠释：“当一个度量变成了目标，它就不再是一个好的度量。”

解法：用吞吐量（Throughput）替代 Story Point 做度量

不要再统计"每个人完成了多少 Story Point"。改为统计：

• 团队每个 Sprint 完成了多少个 Story（Throughput）——衡量团队整体产出节奏
• Cycle Time——一个 Story 从"开始开发"到"已完成"的平均时长——衡量流程效率
• Sprint 目标达成率——这个 Sprint 定了一个目标（比如"支付模块上线"），Sprint 结束的时候目标达到了吗？——衡量价值交付

这三个指标，没有一个和"个人绩效"直接相关——它们全部衡量的是团队作为一个整体的交付能力。这才是 Sprint 回顾真正需要讨论的东西。

在禅道的统计报表模块里，Cycle Time 和 Throughput 都有现成的图表——燃尽图告诉你 Sprint 的进度偏差，分布图告诉你任务在各个状态的平均停留时间。不需要自己拉 Excel 手算。

一句话总结：一旦 Story Point 变成了 KPI，你就失去了估算的诚实性。用吞吐量和周期时间替代，把度量对象从"个人"转成"团队"。

实际效果对比：切换度量方式后，我带的团队出现了一个有意思的变化——Cycle Time 从平均 5.2 天降到了 3.1 天。不是因为大家更努力了，而是因为吞吐量这个指标暴露了一个真相：团队有大量 Story 被"开工了但卡在 Code Review 等了两天"。以前没人注意到这个瓶颈，因为 Story Point 统计只关心完成了多少，不关心完成的路上花了多长时间。

坑 4：Sprint 回顾变成了"吐槽大会"，然后什么都没改变

场景

Sprint 回顾上，团队踊跃发言：

“这个 Sprint 中途被业务方塞了三个紧急需求，节奏全乱了。”

“Code Review 等了两天才有人看，以后能不能规定 24 小时内必须 Review 完？”

“测试环境又挂了两次，开发部署了半天才修好。”

一个小时的回顾，白板上写了十几条改进建议。然后——下一次回顾，同样的问题又出现了。

Scrum Master 很无奈：“大家都说了要改，但 Sprint 一忙起来就都忘了。”

根因：回顾产生的 Action Item 没有负责人和截止时间。一个没有 Owner 和 Deadline 的改进项，本质上只是一句牢骚的书面形式。

解法：每个 Action Item 都必须满足"三人原则"

回顾结束前，挑出投票最多的 1-2 个改进项（别贪多，一次最多改两个），每个改进项必须明确三件事：

• 谁负责推进（一个人，不是一个组）
• 什么时候完成（下个 Sprint 结束之前）
• 怎么衡量改没改（要有明确的验收标准）

举个例子——"Code Review 太慢"在回顾上变成了 Action Item：

Action：Code Review 响应时间从平均 18 小时缩短到 4 小时以内。
负责人：老赵（技术负责人）
截止：Sprint 15 结束前
验收标准：下一个 Sprint 中，MR 从提交到首次 Review 的 P50 时间 ≤ 4 小时，P90 ≤ 8 小时。

下个 Sprint 的第一次 Standup，老赵先汇报这条 Action 的推进情况。回顾不是 Sprint 的结束，是下一个 Sprint 的起点。

坑 5：Backlog Refinement 被无限期搁置

场景

Sprint 跑了三四轮之后，Backlog 里的 Story 越来越多——从最初的 30 条膨胀到了 120 条。而且其中一半的需求描述是半年前写的，到底还要不要、优先级还对不对，没人说得清。

到了 Sprint Planning，团队从 120 条的 Backlog 里现挑——挑出来的 Story 描述太模糊拆不了任务，拆了任务发现依赖外部团队的接口还没准备好，勉强拆完的 Story 做到一半才发现需求本身就不合理。

根因：Backlog Refinement（需求梳理）被认为是"可有可无"的活动，因为它不产生直接的 Sprint 交付物。但 Backlog 不维护，Sprint Planning 的质量就必然下降——输入是垃圾，输出不可能是金子。

解法：每周固定 45 分钟的 Backlog Refinement

把这个时间钉死在日历上，和 Standup 一样不能取消。只做三件事：

1. Top 优先级的 Story 做细化——确保未来 1-2 个 Sprint 要用到的 Story 已经足够清晰，可以立刻拆成开发任务。判断标准：一个刚入职一个月的开发能不能看懂这个 Story 要做什么？不能，就继续拆。
2. 废弃需求做归档——超过 3 个月没有更新过、也没有人认领的 Story，直接关掉或归档。别让死需求占着 Backlog 的前排座位。
3. 优先级重排——业务方是不是又改了主意？上次排的 P0 还是 P0 吗？快速过一遍 Top 10。

每次 Refinement 控制在 45 分钟以内，只邀请产品经理和 1-2 个资深开发参加，不要拉全员。全员的意见在 Sprint Planning 时再讨论，Refinement 的目的是"让 Planning 有好的原材料"。

附：Story 细化到什么粒度算及格？

这是 Refinement 中最常被问的问题。给一个可操作的判断标准——一个合格的 Story 必须满足以下四条，缺一条就是还没拆到位：

1. 一个人能独立完成——如果这个 Story 需要前端和后端同时开工才能交付，拆成两个 Story
2. 在一个 Sprint 内能做完——如果一个 Story 估了 13 个 Point 以上，大概率需要继续拆
3. 验收标准可测试——不是"用户体验好"，而是"登录失败 3 次后账号锁定 15 分钟"。验收标准写到测试人员可以直接拿去写测试用例的程度
4. 不依赖"还没开始做的外部工作"——如果 Story 的前置依赖（比如第三方 API 对接）还没完成，要么先把依赖做成一个独立 Story 在本 Sprint 完成，要么这个 Story 不要进入当前 Sprint

一个简单的自检方法：把 Story 标题读给一个刚入职一个月的同事听，问他"你知道要做什么吗？你知道做完的标准是什么吗？"如果他回答不了，说明这个 Story 还需要继续拆。

想把 Scrum 做成长期主义的事情，需要的不是某种更复杂的方法论，而是一个愿意把"看起来不紧急但非常重要"的基础维护写进日历的人。Backlog Refinement 就是这样一件事。

写在最后

回过头看，Scrum 最难的地方不是理解它——Scrum Guide 只有 13 页。最难的是在执行过程中识别出"人是怎样让流程走形的"。

这 5 个坑，我全都踩了一遍。不是因为我笨，而是因为这些问题在书上和培训里很少被讲透——它们不是 Scrum 框架本身的问题，是人性和流程碰撞时必然产生的摩擦力。

如果你正在推 Scrum 或者准备推，把上面这张表贴在看板旁边。不用一次改完，一个 Sprint 改一个——6 个月后，你的团队会感谢你的。

❓ FAQ

Q1：Scrum 适合所有团队吗？小团队有没有必要搞 Scrum？

Scrum 不适合所有团队。10 人以下的团队，如果产品需求变化极快、团队成员高度默契，过分正式的 Sprint 仪式反而会拖慢节奏。但这种情况下，Scrum 的思想（固定节奏、可视化、回顾改进）仍然值得借鉴——只是形式可以更轻。比如不叫 Sprint 叫"一周循环"、不写正式的 Standup 而在下班前口头同步一轮。核心是思想，不是形式。

Q2：禅道支持 Scrum 管理吗？和 Jira 比怎么样？

禅道完整支持 Scrum 管理——从 Product Backlog 到 Sprint Planning、任务看板、燃尽图、Sprint 回顾，这些 Scrum 核心仪式都有对应的功能模块。和 Jira 相比：Jira 的工作流定制深度更强（JQL 无敌），禅道的优势在于研发全流程一体化——需求、任务、Bug、测试、文档在同一个系统里闭环，不需要额外插件串联。如果团队更看重"一套工具管到底"而非"每个环节都要极致可定制"，禅道是性价比很高的选择。

Q3：团队对 Scrum 有抵触情绪怎么办？

最常见的抵触原因是"感觉多了一堆会"。解法是：先不要叫"Scrum"，直接做三件事——①每天早上 10 分钟，所有人对着看板快速同步一次（不叫 Standup）；②每两周定一次本周要交付什么（不叫 Sprint Planning）；③做完一个周期后花 20 分钟聊一下哪里可以改（不叫回顾）。等团队从这三件事里尝到了甜头——比如"确实比之前少了很多扯皮"——再告诉他们"其实这就是 Scrum 的简化版"。

Q4：Scrum Master 必须是专职的吗？

20 人以下的团队不需要专职 Scrum Master。最自然的安排是：技术负责人在 Sprint 的前半段（Planning 和 Standup）承担更多流程引导角色，在后半段（开发和交付）回归技术角色。关键不是"谁来当 Scrum Master"，而是"有一个人对流程的持续运作负责"。如果没有人对流程负责，流程在第一次遇到阻力时就会自动瓦解。

Q5：Scrum 和看板（Kanban）应该怎么选？

简单判断：如果你的团队需求来自一个持续变动的队列（比如运维/客户支持/日常迭代），选看板——没有固定 Sprint，来了就排优先级，做完一个再拉下一个。如果你的团队按版本节奏交付、需要每 1-2 周同步一次阶段性目标，选 Scrum。两者不互斥——不少团队用 Scrumban（Scrum 的仪式 + 看板的流动管理），效果也很好。选方法论的标准只有一条：它能不能帮团队交付出更好的软件，而不是"它听起来够不够正统"。

本文内容来自作者在多个研发团队中推进 Scrum 的一线实践经验。工具截图为禅道项目管理软件的实际使用界面，数据和分析框架基于 PMI 敏捷实践指南和 Scrum Guide 2020 版中的核心原则。每个团队的情况不同，请结合自身实际调整落地策略。