（13.2.1）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的价值观

• 专注：一段时间内只专注于少数件事情
• 勇气
• 公开
• 承诺
• 尊重