SCRUM的五个事件

转自：http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-7

Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其它会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是固定的，不能缩短或者延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。

事件一：Sprint

Sprint 是 Scrum 的核心，其长度(持续时间)为一个月或更短时间的限时，在这段时间内构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度通常保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。
Sprint由 Sprint计划会议、每日Scrum 站会、开发工作、 Sprint评审会议和 Sprint回顾会议构成。

在 Sprint 期间:

不能做出有害于 Sprint 目标的改变;
不能降低质量的目标;以及,
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会要澄清和重新协商。

每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会定义要开发什么，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品。

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。

取消 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。
如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大。

当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以必须经常性地重估。

取消 Sprint 会消耗资源，因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。

事件二：Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共同协作完成的。

Sprint 计划会议是限时的，以一个月的 Sprint 来说最多 8 小时为上限。对于较短的 Sprint，会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的目的。 Scrum Master 要教导 Scrum 团队遵守时间盒的规则。

Sprint 计划会议回答以下问题:
1. 接下来的 Sprint 交付的增量中要包含什么内容?

2. 要如何完成交付增量所需的工作?

话题一: 这次 Sprint 能做什么?
开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的 Sprint 可以完成什么工作。

在开发团队预测完这个 Sprint 中可交付的产品待办列表项之后，Scrum 团队草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。

话题二: 如何完成所选的工作?

在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中，开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

Sprint目标

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

事件三：每日Scrum站会

每日 Scrum 站会是一个以 15 分钟为限的事件，它让开发团队同步开发活动，并为接下了

的 24 小时制定计划。这需要检视上次每日站会以来的工作和预测下次每日站会之前所能够完成的工作。

每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。在会议上，每一个开发团队成员都需要说明:

昨天，我为帮助开发团队达成 Sprint 目标做了什么?
今天，我为帮助开发团队达成 Sprint 目标准备做什么?
是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?

开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

Scrum Master 强制执行每日 Scrum 站会规则——只有开发团队成员才能参加。
每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并

促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

事件四：Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

对于长度为一个月的 Sprint 来说，评审会议的限时为 4 小时。对于较短的 Sprint 来说，会议的时间会有所缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。

Sprint 评审会议包含以下内容:

产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议;
产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的;
开发团队演示“完成”的工作并解答关于所交付增量的问题;
产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话);
参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息;
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;同时，
为下个预期产品版本的发布评审时间表、预算、潜力和市场。

Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

事件五：Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个月的 Sprint 来说，会议的限时为 3 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加该会议。

Sprint 回顾会议的目的在于:

检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;
找出并加以排序做得好的和潜在需要改进的主要方面;同时,
制定改进 Scrum 团队工作方式的计划。

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完成”的定义的方式来计划提高产品质量。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和适应的正式机会。