Scrum

scrum是用于开发、交付和持续支持复杂产品的一个框架，本指南包含了scrum的定义，其中包括了scrum的角色、事件、工件以及把他们组织在一起的规则

Scrum指南的目的

Scrum是轻量的、易于理解的、难以精通的

Scrum由scrum团队以及之间相关的角色、事件、工件和规则组成，框架中的每个部分都有特定的目的，其对于scrum的成功和使用是至关重要的

Scrum的规则把角色、事件和工件组织在一起，管理他们之间的关系和交互

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

Scrum的定义

Scrum的应用

过程中的关键环节对于那些对产出负责的人必须是显而易见的，要拥有透明、就要为这些关键环节制定一个统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解

透明

Scrum的使用者必须经常检视scrum的工件和完成sprint目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身，当检视是由技能娴熟的检视者在工作中勤勉的执行时，效果最佳

检视

如果检视者发现在过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整，调整工作必须尽快执行如此才能最小化进一步的偏离

适应

Scrum基于经验过程控制理论，或称之为经验主义，经验主义主张知识源自实际经验以及当前有价值情况下做出的决定所获得，Scrum采纳一种迭代和增量式的方法来优化对未来的预测和控制风险透明、检视和适应是经验控制过程的三大支柱，支撑起每一个经验过程的实施

Scrum理论

Scrum价值观

清楚的描述产品代办列表

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

优化开发团队所执行工作的价值

确保产品代办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作以及确保研发团队对产品代办列表项有足够深的了解

产品代办列表的管理包括：

产品负责人的职责是将开发团队开发的产品价值最大化，如何实现直一点会随着跨组织、Scrum团队和团队成员个体的不同而有所不同产品负责人是负责管理产品代办列表的唯一负责人

产品负责人

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

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

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

Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或者业务分析，同时，开发团队中的每个成员也许有特长或者专注的领域，但是责任属于整个开发团队

开发团队的特点：

开发团队的规模

开发团队包括各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量，在Sprint评审会议上，一个“完成”增量是必须的，只有开发团队成员才能创建增量开发团队由组织组建并得到授权，团队自己组织并管理他们的工作，由此产生的正面效应能最大化开发团队的整体效率和效用

开发团队

Scrum Master 服务于产品负责人

Scrum Master 服务于开发团队

Scrum Master服务于组织

Scrum Master 负责根据scrum指南中的定义来促进和支持Scrum，Scrum Master 通过帮助每个人理解Scrum 理论、实践、规则和价值来做到这一点Scrum Master 对Scrum团队而言，他/她是一名服务型领导，Scrum Master 帮助Scrum团队之外的人他/与她如何与Scrum团队交互是有益的，通过改变他/她们与Scrum团队交互的方式来最大化Scrum 团队所创造的价值

Scrum Master

Scrum团队由一名产品负责人、开发团队和一名Scrum Master 组成，scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导，跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人

Scrum团队

每个Sprint都可被视为一个项目，为期不超过一个月，就如同项目一样，Spint被用于完成某些事情，每个Sprint都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来知道如何做这些事、工作内容和最终产品增量

Sprint 由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Spring 回顾会议构成

Sprint的长度限制在一个月之内，当Sprint的长度太长的话，对要构建什么的定义就可能会改变，复杂性也有可能会增加，Spint通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性，Spring同时也把风险限制在一个月的成本上

Spint是Scrum的核心，其长度（持续时间）为一个月或者更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量，在整个开发过程期间，Sprint 的长度保持一致，前一个Spring 结束后，下一个新的Sprint紧接着立即开始

Sprint 可以在Sprint时间盒结束之前取消，只有产品负责人才有取消Sprint的权利，虽然可能这样的决定可能受到利益攸关者、开发团队或者Scrum Master 的影响

如果Sprint目标过时，那么Sprint就会被取消，由于Sprint的时间都很短，所以取消Sprint通常是不合理的

当取消某个Sprint时，任何做完和“完成”的产品代办列表都需要评审，假如成果的任何部分具有潜在可发布的话，产品负责人通常会接受这个成果，所有未完成的产品代办项都会被放回到产品代办列表中，并重新估算，花在他们身上的工作会很快的被贬值，所以必须经常性的重估

