标签：最小化 多次 统一 讲解 网络 预测 功能 设计 指南
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通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么构建增量。
标签：最小化 多次 统一 讲解 网络 预测 功能 设计 指南
原文地址：https://www.cnblogs.com/aixiaoxiaoyu/p/10235821.html
