前言

本文翻译自 Agile Alliance 的 Scrum 词条,仅为学习之用,如有版权方面问题,请与我联系。原文档请点击Scrum

定义

Scrum是一个用来管理产品开发和其它知识性产品的流程框架。Scrum是经验性的,因为它为团队提供了一种手段来建立关于他们认为某事如何运作的假设。先尝试,再根据反馈经验进行调整。这就是这个框架的正确用法。

Scrum在某个层面是结构性的,适当的时候,团队可以引入其它框架的实践。

何时适用

Scrum最适合跨职能团队在产品开发环境中工作的情况,在这种情况下,大量的工作很容易分解为2至4周的迭代。

价值观

使用Scrum的团队应该学习和探索下面提到的价值观。

成果

团队成员亲自实现了目标。

勇气

团队成员面对困难做出了正确的事。

专注

专注于Sprint和团队目标提到的工作。

开放

团队成员和投资方公开所有工作和团队面对的问题。

尊重

团队成员互相尊重以保证能力在线和独立。

原则

以下原则支持了Scrum实验性的特点。

透明

整个团队必须在工作在一个可以知道其它成员在做什么的环境中。团队成员发现了组织内部的问题(通常是存在很长时间的问题),阻碍了团队的成功。

检查

框架中内置了频繁的检查点,使团队有机会了解工作进度。这里的检查点包括每日Scrum会议和Sprint回顾会议。

适应

整个团队不断地探究事情正在如何进行并且修改那些看起来不合理的项目。

实践

事件

Sprint

Sprint是一个不多于1个月的时间窗口,留给开发者开发潜在可用的产品功能。通常Sprint有以下特点:

  • 在整个开发过程中保持一致的步调。
  • 新的Sprint是直接基于上一个Sprint的结果。
  • Sprint的启示和终止事件都是固定的。

Sprint计划

团队在开启一个Sprint时,需要首先讨论在这一期Sprint中要从产品Backlog中选取哪些项目来完成。Sprint计划的产出结果就是Sprint Backlog。

Sprint计划通常有两部分。第一部分中,产品所有者和其他团队成员讨论并通过这一期Sprint要完成产品Backlog中的哪些特性。

在Sprint计划第二部分中,团队确定将如何交付产品Backlog中被标记的部分,作为潜在可用产品的一部分。这里有一个可能的实践是,团队会确定必要的具体任务来完成目标。产品Backlog中被标记的项目和可以完成的任务,组成了Sprint Backlog。

一旦团队和产品所有者按照产品Backlog中的说明确定了Sprint的范围,就不能再向Sprint Backlog中添加更多项目。

这避免了团队受到由于Sprint范围改变而造成的影响。

每日Scrum

每日Scrum是一个简短的讨论会(通常不超过15分钟),用来给团队同步接下来一天的工作内容。每日Scrum并不是要进行状态报告会议或解决问题。

Sprint复审

在每个Sprint的结尾,团队成员、产品所有者和所有利益相关者会一起复审这个Sprint的结果。这个复审的目的是讨论和演示并潜在地使利益相关者有机会使用完成的功能以获取反馈。Sprint复审的目的不是提供一个状态报告。Sprint复审的反馈将会体现在产品Backlog中以供未来进行考虑。

Sprint回顾

在Sprint的结尾,Sprint复审之后,整个团队(包括产品所有者)一起回顾过去的Sprint中事情进展情况以及确实未来如果调整。这个回顾的结果就是至少有一个行动项要包括进下一个Sprint的Sprint Backlog中。

实体

产品Backlog

产品Backlog是一个包括所有可能体现在产品中的变化点的有序列表。产品Backlog中的项目是可选的和不确定的,并不保证一定会被交付。

产品所有者负责维护产品Backlog,以及后期的内容、可行性和有序性。

Sprint Backlog

Sprint Backlog是产品Backlog中被选中将被交付的项目的集合。如果团队确定了任务,则是交付那些产品Backlog项目并实现Sprint目标所需的任务。

完成项

完成项是在Sprint结尾时,那些符合完成定义的产品Backlog中项目的集合。产品所有者可能会发布这些完成项或者在下一个Sprint中构建。

完成定义

完成定义是一个团队关于产品Backlog中项目应该达到哪些目标才会被认为是完成的公认标准。

角色

产品所有者

产品所有者是一个负责维护产品Backlog的角色,目的是让团队完成期望的标准。

产品所有者角色存在于Scrum中,以解决产品开发团队在构建内容方面有多个,相互冲突的方向或根本没有方向的挑战。

Scrum掌控者

Scrum掌控者是负责确保团队工作在敏捷的价值观和原则之内,并遵循团队同意使用的流程和实践的角色。

该名称最初旨在表示某个人是Scrum的专家,从而可以指导其他人。

该角色通常没有任何实际权限。 担当这一角色的人们必须从有影响力的职位开始领导,通常是一个服务型领导的角色。

开发团队

开发团队是一些在Sprint中交付产品完成项的人。

开发团队的主要职责是在每个Sprint中交付那些可以带来价值的项目。如何划分具体工作,由团队根据当时的情况来确定。

生命周期

Scrum是一个可以让开发团队灵活应对变化场景的框架。这个框架有足够的检查点使得团队不会偏离期望的输出。任何问题都可以被找到、解决并且做出调整。

Scrum生命周期从优先的Backlog开始,但没有提供任何关于如何开发或确定优先顺序的指导。

Scrum生命周期由一系列Sprint组成,其最终结果就是完成一个潜在可交付的产品完成项。在这些Sprint之中,所有为了开发产品的必要工作都在总体产品内容的一个子集当中。下面是关于Scrum生命周期的关键步骤的描述。

  1. 建立产品Backlog。
  2. 产品所有者和开发团队确定Sprint计划。
    确定Sprint的边界是Sprint计划的第一步,第二步是计划如何交付边界内的内容。
  3. 随着Sprint的进行,开发团队的工作就是交付被选中的产品Backlog项目。
  4. 开发团队会在每日Scrum中协调工作。
  5. 在Sprint的结尾,开发团队交付Sprint计划中被选中产品Backlog项目。开发团队在Sprint复审中给客户展示完成项并得到反馈。团队成员和产品所有者也会一起复盘Sprint迄今为止的进度,并且在回顾中调整进度。
  6. 团队重复前面第二到第五步直到整个产品完成。

起源

1986年,Takeuchi和Nonaka在哈佛商业回顾中发表了文章《The New New Product Development Game》。本文介绍了一种团队合作方式,其中“产品开发过程源于一个经过精心挑选的,跨学科团队的不断互动,该团队的成员从头到尾一起工作”。该文章经常在Scrum的布道会上被提到。

1993年,Jeff Sutherland在Easel公司创立的Scrum方法。

1995年,Ken Schwaber和Jeff Sutherland在OOPSLA大会上一起介绍了Scrum。

主要贡献

Scrum的主要贡献在于介绍了一种简单而有效的,用于小型合作团队的管理工作和软件开发方式。它提供了一个框架和一组简单规则,允许进行适当数量的计划,对工作的控制以及风险识别和缓解以及问题识别和解决。

参考阅读

Scrum Guide
Agile Software Development with Scrum Ken Schwaber和Mike Beedle
Agile Project Management with Scrum Ken Schwaber
Scrum Alliance