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

相关主题

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

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)

Scrum指南的目的

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采用迭代增量式的方法来优化可预测性和管理风险。

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

透明性

流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。

例如：

∙所有参与者谈及流程的时候都必须使用统一的术语

∙负责完成工作和验收工作的人必须对“完成”有一致的定义。

检视

Scrum的使用者必须经常检视Scrum的工件和完成Sprint目标的进度，以发现不必要的偏差。检视不应该过于频繁而阻碍了工作本身。当熟练的检视者认真履行检视工作时，效果最佳。

调整

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

Scrum指定了进行检视和调整的4个正式事件，将在“Scrum事件”一节中详细描述：

∙Sprint计划会议

∙每日Scrum站会

∙Sprint评审会议

∙Sprint回顾会议

Scrum团队

Scrum团队由产品负责人、开发团队和Scrum Master组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导。跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率。

Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。增量式地交付“完成”的产品保证了可工作产品的潜在可用版本总是存在。

产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。

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

∙清晰地表达产品待办列表项

∙对产品待办列表项进行排序，最好地实现目标和使命

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

∙确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作

∙确保开发团队对产品待办列表项有足够的理解

产品负责人可以亲自完成上述工作，也可以让开发团队来完成。然而，产品负责人是负最终责任的人。

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

为保证产品负责人的工作顺利进行，组织中的所有人员都必须尊重他的决定。产品负责人所作的决定通过产品待办列表的内容和排序来表达。任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。

开发团队

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

开发团队由组织组建并授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和有效性。

开发团队有以下几个特点：

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

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

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

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

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

开发团队的规模

开发团队最佳规模是：足够小以保持敏捷性，足够大以完成重要的工作。少于3人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在Sprint 中可能会受到技能的约束，无法交付可发布的产品增量。大于9人的团队需要过多的协调沟通工作。过大的团队会产生太多复杂性，不便于经验过程管理。产品负责人和Scrum Master的角色不包含在此数字中，除非他们也参与执行Sprint代表事项列表中的工作。

Scrum Master

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

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