00.Scrum 指南的目的
Scrum是用于开发、交付和持续支持复杂产品的一个框架。本指南包括了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum。
01.Scrum的定义
Scrum:Scrum是一个框架，在此框架中人们可以解决复杂的自适应的难题，同时也能高校并创造性地交付可能最高价值的产品。
Scrum特点：轻量的、易于理解的、难以精通的
Scrum并不是一种过程、技术活决定性的方法。
Scrum框架由Scrum团队以及之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要。
Scrum的规则吧角色、事件和攻讦组织在一起，管理他们之间的关系和交互。
02.Scrum的应用
应用范围：
*研究与识别可行的市场、技术和产品能力
*开发产品和增强功能
*产品和增强功能，频率高到一天发布多次
*开发与支持云(在线、安全、按需)和其他运行环境来提供给产品使用
*支持和更新产品
Scrum的精髓在于小团队。个体团队具有高度灵活性与适应型。当单个团队、几个团队、多个团队和网络团队在开发、发布、运营和维护成千上万的工作和工作产品时，这些优势得以持续运行。他们通过精妙的开发架构和目标发布环境来协作和互操作。
03.Scrum理论
Scrum基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。Scrum采纳一种迭代和增量的方式来优化对未来的预测和控制风险。透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。
透明：过程中的关键环节对于那些产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一标准，这样所有留意这些缓解的人都会对观察到的事物有统一的理解。
检视：Scrum的使用者必须经常检视Scrum的工件和完成Sprint目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当监视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。
适应：如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。
事件章节：Sprint计划会议、每日Scrum站会、Sprint评审会议和Sprint回顾会议
04.Scrum价值观
当承诺、勇气、专注、开发和尊重五大价值观为Scrum团队所践行与内化时，Scrum的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum团队成员通过Scrum的角色、事件和工件来学习和探索这些价值观。
Scrum的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现Scrum团队的目标。Scrum团队成员有勇气去做正确的事件并不处理那些棘手的问题。每个人专注于Sprint工作和Scrum团队目标。Scrum团队及其利益攸关者同一将所有工作和执行工作上的挑战进行公开。Scrum团队成员相互尊重，彼此是有能力和独立的人。
05.Scrum团队
Scrum团队由一名产品负责人、开发团队和一名Scrum Master组成。Scrum团队是跨职能的自组织团队。字组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来知道。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum团队(自身)已经证明，对于所有之前所述Scrum的应用以及任何复杂工作来说，它都是越来越有效。
06.产品负责人
产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨组织、Scrum团队和团队成员个体不同而有所不同。
产品负责人是负责管理产品待办列表的唯一负责人。
*清晰地表述产品待办列表项
*对产品待办列表项进行排序，使其最好地是心啊目标和使命
*优化开发团队所执行工作的价值
*确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作
*确保开发团队对产品待办列表项目有足够深的了解
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。产品负责人是一个人，而不是一个委员会。为了保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另一套需求开展工作。
07.开发团队
开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和效用。
特点：
*他们是自组织的。没有人(即使是Scrum Master)有权告诉开发应该如何把产品待办列表变成潜在可发布的功能增量。
*开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
*Scrum不认可开发团队成员的任何头衔，不管其承担何种工作(他们都叫开发人员)。
*Scrum不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；
*开发团队中每个成员也许有特长和专注的领域，但是责任属于整个开发团队
08.开发团队的规模
开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在Sprint内完成重要的工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和Scrum Master角色不包含在开发团队人数中，除非他们同时也参与执行Sprint待办列表中的工作。
09.Scrum Master
Scrum Master负责根据Scrum指南中的定义来促进和支持Scrum。Scrum Master通过帮助每个人理解Scrum理论、实践、规则和价值来做到这一点。
Scrum Master对Scrum团队而言，他/她是一位服务型领导。Scrum Master帮助Scrum团队之外的人了解他/她如何与Scrum团队交互是有益的，通过改变他/她们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。
a.Scrum Master 服务于产品负责人
Scrum Master以各种方式服务于产品负责人，包括：
*确保Scrum团队中的每个人都尽可能地理解目标、范围和产品域
*找到有效管理产品待办列表的技巧
*帮助Scrum团队理解为和需要清晰且键名的产品待办列表项
*理解在经验主义的环境中的产品规划
*确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
*理解并时间敏捷性
*当被请求或需要时，引导Scrum事件
b.Scrum Master服务于开发团队
*作为教练在自组织和跨职能方面给予开发团队以指导
*帮助开发团队创造高价值的产品
*移除开发团队工作进展中的障碍
*按被请求或需要时，引导Scurm事件
*在Scrum还未完成采纳和理解的组织环境中，作为教练指导开发团队
c.Scrum Master服务于组织
*带领并作为教练指导组织采纳Scrum;
*在组织范围内规划Scrum的实施
*帮助员工和利益攸关者理解并实施Scrum和经验导向的产品开发
*引发能够提升Scrum团队生产率的改变
*与其他Scrum Master一起工作，增强组织中Scrum应用的有效性。
10.Scrum事件
Scrum使用固定的事件来产生规律性，以此减少Scrum之外的其他会议的必要。所有时间都是有时间盒限定的，也基于是说每一个事件限制在最长的事件范围内。Sprint除了本身作为一个事件以外，他还是其他所有事件的容器，在Scrum中每个事件都是用来进行检视和适应的正式机会。这些时间都是被特别设计用来确保达成透明和检视。如果Sprint不能成功地包含这些时间中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。
11.Sprint
Sprint是Scrum的核心，其长度(持续时间)为一个月或更短的限时，这段时间构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint的长度保持一致。前一个Sprint结束后，下一个新的Sprint紧接着立即开始。
Sprint由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成
在Sprint期间：不能做出有害于Sprint目标的改变；不能降低质量的目标；随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做到的事可以加以澄清和重新协商。
每个Sprint都会有一个要构建什么目标，还有一份设计过和灵活的用来指导如何做这些事、工作内容和最终产品增量。
12.取消Sprint
Sprint可以在Sprint时间和结束之前取消。只有产品负责人才有取消Sprint的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是Scrum Master的影响。
总的来说，如果某个Sprint对其所在环境来说失去了价值和意义，那么他就应该被取消。然而，由于Sprint的时间都很短，所以取消Sprint通常是不太合理的。
13.Sprint计划会议
Sprint中要做的工作在Sprint计划会议中做计划。这份工作计划由整个Scrum团队共同协作完成的。
Sprint计划会议是有时间盒限定的，以一个月的Sprint来说最长为8小时。对于较短的Sprint，会议时间通常会缩短。Scrum Master要确保会议顺利举行，并且每个参会都理解会议的目的。Scrum Master要教导Scrum团队遵守时间和的规则。
14.开发Sprint能做什么？
开发团队预测这次Sprint中药开发的功能。产品负责人讲解Sprint的目标以及达成该目标所需完成产品待办列表项。整个Scrum团队协同工作理解Sprint的工作。
Sprint会议的输入是产品待办列表、最新的产品增量、开发团队在这个Sprint中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的Sprint可以完成什么工作。
在Sprint计划会议中，Scrum团队还草拟一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。
15.如何完成所选的工作？
开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在Sprint计划会议中，开发团队已经挑选足够量的工作，以此来预估他们在即将来到的Sprint中能够完成。
产品负责人嫩巩固帮助解释清楚所选定的产品待办列表项，兵做出权衡。
16.Sprint目标
Sprint目标是在当前Sprint通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么构建增量。
17.每日Scrum站会
每日Scrum站会是开发团队的一个时间盒限定为15分钟的事件。每日站会在Sprint的每一天举行。在每日Scrum站会上，开发团队为接下来24凶啊是的工作制定计划。通过检视上次每日Scrum站会依赖的工作和预测即将到来的Sprint工作来优化团队协作和效能。每日Scrum站会在同一时间同一地点举行，以便降低复杂性。
会议的结构由开发团队设定。只要会议专注于达成Sprint目标的进展，开发团队可以采用不同的方式进行。
*昨天，我为帮助开发团队达成Sprint目标做了什么？
*今天，我为帮助开发团队达成Sprint目标准备做什么?
*是否有任何障碍在阻碍我或开发团队达成Sprint目标?
开发团队或者开发团队成员通常会在每日Scrum站会后立即聚到一起进行更详细的讨论，或者为Sprint中剩余的工作进行调整或重新计划。
Scrum Master确保开发团队的每日站会如期举行，但开发团队自己负责召开会议。Scrum Master教导开发团队将每日Scrum会议时间控制在15min.
每日Scrum站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。
每日Scrum站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做出决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。
18.Sprint评审会议
Sprint评审会议在Sprint快结束时举行，用以监视所交付的产品增量并按需调整产品待办列表。
对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。Scrum Master要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master教导每位参会者遵守时间盒的规则。
Sprint评审会议包含以下内容：
*参会者包括Scrum团队和产品负责人邀请的主要利益攸关者；
*产品负责人说明那些产品待办列表项已经“完成”和哪些没有“完成”；
*开发团队讨论在Sprint期间那些工作做的很好，遭遇到什么问题以及问题是如何解决的；
*开发团队演示“完成”的工作并解答关于所交付增量的问题
*产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）
*参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下来的Sprint计划会议提供有价值的输入信息
*评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变
*为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表页游可能为了迎接新的机会而进行全局性地调整。
19.Sprint回顾会议
Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。
回顾会议发生在Sprint评审会议结束之后，下个Sprint计划会议之前。对于长度为一个月的Sprint来说，回顾会议事件最长不超过3小时。对于较短的Sprint来说，会议时间通常会缩短。Scrum Master要确保会议举行，并且每个参会者都明白会议的目的。
Sprint回顾会议的目的在于：
*检视前一个Sprint中关于人、关系、过程和工具的情况如何
*找出并加以排序做得好的和潜在需要改进的主要方面
*制定改进Scrum团队工作方式的计划
在Sprint回顾会议结束时，Scrum团队应该明确接下来的Sprint中需要实施的改进。在下一个Sprint中实施这些改进是基于Scrum团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，但Sprint回顾会议提供了一个专注于检视和适应的正式机会。
20.Scrum工件
Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明以检视和适应的机会。Scrum所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对攻讦都需要有相同的理解。
21.产品待办列表
产品待办列表是一份涵盖产品中已知所需每项内容有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精化的过程中，产品待办列表项背重新评审和修改。Scrum团队决定如何来完成精华以及合何时来完成。净化的工作通常占用开发团队不超过10%的产能。
开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。
各种不同趋势走向的时间已经被预测进度方面，例如，燃尽图(burn-downs)、燃烧图(burn-ups)或者累积流图(cumulative flows)。这些工具都被证实是有用的。然而，他们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法预知的。只有已经发生的事情才能用来做前瞻性的决策。
22.Sprint待办列表
Sprint待办列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。Sprint待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
在Sprint的任何时间点都可以计算Sprint待办列表中所有工作的总和。开发团队至少在每日Scrum站会跟踪剩余工作的总和，预测达成Sprint目标可能性。通过在Sprint中不断跟踪剩余的工作量，开发团队可以管理自己的进度。
增量是在Sprint结束时支持经验主义的、课检视的和已完成的产品组成部分。增量是迈向愿景或目标的异步。无论产品负责人是否决定发布他，增量是可用。
23.工件透明
Scrum依赖于透明。优化价值的控制风险的决定都是基于所获知的工件状态。当工件的状态是完全透明是，这些做出的决定次啊有一个检视的基础；当工件状态不完全透明时，这些做出的决定就会有瑕疵，而价值也可能因此遭受损失，同时风险也可能会因此而增加。
Scrum Master的职责就是和Scrum团队以及组织一起合作增加工件的透明化。这一工作通常包括学习、说服和改变。透明化不会在一夜之间发生，但是这是一条必经之路。
24.结束语
Scrum的角色、时间、工件和规则是不可改变的。Scrum只以整体形势而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。