（13.2.1）Scrum敏捷开发框架

Scrum角色

Scrum基本工件

Scrum活动或会议
1 产品待办事项列表梳理

2 Sprint计划会议

3 每日Scrum会议

4 Sprint评审

5 Sprint回顾

敏捷宣言的价值观

Scrum的价值观

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

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

Scrum要求在团队和利益干系⼈之间保持信息透明。因此， Scrum团队会把当前的计划和进度可视化

1. Scrum角色

Scrum团队包括三个角色

产品负责人：决定要做什么

由1个人来担任，他负责在限定期限内拟定可能的最有价值的产品

产品负责人可能需要其他人的支持，但他只能是1个人

产品负责维护产品待办事项列表（ Product Backlog），并确保大家都知道包括的内容以及优先级

产品负责人通常是离项目的“业务层”最近的人，一般由组织指派来负责“把这个产品做出来”，而且通常期望他以最好的工作成果来满足所有的利益干系人

产品负责人通过选择开发团队下一步应该做什么以及要推迟什么，来权衡范围和进度，以得到尽可能好的产品

并不是所有的事情都由产品负责人1个人负责。整个Scrum团队需要让团队变得尽可能的高效，改善他们的实践、提出正确的问题、帮助产品负责人等等。

开发团队决定1个Sprint要做多少事情，并负责每个Sprint产出可用的产品增量。

开发团队成员：通过一系列称为Sprint的短时间周期以增量式打造产品

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

开发团队成员需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量

开发团队成员共同预测在1个Sprint能完成的工作量，并决定如何实现 (产品负责人准备1个有序的代办事项列表)

Sprint是一个固定的时间周期，长度可以是1周到四周，但越短越好。在每个Sprint中，Scrum团队会开发并交付1个产品增量

每个增量是1个可识别的，对产品功能有明显提升的，可操作的功能子集，符合明确的接受条件，并且质量标准达到了“完成的定义”

ScrumMaster：一个仆人型领导，帮助团队和组织来让Scrum发挥最大效用

作为Scrum团队的教练，帮助Scrum团队遵守他们的流程

帮助产品负责⼈理解如何创建和维护产品待办事项列表（ Product Backlog）

和开发团队一起发现并实施技术实践，确保团队在Sprint结束时能够完成工作

注意团队前进的障碍已被清除

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

确保团队内部和外部人员对Scrum有充分的理解，并保证Scrum被恰当地使用。

帮助团队之外的人理解流程，并明确和团队的哪些交互是有益的，哪些不是。

ScrumMaster帮助每个人改进，使团队更加高效和有价值

2. Scrum基本工件

Scrum包括三个基本的工件

产品待办事项列表（ Product Backlog）：1个有关产品想法的有序列表，这些想法将按照其期望被实现的顺序排列

它是所有需求的唯1来源。这意味着开发团队的所有工作都来自产品待办事项列表

每个产品待办事项都包括描述和估算

开始阶段它比较短小而模糊，随着时间的推移，逐渐变长，越来越明确

通过《产品待办事项列表梳理活动》，即将被实现的产品待办事项会得到澄清，变得明确，粒度也拆得更细

由产品负责人维护

可能来自于产品负责人，团队成员，或者其它利益干系人

Sprint待办事项列表（ Sprint Backlog）：下个Sprint的详细开发计划

一个需要在当前Sprint完成的且梳理过的产品待办事项，并包括了一个团队完成这些工作的计划

反映了团队对当前Sprint⾥需要完成工作的预测

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

产品增量：每个Sprint的必要产出。它是个集成好的产品版本，具备足够好的质量并在产品负责人需要时被交付出去

每个Sprint都应该有新的产品增量。

它的质量好到可以随时交付给客户。

产品增量必须符合Scrum团队当前的“完成的定义”，它的每个部分都应该被产品负责人接受。

其他可见的进度指示

Scrum要求在团队内部和外部都保证透明性，产品增量是保证这种透明性的最重要方式

除此之外， Scrum团队还会根据需要去创建一些其他工件来让大家了解项目状态

燃尽图和任务板是常⻅的展式进度的额外工件

交付产品增量时，需要依据共同认可的“完成”标准来确认完成。

每个Scrum团队的“完成的定义”不尽相同，随着团队的成熟，其范围将扩⼤，并且变得越来越严格

“完成的定义”必须总是保证产品增量的质量足够好，从而达到可交付使用的状态：产品负责人可以选择随时发布它

3. Scrum活动或会议

3.1 产品待办事项列表梳理

产品待办事项通常会很大，也很宽泛，而且想法会变来变去、优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动

包含但不限于以下的内容：

保持产品待办事项列表有序

把看起来不再重要的事项移除或者降级

增加或提升涌现出来的或变得更重要的事项

将事项分解成更小的事项

