Scrum指南

有Scrum创始人开发并维护的Scrum指南，游戏规则、如果Sprint目标过时，比如公司发展方向后者市场上或技术上的状况发生改变，这些变化都可能导致Srpint被取消。——某个Sprint对其所在环境失去了价值和意义，就应该被取消。

Scrum指南（游戏规则）

1、概述

Ken Schwaber和Jeff Sutherland创造了Scrum

用于开发、交付和持续支持复杂产品的一个框架

指南包含了Scrum的定义，包括角色、事件、工件，以及把他们组织在一起的规则

2、定义

定义

Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性的交付可能最高价值的产品

特点

轻量的

易于理解的

难以精通的

并不是一个过程、技术活决定性方法，倒不如说是一个框架，可以用各种不同的过程和技术，使得产品管理和工作技术的相对成效更加清晰显现，支持持续改进产品、团队和工作环境

应用

最初为了管理和开发产品

上世纪90年代初开始，在全球范围得到广泛应用

研究和识别可行的市场、技术和产品能力

开发产品和增强功能，频率高到一天发布多次

开发和支持云（在线、安全、按需）和其他运行环境

已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、学校、政府、市场营销、管理组织运营，一以及日常生活中

Scrum的精髓在于小团队

个体团队具有高灵活性和适应性

通过精妙的开发架构和目标发布环境来协作和互操作

理论

采纳一种迭代和增量式的方法来优化对未来的预测和控制风险

经验过程控制

透明

关键环节对于产品负责人显而易见→关键环节透明→制定统一标准

所有参与者谈及过程时都必须使用统一的术语

负责完成工作和检视结果增量的人必须对“完成”的定义有一致的理解

检视

检视Scrum的工件和完成Sprint目标的进展，发现不必要的差异

需要技能娴熟的检视者在工作中前面的执行，不应该频繁而阻碍工作本森

适应

发现过程中一个或多个偏离可接受范围，且导致产品不可接受，则必须对内容进行调整，且尽快执行

价值观

承诺、勇气、专注、开放和尊重

3、团队

跨职能的自组织团队

自己选择如何以最好的方式完成工作

拥有完成工作所需的全部技能

用来提供最佳的灵活性、创造力和生产力

一名产品负责人

职责是将开发团队开发的产品价值最大化

负责管理产品代办列表的唯一负责人

清晰地表达产品代办列表项

对产品代办列表进行排序，使其最好的实现目标和使命

优化开发团队所执行工作的架势

确保产品代办列表对所有人是可见、透明和清晰，显示Scrum团队下一步要做的工作

确保开发团队对产品代表列表项有足够深的了解

产品负责人可以亲自完成工作，或者让开发团队完成

所有人都必须尊重产品负责人的决定，没有人可以强迫开发团队按另一套需求开展工作

开发团队

负责在每个Sprint结束时交付潜在可发布且完成的产品增量

只有开发团队才能创建增量

特点

自组织的，没有人有权告诉开发团队应该如何把产品代办列表变成潜在可发布的功能增量

跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能

开发团队中每个成员也许有有特长和专注的领域，但是负责整个开发团队

Scrum不认可开发团队成员任何头衔，不管器承担何种工作（都叫开发人员）

Scrum不认可开发团队中所谓的子团队，无论其需要处理的领域是测试、架构、运维或业务分析

规模

足够小保持敏捷性，3~9人

小于3人，成员之间没有足够互动，生产力增长不会很大，可能会遭遇技能上的约束

超过9人，需要过多的协调沟通，产生太多负责

Scrum Master

负责帮助每个人理解Scrum理论、实践、规则和价值，根据Scrum指南中的定义来促进和支持Scrum

服务于产品负责人

理解并实践敏捷性

当被请求或需要时，引导Scrum事件

确保产品负责人懂得如何安排产品代办列表使其价值最大化

帮助Scrum团队理解为何需求清晰且简明的产品代办列表项

确保Scrum团队中每个人都尽可能的理解目标、范围和产品域

找到有效管理产品代办列表的技巧