取消Sprint会消耗资源，因为每个人都重新集合在另外一个Sprint计划会议来开始另外一个Sprint，取消Sprint通常会对Scrum 造成重创，这种情况非常罕见

取消Sprint

Sprint

Sprint中要做的工作在Sprint计划会议中来做计划，这份工作计划是由整个Scrum团队共同协作完成的

Sprint 计划会议是有时间盒限定的，以一个月的Sprint 来说最长为8个小时，对于较短的Sprint，会议时间通常会缩短，Sprint Master要确保会议顺利举行，并且每个参会者都理解会议的目的，Sprint Master要教导Scrum团队遵循时间盒的规则

Sprint 目标

Sprint 计划会议

会议的结构由开发团队设定，只要会议专注与达成Sprint目标的进展，开发团队可以采用不同的方式进行，一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨论来开会

开发团队或者开发团队成员通常会在每日Scrum站会后立即聚到一起进行更详细的讨论，或者为Sprint中剩余的工作进行调整或者重新计划

Scrum Master确保开发团队每日站会如期举行，但开发团队自己负责召开会议，Scrum Master教导开发团队将每日Scrum 会议事件控制在15分钟内

每日Scrum站会是开发团队的内部会议，如果有开发团队之外的人参加会议，Scrum Master 必须确保他们不会干扰会议进行

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

每日Scrum站会是开发团队的一个时间盒为15分钟的事件，每日scrum站会在Sprint的每一天都举行，在每日Scrum站会上，开发团队为接下来的24小时的工作制定计划，通过检视上次每日Scrum站会以来的工作和预测即将到来的Sprint 工作来优化团队协作和效能，每日Scrum站会在同一时间同一地点举行，以便降低复杂性

每日Scrum 站会

对于长度为一个月的Sprint 来说，评审会议最长不超过4个小时，对于较短的Sprint 来说，会议时间通常会缩短，Scrum Master 要确保会议举行，并且每个参会者都理解会议的目的，Scrum Master教导没位参会者遵守时间盒的规则

Sprint 评审会议在Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品代办列表，在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作，根据完成情况和sprint期间产品代办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值，这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作

Sprint 评审会议

回顾会议发生在Sprint 评审会议结束之后，下个sprint 计划会议之前，对于长度为一个月的sprint 来说，回顾会议时间最长不超过三个小时，对于较短的sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的

Scrum Master 确保会议是积极的和富有成效的，Scrum Master 教导大家遵守时间盒的规则，Scrum Master对Scrum 过程负责，作为团队的一员参加该会议

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

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

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

Sprint 回顾会议的目的在于：

Scrum Master 鼓励Scrum 团队在Scrum 的过程框架内改进开发过程和实践，使得他们能在下一个Sprint 中更高效更愉快，在每个Sprint 回顾会议中，如果适用且不与产品或组织标准相冲突，Scrum 团队计划不同的方式通过改进工作过程或调整“完成”的定义来提高产品质量

在Sprint 回顾会议结束时，Scrum 团队应该明确下来的Sprint中需要实施的改进。在下一个Sprint 中实施这些改进是基于Scrum 团队对自身的检视而做出的适当调整，虽然改进可以在任何时间执行，但Sprint回顾会议提供了一个专注于检视和适应的正式机会

Sprint 回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会

Sprint 回顾会议

Scrum使用固定的事件来产生规律性，以此来减少Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的，也就是说每一个事件限制在最长的时间范围内，一旦Sprint 开始，它的持续时间的固定的，不能缩短或者延长，而其他事件则可以在该事件的目标达成之后可以立即结束，如此确保时间被适当的使用而不会造成过程中的浪费Scrum除了本身作为一个事件以外，它还是其他所有事件的容器，在Scrum中的每个事件都是用来进行检视和适应的正是机会，这些事件都是被特别设计用来确保达成检视和透明，如果Spint不能成功地包含这些事件中的任何一个事件，导致透明化降低，同时也会丧失进行检视与适应的机会

Scrum事件

产品代办列表永远是不完整的，最早开发的产品代办列表列举最初所知的以及理解透彻的需求，产品代办列表会随着产品及其应用环境的改变而演进，产品代办列表是动态的，需要持续更新以反应出产品需要什么来保持其适用性、竞争力和有用，如果产品存在，产品代办列表也就同样存在

