The Scrum Framework — 第二版

本章保留第二版的历史与实践教学语境。下方目录也提供第三版课程。

---

Scrum示例：面向优秀敏捷团队的真实Scrum案例

本文介绍一个Scrum方法案例，希望启发您的团队、其他业务利益相关者及项目相关人员。我们见过许多企业虽有受过培训的Scrum专业人士，却因经验不足，在日常Scrum运作和产品实现中遇到挑战。

这通常阻碍团队达到最佳速率，以及按时、在预算内发布成果。这正说明本Scrum案例的重要性。

因此，本文帮助您理解Scrum框架全貌：从构建为业务、产品与服务创造前所未有价值，并为客户带来广泛敏捷体验的流程，到配置和运用Scrum燃尽图，以提升并维持团队速率。

通过此案例，我们帮助您理解Scrum团队如何运作，以及能为组织带来什么。数据显示，多数企业的团队由Product Owner、Scrum Master和开发人员组成，共同构成Scrum Team，在称为Sprint的短迭代中交付有价值的产品增量。这种迭代方式支持灵活性、适应性和更快反馈。

此Scrum方法示例的主要人物包括：

• Alex，Scrum Product Owner。
• Frank，Scrum Master。
• Scrum Team。

首个Sprint开始之前

Alex被任命为新软件开发项目的Scrum Product Owner。最初任务之一是启动需求工程。他记录最重要的用例，并与架构师、客户代表和其他利益相关者讨论。收集高层级用例与需求后，他将其写入 Scrum Product Backlog ，并与架构师及资深开发人员开展估算与排序。之后，所有Product Backlog条目都有初始粗略估算与优先级。他开始将高层级需求拆成更细的用户故事，再依据清单召集首个Sprint Planning会议。

Scrum入门：贯穿不同阶段与Sprint的真实案例

Sprint 1 - 第0天

Sprint Planning中，Alex按优先级从高到低介绍Product Backlog条目。团队澄清未决问题，并逐项讨论容量、所需知识及其他条件是否齐备。随后承诺在本Sprint结束前完成故事1、2、3、6、7和8。由于部分技术基础设施尚未就绪，条目4和5无法在本Sprint实现。

Sprint Planning之后，Scrum Master Frank召集团队确定承诺条目的实现细节，将任务写在已准备好的Sprint任务看板卡片上。现在，每位 Scrum Team 成员选择要开展的任务。

Scrum Team实用提示：

Product Owner Alex在组织中领导新软件项目，如同指挥每个人各司其职的乐团。他的跨职能角色责任重大，专注建立自组织敏捷软件开发框架，持续改进。这并非通用方案，而是指引开发人员的既定路线。他如公司脉搏，确保最终产品满足客户需要。这种敏捷方式不断迭代，推动产品和方法持续完善。

随后，Alex使用用户故事推进估算与排序（更多内容参见 Scrum用户故事），并使用故事点进行相对估算。Kanban式可视化让所有成员看见任务与工作流，为此提供补充。全部Product Backlog条目由此获得初始估算和优先级。Alex借助项目管理经验，将高层级需求拆为以用户为中心的故事，转化为可交付的小块。故事具体展示客户所需，指出实现项目目标的路径。他依据清单召开首个Sprint Planning，推动开发团队紧密协作。

Sprint 1 - 第1天

早上，团队聚集开展Daily Scrum。每人简述进展、更新Sprint任务卡的剩余小时估算、说明当天计划与障碍。一名成员需要新的软件工具许可证。Frank检查其他人是否有同样问题，并承诺会后处理。15分钟后，大家回去工作。

会后，Frank更新Sprint燃尽图，再联系软件供应商订购许可证，转交给需要的人员。

Scrum Team实用提示：

Sprint Planning期间，Alex按优先级介绍Product Backlog。他有组织职责，确保每个人理解项目总体目标。团队站会促进开放讨论，澄清角色并解决潜在问题。

Scrum Master Frank在多元团队中同样发挥关键作用，必要时帮助每日站会聚焦Sprint Goal。开发人员自主拥有计划并协作选择任务，Frank不会分配工作。

Sprint 1 - 第2天

早上团队再次开展Daily Scrum。下午，一名成员不确定某用户故事细节，联系Product Owner Alex讨论未决点。明确该做什么后，便继续实现。

Sprint 1 - 第28天

首个Sprint最后一天，Frank邀请团队参加Sprint Review。团队准备了装有当前软件实现的机器。Alex坐在机器前，检查实现是否符合预期、功能是否按要求记录。评审结束时，他得出结论：

• 故事1、2、6和7按预期完成。
• 故事3未按时完成，完全没有展示。
• 故事8有些地方需要重构。

下午，团队开展Sprint Retrospective，讨论Sprint中做得好和可改进之处。团队反馈对整体系统架构了解不足，Frank负责邀请系统架构师作更详细介绍。

Scrum方法示例

Scrum Team实用提示：

首个Sprint最后一天，Frank带领团队开展Sprint Review。持续协作产生了有形原型，体现团队的承诺与努力。

下午，团队开展Sprint Retrospective，交流进展见解，重新审视未来Sprint需改进的方面。这是敏捷方式的关键要素，为整个项目提供重大价值。

规划下个Sprint时，Alex的重要作用再次显现。他依据近期客户会议添加Product Backlog条目。第二个Sprint开始后，团队协作、透明与有效项目管理继续推动这个以信息为基础的团队走向成功。

Sprint 2 - 第1天

Alex根据近期客户会议添加Product Backlog条目，也添加故事8的重构工作。随后邀请团队参加Sprint 2的Sprint Planning。在Frank指导下，团队讨论并承诺故事，第二个Sprint由此开始。

Scrum Team实用提示：

第二个Sprint将团队所学付诸实践：修订的Product Backlog反映客户反馈，重新考虑未完成工作，并继续围绕下一个Sprint Goal协作。

希望培养高效、高绩效Scrum团队的组织，必须学习示例与案例研究。分析真实情境带来成功实施的宝贵见解，同样重要的是识别常见陷阱。借鉴案例，团队可更快成为优秀团队，运用最佳实践、避开潜在错误，在Scrum实践中快速取得成果。

敬请关注更多真实场景与案例，进一步加深对Scrum框架及其实践应用的理解。