理解在经验注意的环境中的产品规划

服务于开发团队

作为教练在自组织和跨职能方面给与开发团队指导

在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队

移除开发团队工作进展中的障碍

帮助开发团队创造高价值的产品

当被请求或需要时，引导Scrum事件

服务于组织

领导并作为教练指导组织采纳Scrum

在组织范围内规划Scrum的实施

帮助员工和利益相关者理解并实施Scrum和经验导向的产品开发

引发能够提升Scrum团队生产率的改变

与其他Scrum Master一起工作，增强组织中Scrum 应用的有效性

4、事件

Scrum使用固定的时间来产品规律性，减少Scrum之外的其他会议的必要，所有事件都有时间盒限定

一旦Spring开始，持续时间固定，不能缩短或延长；其他时间在改时间的目标达成之后可立即结束，确保时间被适当使用而不会造成过程中浪费

Sprint是Scrum的核心

长度未一个月或更短

若太长，则对要构建什么的定义可能会改变，增加负责性和风险

构建一个“完成”、可用的和潜在可发布的产品增量

在整个开发过程期间，Sprint的长度保持一致，前一个Sprint结束，下一个新的Sprint立即开始

在Sprint期间

不能做出有害Sprint目标改变

不能降低目标的质量

随着对信息掌握的增加，产品负责人余开发团队对范围内要做的事情加以澄清和重新写上

取消Sprint

只有产品负责人才有取消的权利

如果Sprint目标过时，比如公司发展方向后者市场上或技术上的状况发生改变，这些变化都可能导致Srpint被取消。——某个Sprint对其所在环境失去了价值和意义，就应该被取消

Sprint时间都很短，取消通常是不太合理的，会对Scrum团队造成重创，情况非常罕见

Sprint计划会议

一个月的Sprint的计划会议最长8h

接下来Sprint交付的增量中需包含什么内容

产品负责人讲解Sprint的目标及达成该目标所需完成的产品待办列表项，整个Scrum团队理解Sprint工作

输出

产品待办列表

最新的产品增量

开发团队在这个Sprint中能力的预测及开发团队以往的表现

开发团队自己决定选择产品代办列表项的数量，只有开发团队可以评估接下来Sprint可以完成什么工作

草拟一个Sprint目标

所选定的产品代办列表项会提供一个连贯一致的功能，就是Sprint目标

为开发团队提供指引，明确为什么要构建增量

如何完成交付增量所需的工作

这个Sprint要完成的产品待办列表+如何交付他们的计划→Sprint待办列表

产品负责人能够解释清楚所选定的产品代表列表项，并权衡

产品开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需的工作

Sprint计划会议中，开发团队已经挑选出足够的工作，来预估即将来的Sprint中能够完成

Sprint计划会议最后，开发团队规划处在Sprint最初几天内所要的工作，以一天或更少为一个单位

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

每日Scrum站会

一个15min的事件，Sprint的每一天都举行，在同一时间同一地点举行

增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速的做决策、提高开发团队的认知程度，是进行检视域适应的关键会议

开发团队为接下来的24h的工作制定计划；

开发团队通过每日Scrum站会，检视Sprint目标进度，检视完成Sprint待办列表的工作进度趋势

通过检视上次每日Scrum站会以来的工作和预测即将的Sprint工作来优化团队协作和效能

不同的凡是，有的以问题为道姓，有一基于更多的讨论

昨天，我为帮助开发团队达成Sprint目标做了什么

今天，我为帮助开发团队达成Sprint目标准备做什么

是否有任何障碍在阻碍我或开发团队达成Sprint目标

Scrum Master确保开发团队每日站会如期举行，但开发团队自己负责召开会议

站会是开发团队的内部会议，如果有开发团队之外的人出席，Scrum Master确保他们不会干扰会议进行

Sprint评审会议

一个月的Sprint，评审会议不超过4h

在Sprint快结束时举行，用以检视所交付的产品增量并按需体哦正产品待办列表

Scrum团队和利益相关者讨论这次Sprint中所完成的工作

