Scrum入门基础之敏捷 Agile Scrum框架精髓

Scrum的原则

敏捷宣言的价值观

Scrum是最著名的敏捷框架。它是敏捷宣言的价值观和原则背后的重要思想源泉， 这些价值观和原则也是所有敏捷方法的基础。具体内容请参敏捷宣言。

Scrum直接体现敏捷宣言的价值观:

个体与互动  高于 流程和工具。跟其它所有的敏捷框架和方法一样，Scrum直接依赖于不 同团队和团队中的个体之间的信任以及他们之间的合作方式。团队确定该做什么，团队确定如何去实现，然后由团队来完成。团队发现前进道路上的障碍，并负责解决职责范围内的所有困难。团队也会与组织内的其他部 合作去解决团队职责范围外的困难。这点十分关键，尝试应 Scrum却忽视团队共担职责，往往导致问题。

可工作的软件 高于 详尽的文档。Scrum要求每个Sprint都交付可g工ong作的、已经完成的产品增量，并把这个看作Sprint的主要产出物。尽管还会有类似于分析、设计、测试的 作， 可能需要 文档记录下来，但是只有可 作的软件能帮助组织达到项目成功。这点十分关键。Scrum团队每个Sprint都必须交付可工作的产品增量。

客户合作  高于 合同谈判。Scrum产品负责人是Scrum团队与产品最终用户之间，以及组 织内部需要该产品的其它相关部门之间最主要的联络点。产品负责人是团队的成员，他与其他团队成员一起合作来确定哪些需要完成。在合作中，产品负责人选择价值最高的下 批功能，并尽可能时刻确保产品具有最高的价值。这点十分关键。产品负责人需要跟团队充分合作。

响应变化  高于 遵循计划。Scrum的 切就是为了保证每个 都掌握 够的信息来对项 做出有利的决定。真实的、可以运行的产品增量才是项目进度的体现。让所有人都能够了解待办事项列表， 论是总体进度还是每个Sprint的进度总是透明的，问题和担忧被公开讨论并及时处理。这点十分关键。对于那些能够公开地“检视”现状，并根据实际情况进行“调整”的团队，Scrum会十分有效。对于那些不这样做的团队不会有效。

Scrum的价值观

Scrum中进 的所有工作都需要一个坚实的价值观基础，作为团队过程和原则的基础。通过团队合作和持续改进，Scrum在培养这些价值观的同时也依赖于它们。这些价值观是专注、勇气 、开放、承诺和尊重。

专注，由于我们在 段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。
勇气，因为我们不是单打独斗，我们能够感受到支持， 且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。
开放，在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。我们发现将担忧 说出来是 件好事，因为只有这样才能让这些担忧及时得到解决。

承诺，由于对自己的命运有更大的掌控，我们会有更坚定的信念去获得成功。
尊重，因为我们在一起工作，分享成功和失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的 。 如果整个组织让Scrum发挥它的效能，他们会从中发现益处，并开始理解为什么这些价值观是Scrum需要和积极倡导的。

Scrum框架

Scrum是一个用于打造产品的框架。当利益干系人需要一个产品时，Scrum就启动了。

Scrum是一个团队流程。Scrum团队包括三个角色，产品负责人，ScrumMaster和开发团队成 员。产品负责人决定需要做什么。ScrumMaster作为 个仆人型领导，帮助团队和组织来让Scrum发挥最大效力。开发团队通过一系列称为Sprint的短时间周期以增量的方式打造产品。Sprint是一个固定的时间周期， 度可以是 周到四周，但越短越好。在每个Sprint中，Scrum团队会开发并交付 个产品增量。每个增量是一个可识别的，对产品功能有明显提升 的，可操作的功能集，符合明确的接受条件，并且质量标准达到了“完成的定义”。

Scrum包括三个基本的工件，产品待办事项列表(Product Backlog)，Sprint待办事项列表 (Sprint Backlog)和产品增量。产品待办事项列表是个有关产品想法的有序列表，这些想法将按照其期望被实现的顺序排列。Sprint待办事项列表是下一个Sprint的详细开发计划。产品增量是每个Sprint的必要产出。它是个集成好的产品版本，具备足够好的质量并在产品负责人需要时被交付出去。除了这些工件以外，Scrum要求在团队和利益干系人之间保持信息透明。因此，Scrum团队会把当前的计划和进度可视化。

