Scrum 敏捷项目实战：Sprint 计划与回顾

1. Scrum 敏捷框架核心概念

Scrum 是一个轻量级、迭代增量的敏捷框架，用于管理复杂产品的开发。它通过固定时长的 Sprint 持续交付可工作的软件，并鼓励团队自组织、持续改进。

1.1 Scrum 三大支柱

• 透明：过程和工作对所有相关人员可见。
• 检验：频繁检查工件和进展，及时发现偏差。
• 适应：检查到超出可接受范围的偏差时，立即调整过程或产品。

1.2 关键角色与职责

• 产品负责人：定义产品愿景，管理产品待办列表（Product Backlog），对产品价值负责。
• Scrum Master：作为仆人式领导，确保团队遵循 Scrum 理论、实践和规则，移除障碍。
• 开发团队：跨职能自组织团队（通常 3-9 人），在每个 Sprint 结束时交付潜在可发布增量。

1.3 Sprint 循环

一个 Sprint 通常为 2-4 周，包含四个正式会议：Sprint 计划、每日站会、Sprint 评审、Sprint 回顾。本篇重点深入 Sprint 计划与 Sprint 回顾 的实战操作。

2. Sprint 计划会议实战指南

Sprint 计划由一个时间盒限制（通常为 Sprint 长度 1 周的对应 2 小时）的会议启动整个 Sprint。它回答两个核心问题：这个 Sprint 能交付什么？ 和 如何完成这些工作？

2.1 会议准备清单

• 产品负责人：已排序和细化的产品待办列表，每个条目的描述、价值、验收标准清晰可见，最近 1～2 个 Sprint 的条目已拆分至可在一个 Sprint 内完成。
• Scrum Master：预订会议室，确保所有关键人员到场，准备白板或电子工具。
• 开发团队：知悉团队近期速率（Velocity）和产能（考虑假期、培训等因素）。

2.2 第一部分：确定“做什么”

时长：约占计划总时长的前 50%
目标：选出 Sprint 目标并决定交付哪些产品待办列表条目。

1. 产品负责人阐述愿景和优先级：讲解业务目标与 Sprint 目标建议，解释顶部条目的价值。
2. 团队评估产能：开发团队计算本 Sprint 的实际可用人天（扣除公共假日、成员请假、其他承诺）。
3. 选取待办条目：开发团队根据历史速率和当前产能，从产品待办列表顶部向下选取条目，直至感觉可以合理完成。

   技巧：如果历史数据不足，可以先预测少一些，适应后再调整。

4. 明确验收标准：团队与产品负责人逐条确认验收标准，确保每个人都理解“完成”的边界。
5. 敲定 Sprint 目标：用一句清晰、可衡量的业务语言概括本 Sprint 要达成的成果，例如“用户可以通过手机号注册并登录，且基本个人信息可编辑”。

2.3 第二部分：确定“如何做”

时长：约占总时长的 50%
目标：将选取的待办条目拆解为可执行的任务，并确保每个人有信心完成。

1. 拆分任务：开发团队将每个条目分解为具体技术任务（设计开发、编写测试、代码审查、文档更新等），单个任务建议不超过 1 天工作量。
2. 识别依赖与风险：标出串行依赖或需要外部协作的任务，讨论缓解措施。
3. 确认是否超额：把所有任务的预估工时与团队产能对比。如果明显超出，团队可与产品负责人协商缩小范围或调整 Sprint 目标。
4. 自愿认领：团队成员根据自己的技能和成长意愿认领任务，Scrum Master 鼓励主动认领而非分配。
5. 定义完成基准：引入“完成定义（Definition of Done）”检查清单，确保所有工作事项（代码审查、单元测试、集成测试、文档）一致理解。

2.4 Sprint 计划常见陷阱及对策

3. Sprint 回顾会议深度实践

Sprint 回顾在每个 Sprint 结束后进行，时间盒为 Sprint 长度 1 周的对应 45 分钟。会议聚焦于过程改进，而非产品内容。

3.1 回顾的核心目的

让团队检视自身在人员、关系、过程和工具方面的表现，找出改进项，制定具体执行计划，并在下一个 Sprint 实施。

3.2 标准会议流程

1. 设定舞台（5～10 分钟）

   • 主持人（通常是 Scrum Master）重申回顾目标：发现问题，寻找改进，不指责个人。
   • 可以阅读“回顾主要原则”（如“无论我们发现了什么，我们理解并真心相信每个人在当时已经尽了最大的努力”）。