产品代办列表列出所有特性、功能、需求、增强和修复等对未来要发布的产品进行的更新。产品代办列表具有这些属性：描述、次序、估算和价值。产品代办列表项通常包括测试描述、将在“完成”是证明其完整性

产品代办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变化的唯一来源，产品负责人负责管理产品代办列表的内容、可用性和排序

产品代办列表

Sprint 产品代办列表将开发团队用来达成sprint 目标的所有工作变得清晰可见，为了确保持续改进，它至少包含一项在前次回顾会议中确定下来的高优先级的过程改进

Sprint 产品代办列表是拥有足够细节的计划，任何进度的变化可以在每日Scrum 站会中清晰的看到，开发团队在Sprint 期间修改Sprint 代办列表，使得Sprint 代办列表在Sprint 期间涌现，涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达成Sprint 目标所必须的工作时

当新工作出现时，开发团队需要将其加入到Sprint 代办列表中去，随着工作的执行或者完成，剩余的工作量被估算并更新，当计划中的某个部分失去开发意义，就可以将其移除，在Sprint 期间，只有开发团队可以改变Sprint 代办列表，Sprint 代办列表是高度可见的，是对开发团队计划在当前Sprint 内工作完成情况的实时反馈，该列表由开发团队全权负责

在Sprint 的任何时间点都可以计算Sprint代办列表中所有剩余工作的总和，开发团队至少在每日Scrum 站会时跟踪剩余工作的总和，预测达成Sprint 目标的可能性，通过在Sprint 中不断跟踪剩余的工作量，开发团队可以管理自己的进度

监控Sprint 进度

Sprint 代办列表是一组为当前Sprint选出的产品代办列表项，同时加上交付产品增量和实现Sprint目标的计划，Sprint代办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测

Sprint 代办列表

增量是一个Sprint完成的所有产品代办列表项的总和，以及之前所有Sprint 所产生的增量的价值的总和，在Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义和标准，增量是在Sprint结束时支持经验主义的、可检视的和已完成的产品组成部分，增量是迈向愿景或者目标的一步，无论产品负责人是否决定发布它，增量必须可用

增量

Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会，Scrum 所定义的工件是特别设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解

Scrum工件

Scrum Master 必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的，有些实践就是为应对不完全透明的状态而生的，Scrum Master 必须帮助每个人，让他们能够遇见不透明的情况下采用最合适的实践。Scrum Master 能够通过检视工件、嗅探模式、倾听周围的声音以及观察预期和世纪结果之间的差异发现不完全透明

Scrum Master 的职责就是和Scrum 团队以及组织一起合作增加工件的透明化，这一工作通常包括学习、说服和改变，透明化不会在一夜之间发生，但是这是一条必经之路

Scrum 依赖于透明，优化价值和控制风险的决定都是基于所获知的工件状态，当工件的状态是完全透明时，这些做出的决定才有一个坚实的基础，当工件的状态是不完全透明时，这些做出的决定就会有暇疵，而价值也可能因此遭受损失，同时风险也可能会因此增加

这一定义也同时被用来指导开发团队了解在Sprint 计划会议时能够选择多少产品代办列表项，每个Sprint 的目标在于交付符合Scrum团队当前“完成”的定义的潜在可交付功能增量

开发团队在每个Sprint 都交付产品功能增量，这一增量是可用的，所以产品负责人可以选择立即发布它，如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都应该遵守它，以此为最低标准

如果增量“完成”的定义不是开发组织的惯例，那么Scrum 团队中开发团队就必须制定适合于产品“完成”的定义，如果系统或者产品发布由多个Scrum 团队一起开发，那么所有Scrum 团队中的开发团队必须一起参与制定“完成”的定义

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

随着Scrum团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量，当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统对应该对其上面开发的工作有完成的定义

当产品代办列表行或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么，虽然在不同Scrum 团队之间会存在着显著的差异，但是每个团队成员必须对完成工作意味着什么有相同的理解以便确保透明化，这就是Scrum团队的“完成”定义，用来评估产品是否完成

“完成”的定义

工件透明

Scrum