Scrum包括了五个活动或会议。他们是产品待办事项列表梳理，Sprint计划，每日Scrum，Sprint评审和Sprint回顾。

我们将在下面介绍这些工件和活动，以及整个Scrum周期的流程。

Scrum中的角色

角色:产品负责人(Product Owner)

产品负责人总是由一个人来担任，他负责在限定期限内拟定可能的最有价值的产品。这是通过管理流向团队的产品待办事项，选择并梳理这些事项来完成的。产品负责 维护产品待办 事项列表(Product Backlog)，并确保 家都知道包括的内容以及优先级。产品负责 可能 需要其他 的 持，但他只能是一个人。

并不是所有的事情都由产品负责人一个人负责。整个Scrum团队需要让团队变得尽可能的高效，改善他们的实践、提出正确的问题、帮助产品负责 等等。开发团队决定 个Sprint要做多少事情，并负责每个Sprint产出可 的产品增量。

然而，在Scrum中，产品负责人处在 个独特的位置。产品负责人通常是离项目的“业务 ”最近的 ， 一般由组织指派来负责“把这个产品做出来”， 且通常期望他以最好的 作成果来满 所有的利益干系 。要做到这些，产品负责人需要管理产品待办事项列表，并确保产品待办事项列表和它的进度可 。产品负责人通过选择开发团队下一步应该做什么以及要推迟什么，来权衡范围和进度，以得到尽可能好的产品。

角色:开发团队成员(Development Team)

开发团队是由实现产品增量的专业人士组成，他们采用自组织的方式完成工作。对于项目

，开发团队的成员是全职的。

Scrum要求开发团队成员由一批跨职能的人组成，他们拥有完成每个产品增量所需的全部技 能。

开发团队成员需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量。 产品负责 人准备一个有序的待办事项列表。开发团队成员共同预测在整个Sprint能完成的工作量，并决定如何实现。

角色:ScrumMaster

ScrumMaster是个“仆人型领导”，帮助Scrum团队遵守他们的流程。ScrumMaster必须对

Scrum框架有很好的理解并且有能力培训其他人去了解Scrum的微妙之处。

ScrumMaster帮助产品负责人理解如何创建和维护产品待办事项列表(Product Backlog)。 为了确保团队在Sprint结束时能够完成 作，他和开发团队一起发现并实施技术实践。他和整 个Scrum团队一起来演进完成的定义。

ScrumMaster的另一个职责是注意团队前进的障碍已被清除了。这些障碍可能来自团队的外 部， 如缺乏另一个团队的支持，也可能来自内部， 如产品负责人不知道如何恰当地准备 产品待办事项列表。

ScrumMaster培养团队的自组织能力。团队应该尽可能地独自解决问题。

作为Scrum团队的教练，ScrumMaster帮助团队执行Scrum的流程。他帮助团队更好地合作， 帮助他们理解Scrum框架，并且保护他们远离内部和外部干扰。他可以引导会议，帮助Scrum团队保持正确的方向，提高效率，并提升能力。

ScrumMaster负责确保团队内部和外部成员对Scrum有充分的理解，并保证Scrum被恰当地使 。他帮助团队之外的理解流程，并明 和团队的哪些交互是有益的，哪些不是。ScrumMaster帮助每个人改进，使团队更加有效和有价值。

工件:产品待办事项列表(Product Backlog)

产品待办事项列表是Scrum 的一个核心工件。产品待办事项列表是包含产品想法的一个有序列表，所有想法按照期待实现的顺序来排序。它是所有需求的唯一来源。这意味着开发团队 的所有工作都来自产品待办事项列表。每个功能想法，改善，缺陷修复，文档需求 —— 他 们需要做的每一点工作 —— 都是来于某个产品待办事项。每 个产品待办事项都包括描述 和估算。开始，产品待办事项列表是一个简短不定列表。它可以是模糊的或是具体的。通常情况下，开始阶段它较短和模糊，随着时间的推移，逐渐变长，越来越明确。通过产品待办事项列表梳理活动，即将被实现的产品待办事项会得到澄清，变得明确，粒度也拆得更小。