非正式会议，不是进度汇报会议，演示增量的目的是为了获取反馈并促进合作

包含

参会者包含Scrum团队和产品负责人邀请的主要利益相关者

产品负责人说明哪些产品待办列表已经“完成”和哪些没有“完成”

开发团队讨论在Sprint期间哪些工作做的很好，遭遇的问题及如何解决的

开发团队演示“完成”的工作并解答关于所交付增量的问题

产品负责人讨论当前的产品待办列表情况，根据进度预测可能的目标交付日期

所有人就下一步工作进行探讨，为接下来的Sprint 计划会议提供有价值的信息输入

评审市场或潜在的产品使用方式所带来的有价值的改变

为下一个预期产品功能或产品能力版本的发布评估时间表、预算、潜力和市场

输出

一份修订后的产品待办列表，阐明很可能进入下一个Sprint的产品待变列表

Sprint回顾会议

一个月的Sprint，回顾会议不超过3h

检视自身并创建下一个Sprint改进计划的机会

目的

检视前一个Sprint中关于人、关系、过程和工具的情况如何

找出并加以排序做得好的和潜在需要改进的主要方面

制定改进Scrum团队工作方式的计划

输出

基于对资深检视做出适当调整，明确接下来的Sprint中需要实施的改进

5、工件

以不同的方式表现工作任务和价值，可以用来提供透明以及检视和使用的机会

产品待办列表

一份涵盖产品中已知所需每项内容的有序列表，是产品需求滨东的唯一来源

产品负责人管理产品待办列表的内容、可用性和排序

永远是不完整的

最早开发时候，列举最初所知以及理解最透彻的需求

随着产品及其应用环境的改变而严谨

动态的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用

属性

描述

次序

估算

价值

多个Scrum团队常常会一起参与同一个产品的开发，一个产品只有一个产品代办列表用于描述下一步产品开发工作，需要能够对产品待办列表进行分组的属性

产品待办列表精化

为其添加细节、估算和排序的动作，支持足够透明

精化工作占用开发团队不超过10%的产能

排序越高的产品待办列表比排序地的更清晰包含更多细节；排序月底，细节信息越少

能够被开发团队在一个Sprint中“完成”的产品代办列表成为“准备就绪”，将作为Sprint计划会议中待选产品列表项

监控目标实现的进度

产品负责人在每个Sprint的评审会议中必须跟踪剩余工作总量，比较这次剩余工作量域之前Sprint评审会时剩余的工作量，来评估在期望时间点完成目标的进度

多种不同趋势走向的时间被应用在预测进度方面，如燃尽图、燃烧图或者累计流图

Sprint待办列表

一组当前Sprint选出的产品待办列表项，加上交付产品增量和实现Sprint目标的计划

是开发团队对于下一个产品增量所需的功能及交付能够“完成”增量所需工作的预测

为了确保持续改进，至少包含一项在前次回顾会议中确定下来的高优先级的过程改进

在Sprint期间，只有开发团队可以改变Sprint待办列表；新工作出现时，需要加入到Sprint待办列表；党计划中某部分失去开发意义，则移除s

监控Sprint进度

开发团队至少每日Scrum站会时跟踪剩余工作的综合，预测达成Sprint目标的可能性

增量

是一个Sprint完成所有产品待办列表项目的综合，以及之前所有Sprint所产生的增量的价值总和

在Sprint最后，新增增量必须时“完成”的。增量时在Sprint结束时支持经验主义的、可检视的和已完成的产品组成部分

工件透明

工件状态完全透明，有效支持决定；不完全透明，做出的决定会有瑕疵

Scrum Master必须帮助每个人能够在遇到不透明的情况下采取最合适的实践

Scrum Master能够通过检视工件、嗅探模式、倾听周围的声音以及观察预期和实际结果之间的差异来发现不完全透明

Scrum Master的职责就是和Scrum团队以及组织一起合作增加工件的透明化

完成的定义

评估产品增量是否完成

指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项

每个增量都添加在之前的增量上，并且经过彻底的测试，确保整合在一起的所有增量都能工作