本书概览
目的
Ken Schwaber 和Jeff Sutherland 创造了Scrum，并编写该指南，包含了定义、事件、角色，以及把他们组织在一起的规则
定义
Scrum是一个框架，人们用此框架解决复杂的自适应难题，同时高效并创造性的交付最高价值的产品。
轻量的、易于理解的、难以精通的
应用
广泛用于产品、服务和大型组织管理。在迭代和增量式的知识迁移中，特别有效。
Scrum精髓在于小团队，个体团队具有高度灵活性和适应性
理论
基于经验过程控制理论，或称为经验主义，主张知识源自实际经验以及当前已知情况下做出的决定所获得。
采用迭代和增量式方法来优化对未来的预测和控制风险。
经验过程控制的三大支柱：透明、检视、适应
透明
过程中关键环节对产出负责人必须显而易见，统一标准，统一理解。
如：统一术语定义
检视
需常检视scrum工件和完成Sprint目标的进展，以便发现不必要的差异。
检视不应过于频繁而阻碍工作本身，监视者技能娴熟利于执行
适应
检视发现偏差或不被接受的情况，对过程或过程化内容加以调整
5个正式事件
Sprint
Sprint 计划会议
每日Scrum站会
Sprint评审会议
Sprint回顾会议
Scrum价值观
五大价值观
承诺、勇气、专注、开放、尊重
人们致力于实现Scrum团队的目标
成员有勇气去做正确的事并处理棘手的问题
专注于Sprint工作和Scrum团队的目标
Scrum团队及其利益攸关者同意将所有工作和执行工作上的挑战进行公开
Scrum团队成员相互尊重，彼此是有能力和独立的人
Scrum 团队
产品负责人、开发团队、Scrum Master
Scrum 团队是跨职能自组织团队，团队成员选择如何以最好的方式完成工作；团队拥有完成工作所需的全部技能
产品负责人
职责：将开发团队开发的产品价值最大化
负责管理产品待办列表的唯一负责人，产品待办列表的管理包括：（可亲自完成也可让团队成员完成）
清晰的表述产品待办列表
对产品待办列表进行排序，使其最好的实现目标和使命
优化开发团队所执行工作的价值
确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作
确保开发团队对产品待办列表项有足够深的了解
开发团队
各种专业人员，负责每个Sprint结束时交付前在可发布并且“完成“的产品增量。
开发团队由组织组建并得到授权，团队自己组织和管理他们的工作
特点：
自组织，没有人有权告诉开发团队应该如何把产品待办列表变成前在可发布的功能增量
跨职能团队：作为一个整体，拥有全部技能
不认可任何头衔，不管承担何种工作，都叫开发人员
不认可”子团队",无论开发、测试、架构、运维、业务分析
每个成员也许有特长和专注的领域，但责任属于整个开发团队
开发团队规模：
足够小以保持敏捷，足够大可以完成Sprint内的工作，一般3~9个人
产品负责人和Scrum Master不包含在开发团队人数中，除非他们同时也参与执行待办列表中的工作
Scrum Master
促进和支持Scrum，服务型领导，帮助Scrum团队之外的人了解他如何与Scrum团队交互是有意的，通过改变Scrum团队的互动方式来最大化Scrum团队所创造的价值
服务于产品负责人：
确保Scrum团队中的每个人都尽可能的理解目标、范围和产品域
找到有效管理产品待办列表的技巧
帮助Scrum团队理解为何需要清晰且简明的产品待办列表项
理解在经验主义的环境中的产品规划
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值
理解并实践敏捷性
当被请求或需要时，引导Scrum事件
服务于开发团队：
作为教练在自组织和跨职能方面给予开发团队以指导
帮助开发团队创造高价值产品
移除开发团队工作进展中的障碍
按被请求或需要时，引导Scrum事件
在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队
服务于组织：
带领并作为教练指导组织采纳Scrum
在组织范围内规划Scrum的实施
帮助员工和利益攸关者理解并实施Scrum和经验导向的产品开发
引发能够提升Scrum团队生产率的改变
与其他Scrum Master一期工作，增强组织中Scrum应用的有效性
Scrum 事件
一旦Sprint开始，它持续事件是固定的，不能缩短或延长。
Sprint本身作为一个事件，还是其他所有事件的容器，Scrum中每个事件都是用来检视和适应的正式机会。
Sprint
Scrum核心，长度为一个约或更多限时，这段事件构建一个“完成”、可用的、前在可发布的产品增量。
整个开发过程期间，Sprint长度保持和一致，前一个结束，下一个紧接着开始。
由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议、Sprint回顾会议构成。
每个Sprint都是可被视为一个项目，被用于完成某些事情，明确的目标，和一份设计过和灵活的计划来指导这些事、工作内容和最终产品增量。
至少每月一次对打成目标的进度进行检视和适应，来实现可预测性。把风险限制在一个月的成本上
期间：
不能做出有害于Sprint目标的改变
不能降低质量的目标
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可用加以澄清和重新协商
取消Sprint
可用在时间盒结束前取消，只有产品负责人才有取消Sprint的权利
当取消时，任何作何和“完成"的产品待办列表项都需要评审
取消Sprint会消耗资源，因为每个人都重新集合在令一个Sprint集合会议上来开始另一个Sprint
取消Sprint会对Scrum团队造成重创，这种情况很罕见，由于Sprint时间都很短，通常取消时不太合理的
取消的原因，某个Sprint对其所在环境来说失去了价值和意义
Sprint 计划会议
一个月的Sprint来说最长8小时，较短的Sprint会议时间通常会更短。
Scrum Master确保会议顺利进行，参会者理解会议的目的，教导Scrum团队遵守时间盒的规则。
Sprint 计划会议回答：
接下来的Sprint交付增量中要包含什么内容？
要如何完成交付增量所需的工作？
话题1：这次Sprint能做什么？
开发团队预测要开发的功能，产品负责人讲解目标以及达成该目标所需要完成的待办列表项。整个团队协同工作来理解Sprint的工作。
会议输入是：产品待办列表、最新的产品增量、开发团队在这个Sprint中能力预测、开发团队的以往表现
开发团队评估接下来Sprint可用完成什么工作
草拟一个Sprint目标
话题2：如何完成所选的工作？
开发团队规划出Sprint最初几天内所要做的工作，通常以一天或更少为一个单位。
开发团队自组织的领取Sprint待办产品列表中的工作，领取工作在Sprint计划会议和Sprint期间按需进行
产品负责人负责协助解释待办列表项，并做出权衡，也可邀请其他人员参加，以获得技术或领域只是方面的建议
会议结束时，开发团队项产品负责人和Scrum Master解释他们将如何以自组织团队的形式完成Sprint目标并开发出预期的产品增量
Sprint 目标
Sprint目标在Sprint计划会议中明确，目标是通过实现产品待办列表要达到的目的
目标要有一定的弹性，目标可用是任何其他的连贯性来促进开发团队一起工作而不是分开独自做
开发团队必须紧急目标，如所需工作和预期不同，开发团队需和产品负责人沟通协商Sprint待办列表的范围
每日Scrum站会
时间盒限定为15分钟，每天举行。同一时间同一地点举行，以便降低复杂性
为接下来24小时的工作制定计划，检视上一次每日站会以来的工作和预测将要到来的Sprint工作来优化团队协作和效能。
站会是开发团队内部的会议，如有开发团队之外的人出席会议，Scrum master必须确保他们不会干扰会议进行。
会议的结构由开发团队设定，专注于达成Sprint目标的进展，可采用不同方式进行：如
昨天，我为帮助开发团队达成Sprint目标做了什么？
今天，我为帮助开发团队达成Sprint目标准备做什么？
是否有任何障碍在阻碍我或开发团队达成Sprint目标？
开发团队一般站会后理解聚一起进行更详细的讨论，或为Sprint中剩余工作进行调整和重新计划。站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速的决策、提高开发团队的认知程度，这是检视与适应的关键会议。
Sprint 评审会议
在Sprint快结束时举行，以检视所交付产品增量并按需调整产品待办列表。
团队和利益攸关者协同讨论这次Sprint中所完成的工作，根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。
非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
以一个月的Sprint来说，评审会议最长不超过4小时，较短的Sprint会议时间更短。Scrum Master确保会议举行，参与者都明白会议目的，教导参会者遵循时间盒的规则。
评审会议包含以下内容：
参会者包括Scrum团队和产品负责人邀请的主要利益攸关者
产品负责人说明哪些产品待办列表项以及完成和哪些没有完成
开发团队讨论Sprint期间哪些工作做的很好，遭遇什么问题以及如何解决
开发团队演示完成的工作并解答关于所交付增量的问题
产品负责人讨论当前的产品待办列表的情况，他根据目前为止的进度来预测可能的目标交付日期（如果有需要的话）
参会的所有人就下一步的工作进行探讨，这样Sprint评审会就能够为接下来的Sprint计划会议提供价值的输入信息
评审市场或前在的产品使用方式所带来的接下来要做的最有价值的东西的改变
为下一个预测产品功能或产品能力版本的发布评审时间表、预算、潜力和市场
输出：
一份修订后的产品待办列表，产品很可能进入下一个Sprint的产品待办列表项
产品待办列表也有可能为了迎接新的机会而进行全局性的调整
Sprint 回顾会议
Scrum团队检视自身并创建下一个Sprint改进计划的机会
Sprint评审会结束之后，下个Sprint计划会议之前，一个月的Sprint一般不超过3个小时，Scrum Master确保会议举行，参与者明白会议目的
目的：
检视前一个Sprint中关于人、关系、过程和工具的情况如何
找出并加以排序做得好的和潜在的需要改进的主要方面
制定改进Scrum团队工作方式的计划
会议结束，应明确接下来的Sprint需要实施的改进，基于自身的检视而做出的适当调整，Sprint回顾会提供了一个工作检视和适应的正式机会
Scrum 工件
工件以不同方式表现工作任何和价值，工件是特别的设计，为了给关键信息提供最大透明化，每个人都工件都需要有相同的理解。
产品待办列表
涵盖产品中一致所需每项内容的有序列表，产品需求变动的唯一来源。
产品负责人负责管理产品待办列表的内容、可用性和排序
产品待办列表是动态的，需要持续更新以反映产品需要保持适用性、竞争力和有用
产品列表项，列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新。属性：描述、次序、估算和价值。包含测试描述，以便确认”完成“标准
排序越高的待办项通常有更多的细节信息，最终估算由开发团队决定
被开发团队在一个团队中”完成“的产品待办列表成为”准备就绪“，作为Sprint计划会议中的待选产品列表项
监控目标实现的进度
产品负责人至少在每个Sprint评审会中都必须跟踪剩余工作总量
比较这次剩余工作量与之前Sprint评审会议时的剩余工作量，来评估在期望时间点达成目标的进度
如燃尽图、燃烧图、累积流图
Sprint 待办列表
一组为当前Sprint选出的产品待办列表项，同时加上产品增量和实现Sprint目标的计划
至少包括一项在前次回顾会议中确定下来的高优先级的过程改进
待办列表拥有足够细节的计划，在每次Scrum站会中清晰的卡拿到
可视需要更新或移除，是对开发团队计划在当前Sprint内工作完成情况的实时反馈，该列表由开发团队全权负责
监控Sprint进度
Sprint任何时间点都可以计算待办列表的所有剩余工作的综合
至少每日站会跟踪剩余工作的总和，预测达成Sprint目标的可能性
通过不断的跟踪剩余工作量，开发团队可以管理自己的进度
增量
一个Sprint完成所有产品待办列表项的总和，以及之前所由Sprint所产生的增量的价值总和
新的增量必须是”完成“的，达到团队定义完成的标准
无论产品负责人是否决定发布它，增量必须可用
工件透明
Scrum Master必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的。
Scrum Master通过检视工件、嗅探模式、倾听周围的声音以及观察预期和实际结构之间的差异来发现不完全透明。
透明化不会再一夜之间发烧，但是这是一条必经之路。
”完成“的定义
每个团队对于完成有相同的理解以便确保透明化
”完成“的定义潜在可用交付功能增量，这一增量是可用的，产品负责人可用选择立即发布它
如果”完成“的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。
如果增量”完成“定义不是开发组织的惯例，那么开发团队就需一起参与制定”完成“的定义
每个增量都添加至之前的所有增量上，并且经过彻底的测试，以此确保整合再一起的所有增量都能工作
结束语
Scrum的角色、事件、工件和规则是不可改变的，Scrum以整体形式而存在，唯其如此才能作为其他技术、方法和事件的容器运作良好。
