（13.2.1）Scrum敏捷开发框架

• 零、敏捷宣言
  • 0.1 四种核心价值观
  • 0.2 十二条原则
  • 0.3 注意
• 一、 Scrum角色
  • 1.1 产品负责人
  • 1.2 开发团队成员
  • 1.3 ScrumMaster
• 二、Scrum基本工件
  • 2.1 产品待办事项列表（ Product Backlog）
    • 2.1.1 用户故事
      • 2.1.1.1 Invest特性
    • 2.1.1.2 优秀用户故事准则
  • 2.2 Sprint待办
  • 2.3 产品增量
  • 2.4 其他可见的进度指示
• 三、 Scrum活动或会议
  • 3.1 产品待办事项列表梳理
  • 3.2 Sprint计划会议
  • 3.3 每日Scrum会议
    • 3.4 Sprint评审会议
    • 3.5 Sprint回顾会议
    • 3.6 Scrum合作会议
• 四、Scrum价值观

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

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

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

零、敏捷宣言

0.1 四种核心价值观

• 个体与互动 高于 流程和工具
  赖于不同团队和团队中的个体之间的信任以及他们之间的合作方式

  • 团队确定该做什么，
  • 团队确定如何去实现
  • 然后由团队来完成
  • 团队发现前进道路上的障碍，并负责解决职责范围内的所有困难。
  • 团队也会与组织内的其他部门合作去解决团队职责范围外的困难

• 工作的软件 高于 详尽的文档
  团队每个Sprint都必须交付可工作的产品增量
  尽管还会有类似于分析、设计、测试的工作，可能需要文档记录下来，但是只有可工作的软件能帮助组织达到项目成功

• 客户合作 高于 合同谈判

• 响应变化 高于 遵循计划

0.2 十二条原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。善于掌控变化， 帮助客户获得竞争优势。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 对技术精益求精，对设计不断完善，将提高敏捷能力。
• 以简洁为本，极力减少不必要工作量。
• 最好的架构、需求和设计出自于自组织的团队。
• 团队定期地反思如何能提高成效，并依此调整团队的行为。

0.3 注意

• 即便是敏捷开发，也是需要项目章程
• 即便是敏捷开发，也是需要计划的，但是敏捷开发主张计划接近实际工作
• 敏捷开发中的进度计划可以通过估算故事点、优先级和开发速度来制定
• 敏捷开发的理想团队应该合理配置空间，使得成员之间面对面，没有或很少障碍物
• 用户故事不要超过2-3周的人工量
• Scrum的理想团队成员个数在5-9人
• 每日例会不要超过15分钟

一、 Scrum角色

Scrum团队包括三个角色

1.1 产品负责人

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

• 产品负责人：决定要做什么
  
  • 由1个人来担任，他负责在限定期限内拟定可能的最有价值的产品
  • 产品负责人可能需要其他人的支持，但他只能是1个人
  • 产品负责人维护产品待办事项列表（ Product Backlog），并确保大家都知道包括的内容以及优先级
  • 产品负责人通常是离项目的“业务层”最近的人，一般由组织指派来负责“把这个产品做出来”，而且通常期望他以最好的工作成果来满足所有的利益干系人
  • 产品负责人通过选择开发团队下一步应该做什么以及要推迟什么，来权衡范围和进度，以得到尽可能好的产品

1.2 开发团队成员

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

• 开发团队成员：通过一系列称为Sprint的短时间周期以增量式打造产品
  
  • 开发团队是由实现产品增量的专业成员组成，他们采用自组织的方式完成工作。对于项目而言，开发团队的成员是全职的
  • 开发团队成员需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量
  • 开发团队成员共同预测在1个Sprint能完成的工作量，并决定如何实现 (产品负责人准备1个有序的代办事项列表)

Sprint是一个固定的时间周期，长度可以是1周到四周，但越短越好。在每个Sprint中，Scrum团队会开发并交付1个产品增量
每个增量是1个可识别的，对产品功能有明显提升的，可操作的功能子集，符合明确的接受条件，并且质量标准达到了“完成的定义”

1.3 ScrumMaster

• ScrumMaster：一个仆人型领导，帮助团队和组织来让Scrum发挥最大效用
  
  • 作为Scrum团队的教练，帮助Scrum团队遵守他们的流程
  • 帮助产品负责⼈理解如何创建和维护产品待办事项列表（ Product Backlog）
  • 和开发团队一起发现并实施技术实践，确保团队在Sprint结束时能够完成工作
  • 注意团队前进的障碍已被清除
  • ScrumMaster培养团队的自组织能力。团队应该尽可能地独立解决问题
  • 确保团队内部和外部人员对Scrum有充分的理解，并保证Scrum被恰当地使用。
  • 帮助团队之外的人理解流程，并明确和团队的哪些交互是有益的，哪些不是。
  • ScrumMaster帮助每个人改进，使团队更加高效和有价值

