Sprint（冲刺）解读
一、Sprint 到底是个啥？（先破误区）
很多人以为：
- Sprint = 两周时间
- Sprint = 一堆 Story
- Sprint = 版本周期
都不完整。
👉 Sprint 本质上是：
团队用一个固定时长，集中精力解决一个清晰的产品目标（Product Goal），并在过程中不断校准方向。
二、为什么 Sprint 要“固定长度”？（不是为了管理）
指南原意 ： Sprint 是固定长度的事件，最长为一个月 （Scrum 指南的这条限制，本质是 “给反馈循环设上限”：）
核心原因有 3 点
- 建立稳定可预期的团队节奏，减少协作成本
- 固定周期让团队形成 “肌肉记忆”：比如选择 2 周为一个 Sprint，团队会默认每 2 周完成一次 “规划→执行→交付→复盘” 的闭环，不用每次都讨论 “这次迭代多久”“什么时候开评审会”，大幅减少协调成本。
- 指南规定 “最多 1 个月”，是因为超过 1 个月的反馈延迟会导致 “需求漂移”—— 市场变了、用户需求变了，之前的开发就成了无效投入。
- 保障持续改进的有效性
- Scrum 的 “回顾会” 是团队持续改进的核心机制，而固定 Sprint 长度是回顾会能定期召开的前提。
- 比如每 2 周开一次回顾会，团队可以基于 “这 2 周的实践” 总结 “哪些做法有效、哪些无效”
- 如果 Sprint 长度不固定，回顾会就会 “想起来就开，想不起来就不开”，团队的问题会不断重复，永远停留在 “低效率” 状态。
三、Sprint 期间「不能做」的事（很关键）
Scrum 指南这里很严格，但不是为了死板。
🚫 1. 不能随便改 Sprint 目标
人话解释：
「如果目标天天变，那我们其实是在到处救火，而不是在交付价值。」
不是说不能沟通变化，而是 变化要大到值得推翻这个 Sprint，才会被接受。
PS：一个关键现实是 👉 很多团队并不是“纯 Scrum”，而是 Scrum + Kanban（全世界81%的团队在使用这个模式，数据来自2019年scrum.org发布的ScrumMaster趋势报告中）
我们现在用的是 Scrum + Kanban， 在 Scrum + Kanban 模式下 这意味着：我们允许变化，但不能失控。
- 每一个临时插入的高优先级 Story，都必须明确“挤掉了什么”。
- 紧急是例外，不是常态。 如果发现每个Sprint 都有“更高优先级”，那问题不在 Sprint而在 需求治理。
🚫 2. 不能为了赶进度而降质量
「质量不是最后再补的，质量是 Sprint 的一部分。」
一旦允许：
- “先上线再说”
- “这次就算了”
👉 Scrum 就开始变味了。
四、Sprint 期间「可以、而且应该」做的事
✅ 1. Product Backlog 可以继续细化
「我们不可能一开始就想得很清楚，所以边做边想是正常的。」
但前提是：
- 不破坏 Sprint 目标
- 不让团队失去专注
✅ 2. 和 PO 持续澄清范围
意思是：在不改变 Sprint 目标的前提下， 怎么能做的更好，是可以边做边聊的 。
举例说明：
场景：合同配置功能
Sprint 目标：让法务可以通过系统配置合同关键参数
Sprint 开始时的理解（还比较粗）
一开始与 PO 对齐的是：
- 支持 20 个合同参数
- 所有参数都可配置
这是当下最合理的猜测，没问题。
Sprint 进行中，开始“澄清范围”
第一次澄清（来自开发 / 使用场景变清晰）
开发/测试在跑场景时发现：
- 实际合同里常用的只有 6 个参数
- 剩下 14 个基本不会一起用
👉 这时候发生的不是“改需求”，
而是 认知变清楚了
和 PO 的澄清对话
团队：
「如果我们把 6 个高频参数做到极简可用，剩下的先不做，会不会更符合这次 Sprint 的目标？」
PO：
「如果业务现在最常用的是这 6 个，那我们这次先把它做好。」
👉 注意：
目标没变，只是范围更聚焦了
最终结果
- Sprint 目标依然达成
- 功能更容易
- 使用成本更低
- 团队少做了“可能没用的东西”
👉 这就是 “持续澄清范围
再给你一个“反例”，用于区分
❌ 这不是澄清范围，这是改目标
Sprint 中途 PO 说：「那顺便把审批流程也加上吧。」
👉这是：
- 新目标
- 新价值假设
- 新复杂度
应该进 产品待办列表，而不是塞进当前 Sprint。
