Scrum敏捷开发框架规范 中文版

Scrum指南Scrum的权威指南:游戏规则2013年7月由Ken Schwaber和Jeff Sutherland开发并维护目录Scrum指南的目的 (3)Scrum的定义 (3)Scrum理论 (3)透明性 (3)检视 (4)调整 (4)Scrum团队 (4)产品负责人 (4)开发团队 (5)Scrum Master (5)Scrum事件 (6)Sprint (7)Sprint计划会议 (8)每日Scrum站会 (9)Sprint评审会议 (9)Sprint回顾会议 (10)Scrum工件 (11)产品待办列表 (11)Sprint待办列表 (12)增量 (12)工件的透明性 (12)“完成”的定义 (13)结束语 (13)致谢 (13)人们 (14)历史 (14)翻译 (14)©2014 and ScrumInc. Offered for license under the Attribution Share-Alike license of CreativeScrum指南的目的Scrum是用于开发和支持复杂产品的框架。

这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。

Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。

他们是Scrum指南的后盾。

Scrum的定义Scrum: Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。

Scrum是：∙轻量级的∙容易理解的∙难以精通的自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。

Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。

Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。

Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。

框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。

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

Scrum 的规则会贯穿这份文档。

实施Scrum的方案根据情况不同而不同，在这里不作介绍。

Scrum理论Scrum基于经验型流程控制理论，或者称为经验主义。

经验主义主张知识源于经验，而决策基于已知的事物。

Scrum采用迭代增量式的方法来优化可预测性和管理风险。

透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。

透明性流程中的关键环节必须为那些对产出负责的人可见。

要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。

例如：©2014 and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative∙所有参与者谈及流程的时候都必须使用统一的术语∙负责完成工作和验收工作的人必须对“完成”有一致的定义。

检视Scrum的使用者必须经常检视Scrum的工件和完成Sprint目标的进度，以发现不必要的偏差。

检视不应该过于频繁而阻碍了工作本身。

当熟练的检视者认真履行检视工作时，效果最佳。

调整如果检视者发现流程中的一个或多个方面背离了可接受的标准，并且将会导致产品不合格时，就必须对流程本身或者流程化的内容进行调整。

调整工作必须尽快实施以最小化进一步的偏差。

Scrum指定了进行检视和调整的4个正式事件，将在“Scrum事件”一节中详细描述：∙Sprint计划会议∙每日Scrum站会∙Sprint评审会议∙Sprint回顾会议Scrum团队Scrum团队由产品负责人、开发团队和Scrum Master组成。

Scrum团队是跨职能的自组织团队。

自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导。

跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。

这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率。

Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。

增量式地交付“完成”的产品保证了可工作产品的潜在可用版本总是存在。

产品负责人产品负责人负责最大化产品以及开发团队工作的价值。

实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。

产品负责人是管理产品待办列表的唯一责任人。

产品待办列表的管理包括：∙清晰地表达产品待办列表项∙对产品待办列表项进行排序，最好地实现目标和使命∙优化开发团队所执行工作的价值©2014 and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative∙确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作∙确保开发团队对产品待办列表项有足够的理解产品负责人可以亲自完成上述工作，也可以让开发团队来完成。

然而，产品负责人是负最终责任的人。

产品负责人是一个人，而不是一个委员会。

产品负责人可能会通过产品待办事项列表展现一个委员会的需求，但要想改变某项的优先级必须先经过产品负责人。

为保证产品负责人的工作顺利进行，组织中的所有人员都必须尊重他的决定。

产品负责人所作的决定通过产品待办列表的内容和排序来表达。

任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。

开发团队开发团队包含了各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。

只有开发团队的成员才能开发增量。

开发团队由组织组建并授权，团队自己组织和管理他们的工作。

由此产生的正面效应能最大化开发团队的整体效率和有效性。

开发团队有以下几个特点：∙他们是自组织的，没有人（即使是Scrum Master都不可以）告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。

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

∙Scrum不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。

此规则无一例外。

∙Scrum不认可开发团队中的所谓“子团队”，无论是测试还是业务分析的成员都不能划分为“子团队”。

此规则无一例外。

∙开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。

开发团队的规模开发团队最佳规模是：足够小以保持敏捷性，足够大以完成重要的工作。

少于3人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。

过小的团队在Sprint 中可能会受到技能的约束，无法交付可发布的产品增量。

大于9人的团队需要过多的协调沟通工作。

过大的团队会产生太多复杂性，不便于经验过程管理。

产品负责人和Scrum Master的角色不包含在此数字中，除非他们也参与执行Sprint代表事项列表中的工作。

Scrum Master©2014 and ScrumInc. Offered for license under the Attribution Share-Alike license of CreativeScrum Master负责确保所有人都能正确地理解并实施Scrum。

因此，Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。

Scrum Master是Scrum团队中的服务型领导。

Scrum Master帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

Scrum Master服务于产品负责人Scrum Master以各种方式服务于产品负责人，包括：∙找到有效管理产品待办列表的技巧∙帮助Scrum团队理解“清晰准确的产品待办列表项”的重要性∙在经验主义的环境中理解长期的产品规划∙确保产品负责人懂得如何安排产品待办列表项来最大化价值∙理解并实践敏捷∙按要求或需要引导Scrum事件Scrum Master服务于开发团队Scrum Master以各种方式服务于开发团队，包括：∙在自组织和跨职能方面给予团队指导∙协助开发团队开发高价值的产品∙移除开发团队工作中的障碍∙按要求或需要引导Scrum事件∙在Scrum还未被完全采纳和理解的组织环境下指导开发团队Scrum Master服务于组织Scrum Master以各种方式服务于组织，包括：∙带领并指导组织采用Scrum∙在组织范围内计划Scrum的实施∙帮助员工及相关干系人理解并实施Scrum和经验型产品开发∙发起能够提升Scrum团队生产效率的改变∙与其他Scrum Master一起工作，增加组织中Scrum实施的有效性Scrum事件Scrum中指定了一些常规性事件，以减少Scrum之外的会议。

Scrum中的事件是有时间盒限定的，也就是说每个事件都有时间限制的。

一旦Sprint开始，它的周期也就固定下来了，不能缩短或者延长。

而其他事件则可以在该事件的目标达成以后立即终止，这样就确保了在这些事件上花费的时间不会影响项目的进度。

©2014 and ScrumInc. Offered for license under the Attribution Share-Alike license of CreativeSprint除了本身作为一个事件以外，还是其他所有事件的容器。

Scrum中的每个事件都是进行检视和调整的机会。

这些事件被特别用来确保至关重要的透明性和检视。

如果Sprint不能成功地包含这些事件中的任何一个，透明性就会降低，同时也丧失了进行检视和调整的机会。

SprintSprint是Scrum的核心，其周期为小于或者等于一个月，其产出是“完成的”、可用的、潜在可发布的产品增量。

Sprint的长度在整个开发过程中保持一致。

新的Sprint在上一个Sprint完成之后立即开始。

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

在Sprint中：∙不能做出有害于Sprint目标的改变∙不能降低产品质量∙随着对信息掌握的增加，产品负责人和开发团队可以澄清或者重新商讨开发范围每个Sprint都可以被视为一个项目，为期不超过一个月。

和普通项目一样，Sprint 的目标也是完成一些事情。

每个Sprint都会定义要开发什么东西，还有一份设计和灵活的计划能够指导开发过程、工作内容和最终结果。