2019 年我在一个 25 人的技术团队第一次推 Scrum。结果是——三个月后团队对 Scrum 的评价出奇一致“又多了一套形式主义的东西。”当时我很沮丧。Scrum Guide 读了不下三遍Sprint 仪式一个没少为什么团队反而觉得被拖累了后来我才明白Scrum Guide 是一本 13 页的框架说明书它告诉你要做什么、什么时候做但没有告诉你人的惯性会让这些东西在实际执行中变成什么样子。这篇文章里聊的 5 个坑是我用了六年 Scrum、带过四个不同团队之后才真正想明白的。每个坑都配了非常具体的解法不是什么加强沟通拥抱变化这种正确的废话——是可以明天就照着做的那种。顺便提一句本文涉及的工具举例使用了禅道——国内目前使用最广泛的国产开源项目管理工具之一——因为它是我在实际带团队时真正深度使用过的。不是广告是实战记录。坑 1Sprint Planning 变成分任务大会没人知道做完是什么意思场景Sprint Planning 开了一个半小时Backlog 里拖了 20 个 Story 进 Sprint每个都估了 Story Point。会议结束大家干劲十足。一周之后Sprint 过半看板上的进行中列堆了 15 张卡片已完成只拖过去 2 张。再一看——有个开发把一个 Story 的代码写完了PR 提了状态还挂在开发中因为他觉得没合并就不算做完。另一个开发把 Story 拖到了已完成但实际上单元测试一个没写理由是这个 Story 没提到要写测试。根因团队没有对Done达成共识。每个人脑子里做完的标准不一样有的人做到 A 就算完有的人要走到 C 才敢标记完成。Sprint Planning 花了大量时间估算要多久却没花时间定义做到什么程度算完。解法在每个 Sprint 的第一个 Story 上定义 DODDefinition of DoneDOD 不需要高大上不需要贴满整面墙。中小团队最简单的 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 分钟降到几乎没有。坑 2Daily Standup 变成了每日汇报大会场景每天早上 9:3015 个人围成一圈或者挤在一个视频会议里。每个人花 3 分钟讲我昨天做了什么、今天要做什么、有什么阻塞。15 × 3 45 分钟。开完站会团队脸上写着的不是方向清晰了而是终于解脱了。更致命的是——大部分人在讲的时候其他人根本没在听。每个人只是在排队等着轮到自己说话然后在别人讲话的时候偷偷回群消息。根因Standup 的本质是团队自我同步不是向上汇报给 Leader。当站会变成了每个人轮流给技术负责人做进度报告它的灵魂就已经死了。解法把 Standup 从对人汇报扭成对看板说话具体操作很简单——站会时不要按人头轮流发言而是对着看板从右往左走。先看已完成列——过去 24 小时有什么完成了快速过3 分钟再看阻塞/有问题列——有什么卡住了需要谁帮忙重点讨论8 分钟最后扫一眼进行中——有没有哪个任务在这列待了超过两天但没人注意到查漏补缺2 分钟这样改之后站会时间从 45 分钟压到了 15 分钟以内。而且讨论焦点从张三做了什么变成了哪些任务需要关注——主角从人变成了事。另有一个配套做法超过 10 人的团队站会限制每人发言不超过 60 秒细节会后一对一解决。站会的目标是暴露问题不是解决问题。坑 3Story Point 从估算工具变成了绩效指标场景到了季度末技术总监拉了一张表——“这个季度张三完成了 32 个 Story Point李四完成了 21 个。李四的效率是不是有问题”李四知道这件事之后下个 Sprint 的第一件事就是给自己每个 Story 多估 3 个 Point。然后 Story Point 的估算彻底变成了一个博弈游戏。没人再认真思考这个 Story 到底有多复杂——每个人在想的是我怎么估才能让自己的季度数据好看。根因Story Point 是一个相对复杂度的估算工具不是产出度量。它衡量的是这个任务比那个任务复杂多少倍而不是你这个人干了多少活。一旦 Story Point 和绩效挂钩它的度量功能就瞬间崩溃——古德哈特定律在敏捷管理中的完美诠释“当一个度量变成了目标它就不再是一个好的度量。”解法用吞吐量Throughput替代 Story Point 做度量不要再统计每个人完成了多少 Story Point。改为统计团队每个 Sprint 完成了多少个 StoryThroughput——衡量团队整体产出节奏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 统计只关心完成了多少不关心完成的路上花了多长时间。坑 4Sprint 回顾变成了吐槽大会然后什么都没改变场景Sprint 回顾上团队踊跃发言“这个 Sprint 中途被业务方塞了三个紧急需求节奏全乱了。”“Code Review 等了两天才有人看以后能不能规定 24 小时内必须 Review 完”“测试环境又挂了两次开发部署了半天才修好。”一个小时的回顾白板上写了十几条改进建议。然后——下一次回顾同样的问题又出现了。Scrum Master 很无奈“大家都说了要改但 Sprint 一忙起来就都忘了。”根因回顾产生的 Action Item 没有负责人和截止时间。一个没有 Owner 和 Deadline 的改进项本质上只是一句牢骚的书面形式。解法每个 Action Item 都必须满足三人原则回顾结束前挑出投票最多的 1-2 个改进项别贪多一次最多改两个每个改进项必须明确三件事谁负责推进一个人不是一个组什么时候完成下个 Sprint 结束之前怎么衡量改没改要有明确的验收标准举个例子——Code Review 太慢在回顾上变成了 Action ItemActionCode Review 响应时间从平均 18 小时缩短到 4 小时以内。负责人老赵技术负责人截止Sprint 15 结束前验收标准下一个 Sprint 中MR 从提交到首次 Review 的 P50 时间 ≤ 4 小时P90 ≤ 8 小时。下个 Sprint 的第一次 Standup老赵先汇报这条 Action 的推进情况。回顾不是 Sprint 的结束是下一个 Sprint 的起点。坑 5Backlog Refinement 被无限期搁置场景Sprint 跑了三四轮之后Backlog 里的 Story 越来越多——从最初的 30 条膨胀到了 120 条。而且其中一半的需求描述是半年前写的到底还要不要、优先级还对不对没人说得清。到了 Sprint Planning团队从 120 条的 Backlog 里现挑——挑出来的 Story 描述太模糊拆不了任务拆了任务发现依赖外部团队的接口还没准备好勉强拆完的 Story 做到一半才发现需求本身就不合理。根因Backlog Refinement需求梳理被认为是可有可无的活动因为它不产生直接的 Sprint 交付物。但 Backlog 不维护Sprint Planning 的质量就必然下降——输入是垃圾输出不可能是金子。解法每周固定 45 分钟的 Backlog Refinement把这个时间钉死在日历上和 Standup 一样不能取消。只做三件事Top 优先级的 Story 做细化——确保未来 1-2 个 Sprint 要用到的 Story 已经足够清晰可以立刻拆成开发任务。判断标准一个刚入职一个月的开发能不能看懂这个 Story 要做什么不能就继续拆。废弃需求做归档——超过 3 个月没有更新过、也没有人认领的 Story直接关掉或归档。别让死需求占着 Backlog 的前排座位。优先级重排——业务方是不是又改了主意上次排的 P0 还是 P0 吗快速过一遍 Top 10。每次 Refinement 控制在 45 分钟以内只邀请产品经理和 1-2 个资深开发参加不要拉全员。全员的意见在 Sprint Planning 时再讨论Refinement 的目的是让 Planning 有好的原材料。附Story 细化到什么粒度算及格这是 Refinement 中最常被问的问题。给一个可操作的判断标准——一个合格的 Story 必须满足以下四条缺一条就是还没拆到位一个人能独立完成——如果这个 Story 需要前端和后端同时开工才能交付拆成两个 Story在一个 Sprint 内能做完——如果一个 Story 估了 13 个 Point 以上大概率需要继续拆验收标准可测试——不是用户体验好而是登录失败 3 次后账号锁定 15 分钟。验收标准写到测试人员可以直接拿去写测试用例的程度不依赖还没开始做的外部工作——如果 Story 的前置依赖比如第三方 API 对接还没完成要么先把依赖做成一个独立 Story 在本 Sprint 完成要么这个 Story 不要进入当前 Sprint一个简单的自检方法把 Story 标题读给一个刚入职一个月的同事听问他你知道要做什么吗你知道做完的标准是什么吗如果他回答不了说明这个 Story 还需要继续拆。想把 Scrum 做成长期主义的事情需要的不是某种更复杂的方法论而是一个愿意把看起来不紧急但非常重要的基础维护写进日历的人。Backlog Refinement 就是这样一件事。写在最后回过头看Scrum 最难的地方不是理解它——Scrum Guide 只有 13 页。最难的是在执行过程中识别出人是怎样让流程走形的。你看到的症状根因解法一句话量化效果实测Sprint过半没人拖已完成没定义 Done 的标准Sprint 启动时用 DOD Checklist 锚定验收条件已合未测 Story 从 5-6 个/Sprint → 归零站会 45 分钟全队走神对着人汇报而非对着看板看板从右往左走聚焦阻塞45 分钟 → 12 分钟估点变成了博弈游戏Story Point 被当成 KPI改用 Throughput Cycle Time 度量团队整体Cycle Time 5.2 天 → 3.1 天回顾完什么都没变Action Item 没有 Owner 和 Deadline每条改进项必须有负责人截止日验收标准Action 完成率 ~20% → ~80%Backlog 膨胀到 100 条无人维护Refinement 被当成可有可无每周固定 45 分钟只做细化归档重排Planning 准备时间从 2h → 45min这 5 个坑我全都踩了一遍。不是因为我笨而是因为这些问题在书上和培训里很少被讲透——它们不是 Scrum 框架本身的问题是人性和流程碰撞时必然产生的摩擦力。如果你正在推 Scrum 或者准备推把上面这张表贴在看板旁边。不用一次改完一个 Sprint 改一个——6 个月后你的团队会感谢你的。❓ FAQQ1Scrum 适合所有团队吗小团队有没有必要搞 ScrumScrum 不适合所有团队。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 的简化版。Q4Scrum Master 必须是专职的吗20 人以下的团队不需要专职 Scrum Master。最自然的安排是技术负责人在 Sprint 的前半段Planning 和 Standup承担更多流程引导角色在后半段开发和交付回归技术角色。关键不是谁来当 Scrum Master而是有一个人对流程的持续运作负责。如果没有人对流程负责流程在第一次遇到阻力时就会自动瓦解。Q5Scrum 和看板Kanban应该怎么选简单判断如果你的团队需求来自一个持续变动的队列比如运维/客户支持/日常迭代选看板——没有固定 Sprint来了就排优先级做完一个再拉下一个。如果你的团队按版本节奏交付、需要每 1-2 周同步一次阶段性目标选 Scrum。两者不互斥——不少团队用 ScrumbanScrum 的仪式 看板的流动管理效果也很好。选方法论的标准只有一条它能不能帮团队交付出更好的软件而不是它听起来够不够正统。本文内容来自作者在多个研发团队中推进 Scrum 的一线实践经验。工具截图为禅道项目管理软件的实际使用界面数据和分析框架基于 PMI 敏捷实践指南和 Scrum Guide 2020 版中的核心原则。每个团队的情况不同请结合自身实际调整落地策略。
2019 年我在一个 25 人的技术团队第一次推 Scrum。结果是——三个月后团队对 Scrum 的评价出奇一致“又多了一套形式主义的东西。”当时我很沮丧。Scrum Guide 读了不下三遍Sprint 仪式一个没少为什么团队反而觉得被拖累了后来我才明白Scrum Guide 是一本 13 页的框架说明书它告诉你要做什么、什么时候做但没有告诉你人的惯性会让这些东西在实际执行中变成什么样子。这篇文章里聊的 5 个坑是我用了六年 Scrum、带过四个不同团队之后才真正想明白的。每个坑都配了非常具体的解法不是什么加强沟通拥抱变化这种正确的废话——是可以明天就照着做的那种。顺便提一句本文涉及的工具举例使用了禅道——国内目前使用最广泛的国产开源项目管理工具之一——因为它是我在实际带团队时真正深度使用过的。不是广告是实战记录。坑 1Sprint Planning 变成分任务大会没人知道做完是什么意思场景Sprint Planning 开了一个半小时Backlog 里拖了 20 个 Story 进 Sprint每个都估了 Story Point。会议结束大家干劲十足。一周之后Sprint 过半看板上的进行中列堆了 15 张卡片已完成只拖过去 2 张。再一看——有个开发把一个 Story 的代码写完了PR 提了状态还挂在开发中因为他觉得没合并就不算做完。另一个开发把 Story 拖到了已完成但实际上单元测试一个没写理由是这个 Story 没提到要写测试。根因团队没有对Done达成共识。每个人脑子里做完的标准不一样有的人做到 A 就算完有的人要走到 C 才敢标记完成。Sprint Planning 花了大量时间估算要多久却没花时间定义做到什么程度算完。解法在每个 Sprint 的第一个 Story 上定义 DODDefinition of DoneDOD 不需要高大上不需要贴满整面墙。中小团队最简单的 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 分钟降到几乎没有。坑 2Daily Standup 变成了每日汇报大会场景每天早上 9:3015 个人围成一圈或者挤在一个视频会议里。每个人花 3 分钟讲我昨天做了什么、今天要做什么、有什么阻塞。15 × 3 45 分钟。开完站会团队脸上写着的不是方向清晰了而是终于解脱了。更致命的是——大部分人在讲的时候其他人根本没在听。每个人只是在排队等着轮到自己说话然后在别人讲话的时候偷偷回群消息。根因Standup 的本质是团队自我同步不是向上汇报给 Leader。当站会变成了每个人轮流给技术负责人做进度报告它的灵魂就已经死了。解法把 Standup 从对人汇报扭成对看板说话具体操作很简单——站会时不要按人头轮流发言而是对着看板从右往左走。先看已完成列——过去 24 小时有什么完成了快速过3 分钟再看阻塞/有问题列——有什么卡住了需要谁帮忙重点讨论8 分钟最后扫一眼进行中——有没有哪个任务在这列待了超过两天但没人注意到查漏补缺2 分钟这样改之后站会时间从 45 分钟压到了 15 分钟以内。而且讨论焦点从张三做了什么变成了哪些任务需要关注——主角从人变成了事。另有一个配套做法超过 10 人的团队站会限制每人发言不超过 60 秒细节会后一对一解决。站会的目标是暴露问题不是解决问题。坑 3Story Point 从估算工具变成了绩效指标场景到了季度末技术总监拉了一张表——“这个季度张三完成了 32 个 Story Point李四完成了 21 个。李四的效率是不是有问题”李四知道这件事之后下个 Sprint 的第一件事就是给自己每个 Story 多估 3 个 Point。然后 Story Point 的估算彻底变成了一个博弈游戏。没人再认真思考这个 Story 到底有多复杂——每个人在想的是我怎么估才能让自己的季度数据好看。根因Story Point 是一个相对复杂度的估算工具不是产出度量。它衡量的是这个任务比那个任务复杂多少倍而不是你这个人干了多少活。一旦 Story Point 和绩效挂钩它的度量功能就瞬间崩溃——古德哈特定律在敏捷管理中的完美诠释“当一个度量变成了目标它就不再是一个好的度量。”解法用吞吐量Throughput替代 Story Point 做度量不要再统计每个人完成了多少 Story Point。改为统计团队每个 Sprint 完成了多少个 StoryThroughput——衡量团队整体产出节奏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 统计只关心完成了多少不关心完成的路上花了多长时间。坑 4Sprint 回顾变成了吐槽大会然后什么都没改变场景Sprint 回顾上团队踊跃发言“这个 Sprint 中途被业务方塞了三个紧急需求节奏全乱了。”“Code Review 等了两天才有人看以后能不能规定 24 小时内必须 Review 完”“测试环境又挂了两次开发部署了半天才修好。”一个小时的回顾白板上写了十几条改进建议。然后——下一次回顾同样的问题又出现了。Scrum Master 很无奈“大家都说了要改但 Sprint 一忙起来就都忘了。”根因回顾产生的 Action Item 没有负责人和截止时间。一个没有 Owner 和 Deadline 的改进项本质上只是一句牢骚的书面形式。解法每个 Action Item 都必须满足三人原则回顾结束前挑出投票最多的 1-2 个改进项别贪多一次最多改两个每个改进项必须明确三件事谁负责推进一个人不是一个组什么时候完成下个 Sprint 结束之前怎么衡量改没改要有明确的验收标准举个例子——Code Review 太慢在回顾上变成了 Action ItemActionCode Review 响应时间从平均 18 小时缩短到 4 小时以内。负责人老赵技术负责人截止Sprint 15 结束前验收标准下一个 Sprint 中MR 从提交到首次 Review 的 P50 时间 ≤ 4 小时P90 ≤ 8 小时。下个 Sprint 的第一次 Standup老赵先汇报这条 Action 的推进情况。回顾不是 Sprint 的结束是下一个 Sprint 的起点。坑 5Backlog Refinement 被无限期搁置场景Sprint 跑了三四轮之后Backlog 里的 Story 越来越多——从最初的 30 条膨胀到了 120 条。而且其中一半的需求描述是半年前写的到底还要不要、优先级还对不对没人说得清。到了 Sprint Planning团队从 120 条的 Backlog 里现挑——挑出来的 Story 描述太模糊拆不了任务拆了任务发现依赖外部团队的接口还没准备好勉强拆完的 Story 做到一半才发现需求本身就不合理。根因Backlog Refinement需求梳理被认为是可有可无的活动因为它不产生直接的 Sprint 交付物。但 Backlog 不维护Sprint Planning 的质量就必然下降——输入是垃圾输出不可能是金子。解法每周固定 45 分钟的 Backlog Refinement把这个时间钉死在日历上和 Standup 一样不能取消。只做三件事Top 优先级的 Story 做细化——确保未来 1-2 个 Sprint 要用到的 Story 已经足够清晰可以立刻拆成开发任务。判断标准一个刚入职一个月的开发能不能看懂这个 Story 要做什么不能就继续拆。废弃需求做归档——超过 3 个月没有更新过、也没有人认领的 Story直接关掉或归档。别让死需求占着 Backlog 的前排座位。优先级重排——业务方是不是又改了主意上次排的 P0 还是 P0 吗快速过一遍 Top 10。每次 Refinement 控制在 45 分钟以内只邀请产品经理和 1-2 个资深开发参加不要拉全员。全员的意见在 Sprint Planning 时再讨论Refinement 的目的是让 Planning 有好的原材料。附Story 细化到什么粒度算及格这是 Refinement 中最常被问的问题。给一个可操作的判断标准——一个合格的 Story 必须满足以下四条缺一条就是还没拆到位一个人能独立完成——如果这个 Story 需要前端和后端同时开工才能交付拆成两个 Story在一个 Sprint 内能做完——如果一个 Story 估了 13 个 Point 以上大概率需要继续拆验收标准可测试——不是用户体验好而是登录失败 3 次后账号锁定 15 分钟。验收标准写到测试人员可以直接拿去写测试用例的程度不依赖还没开始做的外部工作——如果 Story 的前置依赖比如第三方 API 对接还没完成要么先把依赖做成一个独立 Story 在本 Sprint 完成要么这个 Story 不要进入当前 Sprint一个简单的自检方法把 Story 标题读给一个刚入职一个月的同事听问他你知道要做什么吗你知道做完的标准是什么吗如果他回答不了说明这个 Story 还需要继续拆。想把 Scrum 做成长期主义的事情需要的不是某种更复杂的方法论而是一个愿意把看起来不紧急但非常重要的基础维护写进日历的人。Backlog Refinement 就是这样一件事。写在最后回过头看Scrum 最难的地方不是理解它——Scrum Guide 只有 13 页。最难的是在执行过程中识别出人是怎样让流程走形的。你看到的症状根因解法一句话量化效果实测Sprint过半没人拖已完成没定义 Done 的标准Sprint 启动时用 DOD Checklist 锚定验收条件已合未测 Story 从 5-6 个/Sprint → 归零站会 45 分钟全队走神对着人汇报而非对着看板看板从右往左走聚焦阻塞45 分钟 → 12 分钟估点变成了博弈游戏Story Point 被当成 KPI改用 Throughput Cycle Time 度量团队整体Cycle Time 5.2 天 → 3.1 天回顾完什么都没变Action Item 没有 Owner 和 Deadline每条改进项必须有负责人截止日验收标准Action 完成率 ~20% → ~80%Backlog 膨胀到 100 条无人维护Refinement 被当成可有可无每周固定 45 分钟只做细化归档重排Planning 准备时间从 2h → 45min这 5 个坑我全都踩了一遍。不是因为我笨而是因为这些问题在书上和培训里很少被讲透——它们不是 Scrum 框架本身的问题是人性和流程碰撞时必然产生的摩擦力。如果你正在推 Scrum 或者准备推把上面这张表贴在看板旁边。不用一次改完一个 Sprint 改一个——6 个月后你的团队会感谢你的。❓ FAQQ1Scrum 适合所有团队吗小团队有没有必要搞 ScrumScrum 不适合所有团队。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 的简化版。Q4Scrum Master 必须是专职的吗20 人以下的团队不需要专职 Scrum Master。最自然的安排是技术负责人在 Sprint 的前半段Planning 和 Standup承担更多流程引导角色在后半段开发和交付回归技术角色。关键不是谁来当 Scrum Master而是有一个人对流程的持续运作负责。如果没有人对流程负责流程在第一次遇到阻力时就会自动瓦解。Q5Scrum 和看板Kanban应该怎么选简单判断如果你的团队需求来自一个持续变动的队列比如运维/客户支持/日常迭代选看板——没有固定 Sprint来了就排优先级做完一个再拉下一个。如果你的团队按版本节奏交付、需要每 1-2 周同步一次阶段性目标选 Scrum。两者不互斥——不少团队用 ScrumbanScrum 的仪式 看板的流动管理效果也很好。选方法论的标准只有一条它能不能帮团队交付出更好的软件而不是它听起来够不够正统。本文内容来自作者在多个研发团队中推进 Scrum 的一线实践经验。工具截图为禅道项目管理软件的实际使用界面数据和分析框架基于 PMI 敏捷实践指南和 Scrum Guide 2020 版中的核心原则。每个团队的情况不同请结合自身实际调整落地策略。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