产品负责 为产品待办事项列表的维护负责，尽管产品负责人可能 —— 也应该 —— 创建产品待办事项列表，并保证其状态更新。产品待办事项可能来自于产品负责人，团队成员，或者其它利益干系 。

活动:产品待办事项列表梳理(Product Backlog Refinement)

产品待办事项通常会很多，也很宽泛， 且想法会变来变去、优先级也会变化，所以产品待办事项列表梳理是 个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:

保持产品待办事项列表有序;
把看起来不再重要的事项移除或者降级;
增加或提升涌现出来的或变得更重要的事项;
将事项分解成更小的事项;
将事项归并为更大的事项;
对事项进行估算

产品待办事项列表梳理的一个最大好处是为即将到来的下个Sprint做准备。为此，梳理时会特 别关注那些即将被实现的事项。需要考虑不少因素，这包括但不限于以下的内容:

理想情况下，下一个Sprint的备选事项都应该提升“商业价值”。
开发团队需要能够在 个Sprint内完成每 个事项。
每个人都需要清楚预期产出是什么。
产品开发决定了，有可能需要其它的技能和输出 。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动， 不单单是产品负责 。

活动:Sprint计划会议

每个Sprint都由一个限定时长的会议开始，这个会议称作Sprint计划会议。在这个会议中，

Scrum团队共同选择和理解在即将到来的Sprint中要完成的 作。

整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog)，产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时 的。Sprint计划会议推荐时 是Sprint中的每 周对应两 时或者更少(译者注: 如， 一个Sprint包含2个星期，则Sprint计划会议时 应为4个小时或者更少)。因为会议是限制时间的，Sprint计划会议的成功依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理部分重要的原因。

在Scrum中，Sprint计划会议有两部分:

1. 决定在Sprint中需要完成哪些工作;

2. 决定这些工作如何完成。

第一部分:需要完成哪些工作?

在会议的第一部分，产品负责人向开发团队介绍排好序的产品待办事项，整个Scrum团队共同 理解这些工作。

Sprint中需要完成的产品待办事项数量完全由开发团队决定。为了决定做多少，开发团队需要 考虑当前产品增量的状态，团队过去的工作情况，团队当前的产能 ，以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人，都不能给开发团队强加更多的工作量。

通常Sprint都有个目标，称作Sprint目标。这将十分有效地帮助 家更加专注于需要完成的 作的本质， 不必花太多精 去关注那些对于我们需要完成的 作并不重要的 细节。

第二部分:如何完成工作?

在会议的第二部分中，开发团队需要根据当前的“完成的定义” 起决定如何实现下 个产品增量。他们进足够的设计和计划，从 有信 可以在Sprint中完成所有工作。头一天的工作会被分解成 的单元，每个工作单元不超过1天。之后要完成的工作可以稍长些，以后再对它们进行分解。

决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。

在计划会议的第二部分，产品负责人可以继续留下来回答问题，以及澄清一些误解。不管怎样，团队应该很容易找到产品负责人。

Sprint计划会议的产出

Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识，并预期

在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的 作量。 总之:在Sprint计划会议中，开发团队

和产品负责人一起考虑并讨论产品待办事项，
确保他们对这些事项的理解
选择那些他们预测能完成的事项
创建足够详细的计划来确保他们能够完成这些事项。

最终产出的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

工件:Sprint待办事项列表(Sprint Backlog)

Sprint待办事项列表是 个需要在当前Sprint完成的且梳理过的产品待办事项，并包括了 个 团队完成这些 作的计划。该列表反映了团队对当前Sprint 需要完成 作的预测。

有了Sprint待办事项列表后，Sprint就开始了，开发团队成员按照Sprint待办事项列表来开发新 的产品增量。

开发

在Sprint中， 组织开发团队会根据Sprint计划会议中生成的Sprint待办事项列表，去实现每个产品增量。 组织意味着开发团队依据组织的所有标准，以及“完成的定义”，共担职责实现产品增量，开发团队 主决定如何去完成目标。

工件:产品增量(Increment)

产品增量是最重要的Scrum工件。每个Sprint都应该有新的产品增量。它的质量好到可以随时 交付给客户。产品增量必须符合Scrum团队当前的“完成的定义”，它的每个部分都应该被产品 负责 接受。