二、Scrum基本工件

在敏捷项目中计划有几个层次：产品愿景、产品路线、发布计划类似于大版本要实现什么[产品待办事项列表]，冲刺计划(迭代)完成发布计划中的某些功能[Sprint待办事项列表]，每日计划包含当日应该完成的任务

-	产品待办事项列表	冲刺Sprint待办事项列表
所内内容	用户故事	任务
单位	用户故事点	小时
负责人	发起人、产品负责人(客户代表)	团队
包含在那个计划中	发布计划中	冲刺计划中

2.1 产品待办事项列表（ Product Backlog）

• 产品待办事项列表（ Product Backlog）：1个有关产品想法的有序列表，这些想法将按照其期望被实现的顺序排列
  
  • 它是所有需求的唯1来源。这意味着开发团队的所有工作都来自产品待办事项列表
  • 每个产品待办事项都包括描述和估算
  • 开始阶段它比较短小而模糊，随着时间的推移，逐渐变长，越来越明确
  • 通过《产品待办事项列表梳理活动》，即将被实现的产品待办事项会得到澄清，变得明确，粒度也拆得更细
  • 由产品负责人维护
  • 可能来自于产品负责人，团队成员，或者其它利益干系人

2.1.1 用户故事

一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。

2.1.1.1 Invest特性

• I dependent(独立的):

  • 一个用户故事对于另一个用户故事应该是独立的（尽可能的）。故事之间的依赖性使得增加了计划编制，确立有限级，故事估计这些工作非常困难。通常，可以通过组合用户故事或者分割用户故事来减少依赖性。

• N egotiable(便于沟通的):

  • 一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。

• V aluable(有价值的):

  • 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

• E stimable(可估计的):

  • 开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

• S mall(短小):

  • 一个好的故事应该在工作量上短小，描述具有代表性，而且不超过2-3人周的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。

• T estable(可测试的) :

  • 一个用户故事是可测试的来用于确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子：软件应该是易于使用的。

2.1.1.2 优秀用户故事准则

• 考虑每一个用户角色，从目标故事（高层次故事）开始衍生
• 切蛋糕原则：每个故事具有某种程度的完整性
• 编写封闭的故事，有明确的范围边界
• 卡片约束
• 根据时间来确定故事规模和精确度
• 不要过早涉及用户界面
• 有些需求并不是故事，可以使用其他的形式表达某些需求
• 故事里包括用户角色
• 一个用户故事只为一个角色编写
• 以主动语态编写
• 由客户编写
• 不需要编号，增加无谓的流程
• 有序号，表示优先顺序
• 故事卡用来提醒客户和开发的对话讨论，要简洁，尽量只有切人点提醒，不加入太多的细节

2.2 Sprint待办

事项列表（ Sprint Backlog）

• Sprint待办事项列表（ Sprint Backlog）：下个Sprint的详细开发计划
  
  • 一个需要在当前Sprint完成的且梳理过的产品待办事项，并包括了一个团队完成这些工作的计划
  • 反映了团队对当前Sprint⾥需要完成工作的预测
  • Scrum团队共同指定和维护
  • 有了Sprint待办事项列表后， Sprint就开始了，开发团队成员按照Sprint待办事项列表来开发新的产品增量

2.3 产品增量

• 产品增量：每个Sprint的必要产出。它是个集成好的产品版本，具备足够好的质量并在产品负责人需要时被交付出去
  
  • 每个Sprint都应该有新的产品增量。
  • 它的质量好到可以随时交付给客户。
  • 产品增量必须符合Scrum团队当前的“完成的定义”，它的每个部分都应该被产品负责人接受。

2.4 其他可见的进度指示

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

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

  • * 燃尽图和任务板是常⻅的展式进度的额外工件*
  • 燃尽图关注剩下还有多少工作未完成,应该是一个向下的曲线，表示随着剩余工作的完成，烧尽至0
  • 燃烧图关注已经完成了多少工作,应该是一个向上的曲线，表示随着已完成工作的增多，达到全量

• 交付产品增量时，需要依据共同认可的“完成”标准来确认完成。
• 每个Scrum团队的“完成的定义”不尽相同，随着团队的成熟，其范围将扩⼤，并且变得越来越严格
• “完成的定义”必须总是保证产品增量的质量足够好，从而达到可交付使用的状态：产品负责人可以选择随时发布它

三、 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的框架内，改进他们自己的流程

3.6 Scrum合作会议

合作会议允许不同的团队来参加，以协调团队之间的工作

四、Scrum价值观

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