2. 数据收集（15～20 分钟）

   • 团队共同回顾 Sprint 期间发生的事件、指标（燃尽图、速率、缺陷数量）、感受等。
   • 常用工具：时间轴（Timeline）让成员在时间线上贴便签，记录兴奋、困惑、惊喜等时刻。

3. 深入洞察（15～20 分钟）

   • 对收集到的数据进行模式分析：哪些是反复出现的问题？哪些是意外收获？
   • 使用“5 Why”或“鱼骨图”挖掘根因，聚焦过程而非个人。

4. 决定做什么（10～15 分钟）

   • 投票选出最重要的 1～3 个改进项。
   • 为每个改进项制定 SMART 行动项（具体、可衡量、可实现、相关、有时限），明确负责人和跟踪方式。
   • 行动项记录在团队可见之处（如 Wiki、物理看板），纳入日常站会检查。

5. 总结收尾（5 分钟）

   • 团队成员用一句话分享感受，感谢彼此的开放与贡献，强化心理安全。

3.3 丰富回顾形式的技巧

避免回顾会议僵化为“读流水账”，可轮换使用以下引导技术：

• 快艇/帆船：画一艘海上的帆船，锚代表阻碍，礁石代表风险，风代表助力，团队一起放置便签。
• 高兴/沮丧/主意：每人用三色便签写出 Sprint 中让自己高兴的事、沮丧的事、以及对未来的主意。
• 4L 法：将观察分类为 Liked（喜欢的）、Learned（学到的）、Lacked（缺乏的）、Longed for（渴望的）。
• 热气球：热气球（正向动力） vs 沙袋（负向阻力），帮助团队聚焦改进。

3.4 有效回顾的保障要素

• 心理安全感：回顾中禁止指责个人，Scrum Master 需坚定守护环境，认可所有发言的价值。
• 行动闭环：改进项不能仅停留在记录，必须在下一个 Sprint 计划时回顾上期行动项的完成情况，并在日常活动中执行。
• 时间纪律：严格遵循时间盒，如果讨论时间不够，可由团队决定是否延长或安排后续讨论。
• 全员参与：远程团队可使用在线协作白板（如 Miro, Mural），确保人人都有同等输入机会。

4. 从计划到回顾的完整循环：一个微型案例

假设团队开发一个电商小程序，Sprint 目标为“用户可浏览商品并加入购物车”。

• Sprint 计划：产品负责人带领解读“商品列表展示”和“购物车功能”的用户故事；团队拆分出前端接口适配、购物车状态管理、后端购物车服务、单元测试等任务，共预估 32 工时，团队产能 35 工时，决议可以纳入。
• Sprint 执行：每日站会中，团队不断同步进度并暴露出“购物车数据同步延迟”的技术风险。
• Sprint 评审：交付了商品列表和购物车基本功能，但跨设备同步未完全实现，产品负责人接受增量。
• Sprint 回顾：团队使用“高兴/沮丧/主意”方法，发现“后端购物车服务设计”的延迟源于没有提前进行接口模拟；结果提炼出改进项：“下个 Sprint 开始前，所有涉及跨模块接口的用户故事需先完成接口定义模拟”，并指定一名成员在下一个计划会议前完成规则初稿。

通过这样的闭环，团队在下一个 Sprint 接口设计明显更顺畅，持续改进得以落地。

5. 常用工具与模板

Sprint 计划议程模板

1. 开场（5 mins）：回顾 Sprint 目标与议程
2. 产品负责人阐述高优先级条目（15 mins）
3. 团队确认产能并选取条目（20 mins）
4. 详细拆分任务与依赖确认（30 mins）
5. 整体认领与承诺仪式（10 mins）
6. 总结与风险确认（5 mins）

Sprint 回顾行动记录模板

6. 总结与进阶学习建议

扎实掌握 Sprint 计划与回顾，是 Scrum 团队走向高效自组织的基石。初期可能笨拙，但通过严格的节奏和持续的反思，团队将形成自己独特的改进文化。

建议进阶学习方向：

• 《Scrum 指南》精读，理解每个事件的正式定义。
• 学习“解放性结构”（Liberating Structures）等引导技术，丰富回顾深度。
• 研读《团队协作的五大障碍》，深刻理解信任与冲突在回顾中的角色。

开始你的第一个实战 Sprint 吧：先把下一次计划会议的时间定下来，然后严格按照本文的步骤实施，迭代后见证变化。