其他可见的进度指标

Scrum要求在团队内部和外部都保证透明性。产品增量是保证这种透明性的最重要 式，除此之外，Scrum团队还会根据需要去创建那些其他工件来让大家了解项目状态。燃尽图和任务板是常用的展示进度的额外工件。

协议: 完成的定义(Definition of Done)

交付产品增量时，需要依据共同认可的“完成”标准来确认完成。每个Scrum团队的“完成的定 义”不尽相同，随着团队的成熟，其范围将扩展，并且变得越来越严格。

“完成的定义”必须总是保证产品增量的质量足够好，从而达到可交付使 的状态:产品负责 可以选择随时发布它。产品增量包括先前所有增量中的功能，并且被充分测试，以确保所有已完成的产品待办事项仍然可以一起正常工作。

活动:每日Scrum会议

开发团队是自组织的。开发团队通过每 Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的地点召开。每 个开发团队成员需要提供以下三点信息:

从上一个每日Scrum到现在，我完成了什么？ 从现在到下一个每 Scrum，我计划完成什么？有什么阻碍了我的进展？

每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队 会在每 Scrum之后马上开会处理他们遇到的任何问题。

每日Scrum既不是向管理层汇报，也不是向产品负责人或者ScrumMaster汇报。它是个开发 团队内部的沟通会议，来保证他们对现状有一致的了解。只有Scrum团队的成员，包括ScrumMaster和产品负责人，可以在会议中发生。其他感兴趣的可以来旁听。在必要时， 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的目标。

每日Scrum是Scrum的一个关键组成部分，它可以带来透明性，信任和更好的绩效。它能帮助 快速发现问题，并促进团队的自组织和协作。所有Scrum会议都是限定时间的。每日Scrum通 常不超过15分钟。

活动:Sprint评审会议

Sprint结束时，Scrum团队和相关成员一起评审Sprint的产出。所有Scrum会议都是限定时间 的，Sprint评审会议的推荐时长是Sprint中的每周对应1个小时(译者注: 如，每个Sprint包含2个星期，则Sprint评审会议时长为2个小时)。

讨论围绕着Sprint中完成的产品增量。由于Sprint的产出会涉及到一些人的“利益”，因此一个明 智的做法是邀请他们参加这个会议，这会很有帮助。这个会议是个非正式的会议，帮助大家了解我们没有前进展到哪 ，并一起讨论我们下 步如何推进。每个人都可以在Sprint评审会议 上发表意 。当然，产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表 (Product Backlog)。

团队会找到他们的方式来开Sprint评审会议。通常会演示产品增量，整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表的状态、可能的完成周期以及在这些周期前能完成什么。

Sprint评审会议向每个人展示了当前产品增量的概况。因此，通常都会在Sprint评审会议中调整产品待办事项列表。

活动:Sprint回顾会议

在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及具体做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。所有的Scrum会议都是限定时间的，Sprint回顾会议的推荐时 是Sprint中的每1周对应1个小时(译者注: 如， 1个Sprint包含2个星期，则Sprint回顾会议时为2个小时)。

Scrum团队总是在Scrum的框架内，改进他们的流程。

去芜存菁，不断重复。

从这里开始，每个Sprint都会不断地重复Scrum周期。

总之，Scrum团队成员(包括产品负责人、开发团队，以及ScrumMaster) 起合作完成一系列的产品增量，他们采用称为Sprint的短时间周期。每个产品增量符合产品负责人的接受条件，并满 团队的“完成的定义”。所有工作来自于产品待办事项列表(Product Backlog)。Sprint总是从Sprint计划会议开始，团队在会议中制定出Sprint待办事项列表(Sprint Backlog)。团队自组织地去开发，利用每 Scrum会议来协调并确保团队产出最好的产品增量。团队通过产品待办事项列表梳理来为下个Sprint计划会议做准备。在Sprint结束时会有Sprint评审会议以及Sprint回顾会议，来审视产品以及团队流程。

V 2012.12.13 ©2012 Scrum Alliance,Inc

翻译：李国彪，滕振宇，姚若舟，张博超，李丁山  2013年2月