将事项归并为更大的事项

对事项进行估算

产品待办事项列表梳理的最大好处是为即将到来的几个Sprint做准备。为此，梳理时会特别关注那些即将被实现的事项

需要考虑不少因素，这包括但不限于以下的内容：

理想情况下，下一个Sprint的备选事项都应该提升“商业价值”。

开发团队需要能够在一个Sprint内完成每一个事项

每个人都需要清楚预期产出是什么

产品开发决定了，有可能需要其它的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动，而不单单是产品负责人

3.2 Sprint计划会议

每个Sprint都由一个限定时间的会议开始，这个会议称作Sprint计划会议。在这个会议中，Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

- 所有的Scrum会议都是限定时⻓的。 Sprint计划会议推荐时⻓是Sprint中的每一周对应两个时或者更少

因为会议是限制时间的， Sprint计划会议的成功十分依赖于产品待办事项列表的质量

- 整个团队都要参加Sprint计划会议

- 针对排好序的产品待办事项列表（ Product Backlog），产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情

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

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

决定在Sprint中需要完成哪些工作；

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

Sprint中需要完成的产品待办事项数目完全由开发团队决定

做多少工作只能由开发团队决定。

产品负责人或任何其它人，都不能给开发团队强加更多的工作量。

为了决定做多少，开发团队需要考虑当前产品增量的状态，团队过去的工作情况，团队当前的生产能力，以及排好序的产品待办事项列表

通常Sprint都有个目标，称作Sprint目标

决定这些工作如何完成

开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量

进行足够的设计和计划，从而有信心可以在Sprint中完成所有工作

头几天的工作会被分解成小的单元，每个工作单元不超过1天。之后要完成的工作可以稍大些，以后再对它们进行分解

产品负责人可以继续留下来回答问题，以及澄清⼀些误解。不管怎样，团队应该很容易找到产品负责人

Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识，并预期在一个合理的条件范围内完成它们。

开发团队预测并共同承诺他们要完成的工作量

总之：在Sprint计划会议中，开发团队

和产品负责人一起考虑并讨论产品待办事项，

确保他们对这些事项的理解，

选择一些他们预测能完成的事项，

创建足够详细的计划来确保他们能够完成这些事项

产出《Sprint待办事项列表（ Sprint Backlog）》

3.3 每日Scrum会议

开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开

每个开发团队成员需要提供以下三点信息：

从上一个每日Scrum到现在，我完成了什么；

从现在到下一个每日Scrum，我计划完成什么；

有什么阻碍了我的进展。

每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。

通常，许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题

每日Scrum既不是向管理层汇报，也不是向产品负责人或者ScrumMaster汇报

它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解

每日Scrum是Scrum的一个关键组成部分，它可以带来透明性，信任和更好的绩效。能帮助快速发现问题，并促进团队的自组织和自立

所有Scrum会议都是限定时⻓的。每日Scrum通常不超过15分钟

3.4 Sprint评审

Sprint结束时， Scrum团队和相关人员一起评审Sprint的产出。

所有Scrum会议都是限定时间的， Sprint评审会议的推荐时长是Sprint中的每一周对应2个小时

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

讨论围绕着Sprint中完成的产品增量

由于Sprint的产出会涉及到一些人的“利益”，因此一个明智的做法是邀请他们参加这个会议，这会很有帮助

这个会议是个非正式的会议，帮助大家了解我们当前进展到哪⾥，并一起讨论我们下一步如何推进

每个人都可以在Sprint评审会议上发表意见

产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表（ Product Backlog）

团队会找到他们自己的方式来开Sprint评审会议

通常会演示产品增量

整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现

还会讨论产品待办事项列表的状态、可能的完成工期以及在这些工期前能完成什么

3.5 Sprint回顾

Sprint回顾会议的推荐时间是Sprint中的每1周对应1个小时

在每个Sprint结束后， Scrum团队会聚在一起开Sprint回顾会议，目的是回顾下团队在流程、人际关系以及工具方面做得如何

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

4. 敏捷宣言的价值观

个体与互动 高于 流程和工具

赖于不同团队和团队中的个体之间的信任以及他们之间的合作方式

团队确定该做什么，

团队确定如何去实现

然后由团队来完成

团队发现前进道路上的障碍，并负责解决职责范围内的所有困难。

团队也会与组织内的其他部门合作去解决团队职责范围外的困难

工作的软件 高于 详尽的文档

团队每个Sprint都必须交付可工作的产品增量

尽管还会有类似于分析、设计、测试的工作，可能需要文档记录下来，但是只有可工作的软件能帮助组织达到项目成功

客户合作 高于 合同谈判

响应变化 高于 遵循计划

5. Scrum的价值观

专注：一段时间内只专注于少数件事情

勇气

公开

承诺

尊重