---

通过真实案例学习 Scrum！答案可能让你惊讶！

首个 Sprint 开始前

Alex 是新软件项目的产品负责人，首批任务之一是评估并识别需求， 以交付客户期望的业务价值。

他必须确保客户获得 实现具体业务结果所需的正确软件。 他记录关键用例，与架构师、客户代表及其他业务和 IT 相关方讨论。（参阅我们的 Scrum示例)

汇总高层用例及需求后，他把它们写入 Scrum Product Backlog ，并与团队开展估算和排序。结果，所有产品待办事项都得到 初步粗估及优先级。

Scrum Master Anna 确保大家使用共同语言，让产品负责人、成员和相关方 与预期目标一致。 使他们 充分理解可能陌生的概念， 例如用例、待办列表、Sprint。最重要的是， 在工作中正确应用 Scrum 开发交付流程。

Alex 开始把高层需求拆成较小故事初稿，依据清单召集首次规划会。

Sprint 1 - 第0天

在 Sprint 规划会中，Alex 从高到低介绍待办事项。团队提问澄清，逐项讨论是否有足够能力和知识完成交付，并确保 Sprint 开始前所需人员和技术资源到位。 必须确认成功交付功能所必需的前提和依赖已满足。

在 Sprint 规划会（“做什么”部分）中，开发人员预测能完成故事 1,2,3,6,7 和 8，支持已商定目标。因此将这些故事从产品待办列表移到 Sprint Backlog。故事 4 和 5 因必要基础设施尚未到位，无法在本次完成。

“做什么”结束后，Anna 邀请团队 深入确定如何实现所承诺故事（“怎么做”部分）。识别的任务记在卡片上，放进 Sprint 待办列表。现在成员可以选择任务并开始工作。

Sprint 1 - 第1天

早上，开发人员聚集参加 每日 Scrum。每个人 简短清楚地说明 已有成果，更新卡片上的剩余投入，介绍当天计划和妨碍任务的障碍。

今天 Melinda 提出开发环境许可证有问题。Anna 检查其他成员是否同样受影响，并确认会后处理。约 15 分钟 后，每日 Scrum 结束，大家继续工作。

随后 Anna 更新 Sprint 燃尽 图，显示本次进展。再打给供应商，购买缺少的许可并交给 Melinda。

Scrum 入门：跨多个阶段和 Sprint 的真实案例

Sprint 1 - 第2天

早上开发人员再次聚集参加 每日 Scrum。下午 James 不确定某故事预期结果，联系 Alex 讨论并确保正确理解。明确如何推进后，他继续实施。

Sprint 1——第 6 天

当天再次从每日 Scrum 开始。Anna 注意到可能超过 15 分钟，因为成员在讨论数据库查询优化。她提醒， 每日 Scrum 不是长谈技术，而是检查 Sprint 目标进展并调整开发人员计划.

会后 Alex 告知 Anna，客户提出新需求，可能影响当前和后续 Sprint。Anna 礼貌提醒， 变化不能危及 Sprint 目标。开发人员和产品负责人可随学习澄清、协商范围，而非把每个选定故事当不可变承诺。 因此 Anna 安排 待办列表细化会 于下午举行，让 Alex 介绍新需求。

会上，团队支持 Alex 理解故事如何符合整体开发计划，以及初步任务拆分、估算和排序.

Sprint 1——第 10 天

终于来到首个 Sprint 最后一天。Anna 邀请团队参加 Sprint 评审会。团队已准备非生产服务器，运行最新可交付软件增量。

Alex 与客户相关方 Rich 先生坐在软件图形界面前，验证 实现是否符合期望 ，以及当前应用情况的文档是否充分。

评审结束时，Alex 总结：

• 团队按承诺和期望交付故事 1,2,6 和 7。
• 故事 3 未按时完成，也未演示。它返回产品待办列表重新排序，剩余工作可在下一规划中选择。
• 故事 8 未满足共同 DoD，返回产品待办列表，澄清验收条件和剩余任务后，再决定何时选择。

Alex 和客户相关方 Rich 先生 向团队简短说明 即将发生的需求变化、挑战，以及 软件整体策略应发展的方向。Rich 感谢团队的努力与承诺，离开房间。

评审后，团队一起参加 Sprint Retrospective会议，讨论本次成功和可改善之处，改进未来预测，避免故事 3 和 8 的问题重演。回顾发现团队不够了解整体系统架构。Anna 承担协调任务，请架构师在下一 Sprint 开始时指导团队。

Sprint 2 - 第1天

Alex 根据最近客户会议不断增加产品需求，并在保留共同 DoD 的前提下，澄清故事 8 的验收条件和剩余工作，让团队更清楚预期结果。

随后邀请团队规划 Sprint 2。大家商定目标，开发人员选择和规划相应故事。Anna 帮助确保会议有效，第二个 Sprint 开始。