Scrum 事件
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。
一旦Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。
Scrum框架的有五个著名事件：
1）Sprint Planning meeting（Sprint计划会议）
2）Daily Scrum meeting（Scrum每日站会）
3）Sprint Review meeting（Sprint评审会议）
4）Sprint Retrospective meeting（Sprint回顾会议）
5）Product Backlog Refinement meeting（待办事项梳理会议）
在实际应用中如何使用？本文通过列表形式进行总结，从以下几个维度来比较。
比较维度：
1.为什么要做（Why）？
2.谁来做（Who）？
3.什么时候做（When）？
4.做什么或怎么做（What/How）?
5.持续时间多久（How Long）？
6.输入是什么（Input）？
7.输出是什么（Output）？
具体事件比较：
Sprint Planning | |
|---|---|
Why | Sprint 中要做的工作在 Sprint 计划会议中来做计划。 |
Who | Scrum团队（包括开发团队、ScrumMaster以及产品负责人） |
When | Sprint开始 |
What/How | Part1 - 开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该 目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。在 Sprint 计划会议中，Scrum 团队还草拟一个 Sprint 目标。 Part2 - 在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定 如何在 Sprint 中把这些功能构建成“完成”的产品增量。开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。 |
How Long | 一个月（4周）的Sprint上限是8小时；2周的Sprint上限是4小时等 |
Input | 产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。 |
Output | Sprint 目标、Sprint待办列表 |
Daily Scrum | |
|---|---|
Why | 开发团队展示进度；开发团队每日检视进度，并根据具体情况进行调整。 |
Who | 开发团队 |
When | 每日 Scrum 站会在同一时间同一地点举行 |
What/How | 在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队 协作和性能。每日站会可能会回答如下3个问题（举例）： • 昨天，我为帮助开发团队达成 Sprint 目标做了什么? • 今天，我为帮助开发团队达成 Sprint 目标准备做什么? • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标? |
How Long | 15分钟为上限 |
Input | Sprint目标，及每日工作进展 |
Output | 更新后的Sprint待办列表，及问题（风险）更新 |
Sprint Review | |
|---|---|
Why | 检视所交付的产品增量并按需调整产品待办列表。演示增量的目的是为了获取反馈并促进合作。 |
Who | Scrum团队（包括开发团队、ScrumMaster以及产品负责人）及干系人 |
When | Sprint 快结束时举行 |
What/How | Sprint 评审会议包含以下内容: • 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议; • 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”; • 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的; • 开发团队演示“完成”的工作并解答关于所交付增量的问题; • 产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的目标交付日期(如果有需要的话); • 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下来的Sprint 计划会议提供有价值的输入信息; • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变; 同时， • 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。 |
How Long | 一个月（4周）的Sprint上限是4小时；2周的Sprint上限是2小时等 |
Input | Sprint内“完成”的产品增量，Sprint待办列表，产品待办列表 |
Output | 更新后的产品待办列表 |
Sprint Retrospective | |
|---|---|
Why | Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。Sprint 回顾会议的目的在于: • 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何; • 找出并加以排序做得好的和潜在需要改进的主要方面; 同时， • 制定改进 Scrum 团队工作方式的计划。 |
Who | Scrum团队（包括开发团队、ScrumMaster以及产品负责人） |
When | Sprint评审会议结束后，下一个Sprint计划会议前 |
What/How | 回顾会套路：1. 设定场景2. 收集数据3. 产生洞察4. 决定做什么（行动计划）5. 结束 |
How Long | 一个月（4周）的Sprint上限是3小时；2周的Sprint上限是1.5小时等 |
Input | Sprint内的数据（客观数据和主观数据） |
Output | 下一个Sprint要实施的改进行动 |
Product Backlog Refinement | |
|---|---|
Why | 为接下来1-2 Sprint 做准备 |
Who | Scrum团队（包括开发团队、ScrumMaster以及产品负责人）及干系人 |
When | Sprint进行中，团队决定具体时间 |
What/How | 为产品待办列表项增添细节、估算、拆分和排序的动作。 |
How Long | 不超过开发团队10%的时间 |
Input | 当前的产品待办列表 |
Output | 更新后的产品待办列表 |
总结：
我们在实际执行敏捷开发过程中，通常会围绕这几个会议展开敏捷Sprint工作。有部分人会觉得Scrum敏捷框架中的会议是否会占用过多的开发时间？我们以一个两周的sprint来举例，通常整个会议过程，不会超过：8小时，或者会更短。在形成期的敏捷团队中，Scrum Master精力主要会花在对PO、开发团队的具体工作指导，以期达成产品Sprint目标共识，在经过一定周期的Sprint迭代后，逐渐形成稳定的团队Sprint交付能力，不断引进新的工具，提高持续集成能力，提升开发团队从T型人才到全栈工程师的转变，以稳定的团队形态持续提升并逐渐稳定交付能力。
