Scrum
是一种迭代式增量软件开发过程,通常用于敏捷软件开发
。Scrum在英语的意思是橄榄球里的争球。
虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums
.
<script type="text/javascript">
//<![CDATA[
if (window.showTocToggle) { var tocShowText = "显示"; var tocHideText = "隐藏"; showTocToggle(); }
//]]>
</script>
[编辑
]
历史
- 1986年,竹内弘高
和 野中郁次郎
阐述了一种新的整体性
的方法 ,该方法能够提高商业新产品开发
的速度和灵活性:[1]
- 他们将这种新的'整体性方法与
橄榄球
相比较,前者各阶段相互重叠,并且由一个跨职能团队在
不同的阶段完成整个过程,而后者整个团队"tries to go to the distance as a unit, passing
the ball back and forth"
。
- 他们对来自汽车,照片机器,计算机和打印机等产业的案例进行了研究。
- 1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》[2]
一书中将这种方法称
为 Scrum
,在竹内弘高
和 野中郁次郎
的文章中提到的橄榄球术语。
- 1990年代初,肯·施瓦伯
在其公司使用了一种方法Advanced Development
Methods(先进开发方法),这种方法后来发展为Scrum。
- 同时,杰夫·萨瑟兰
在Easel公司开发了一种类似的方法,并首次称之为Scrum。[3]
- 1995年,在奥斯汀举办的OOPSLA '95
上,萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里
合作,将上述的文章,他们的经验,以及业界的最佳实践融合起来,形成我们现在所知的Scrum。
- 2001年,施瓦伯与 麦克·比窦
(Mike
Beedle)合著了《敏捷软件开发-使用Scrum过程》一书,介绍了Scrum方法。
[编辑
]
Scrum的特性
Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括:
-
Scrum主管
(ScrumMaster),这一角色同项目经理类似,负责维护过程和任务;
-
产品负责人
(Product Owner),这一角色代表所有利益相关者;
-
开发团队
(Team),这一角色包括所有开发人员。
在每一次冲刺(一个15到30天的周期,其长度由开发团队决定)当中,开发团队创建可用的(可以随时推出)软件的一个增量。每一个冲刺所要实现的功
能来自产品订单(product
backlog)。产品订单是按照优先级排列的要完成的工作的概要的需求,那些订单项会被加入一次冲刺由冲刺计划会议决定。
在会议中,产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。[4]
在冲刺的过程中,没有人能够变更冲刺订单(sprint backlog),这意味着在一个冲刺中需求是被冻结的。
管理Scrum过程有很多实施方法,从即时贴、白板,一直到软件包。Scrum最大的好处之一是它非常容易学习,而且启动Scrum应用并不需要太
多的投入。
[编辑
]
Scrum中的角色
Scrum当中定义了许多角色。按照对开发过程的参与情况,这些角色被分为两组,即猪
组和鸡
组。这个分组方法的由来
是一个关于猪和鸡合伙开餐馆的笑话[4]
:
一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡
想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行”,猪说:“我把自己全搭进去了,而你只是参与而已。”
[编辑
]
"猪"组的角色
猪
是在Scrum过程中全身投入项目的各种角色,他们在项目中承担实际工作。他们有些像上边那个笑话里的猪,要把自己身上的肉贡献出来。
产品负责人
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事
,排出优先级,并放入产品订单。
Scrum主管(或促进者)
Scrum主管促进 Scrum
过程,他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导(因为团
队是自我组织的),而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。
开发团队
负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人(设计者,开发者等)组成,承担实际的开发工作。
[编辑
]
"鸡"组的角色
鸡
并不是实际Scrum过程的一部分,但是必须考虑他们。 敏捷
方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划,并提供反馈对于这些人来说是非常重要的。
用户
软件是为了人而开发的。有人说,“假如森林里有一棵树倒下了,但没有被人听到,那么它算是发出了声音吗?”同样地,人们可以说,“假如软件没有被
使用,那么它算是被开发出来了么?”
利益相关者(客户,提供商)
影响项目成功的人,但只直接参与冲刺评审过程。
经理
为产品开发团体搭建环境的人。
[编辑
]
Scrum会议
在冲刺中,每一天都会举行项目状况会议,被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则:
- 会议准时开始。对于迟到者团队常常会制定惩罚措施(例如罚款,做俯卧撑,在脖子上挂橡胶鸡玩具)
- 欢迎所有人参加,但只有"猪"可以发言。
- 不论团队规模大小,会议被限制在15分钟。
- 所有出席者都应站立。(有助于保持会议简短)
- 会议应在固定地点和每天的同一时间举行。
在会议上,每个团队成员需要回答三个问题:[4]
- 今天你完成了那些工作?
- 明天你打算做什么?
- 完成你的目标是否存在什么障碍?(Scrum主管需要记下这些障碍)
每一个冲刺完成后,都会举行一次冲刺回顾会议,在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在
4小时。
Scrum提倡所有团队成员坐在一起工作,进行口头交流,以及强调项目有关的规范(disciplines),这些有助于创造自我组织的团队。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意,变更他们的需求,而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。
同样,Scrum采用了经验方法– 承认问题无法完全理解或定义,而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
[编辑
]
文档
[编辑
]
产品订单
产品订单(product backlog
)是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建
的什么产品。产品订单是开放的,每个人都可以编辑。产品订单包括粗略的估算,通常以天为单位。估算将帮助产品负责人衡量时间表和优先级(例如,如果"增加
拼写检查"特性的估计需要花3天或3个月,将影响产品负责人对该特性的渴望).
[编辑
]
冲刺订单
冲刺订单(sprint backlog
)是大大细化了的文档,包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单
位,没有任务可以超过16个小时。如果一个任务超过16个小时,那么它就应该被进一步分解。冲刺订单上的任务不会被分派,而是由团队成员签名认领他们喜爱
的任务。
[编辑
]
燃尽图
燃尽图
(burn down
chart)是一个公开展示的图表,显示当前冲刺中未完成的任务数目,或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图
相混淆。A burn down chart could be flat for most of the
period covered by a sprint and yet the project could still be on
schedule.
[编辑
]
自
适应的项目管理
以下是一些Scrum的通用实践:
- 客户成为开发团队中的一部分。(例如客户肯定对开发的结果真正感兴趣。)
- 和所有其他形式的敏捷软件过程一样,Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件,同时使得
项目可以变更项目需求以适应不断变化的需求。
- 频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解,监测和管理(风险分析)。
- 计划和模块开发的透明 – 让每一个人知道谁负责什么,以及什么时候完成。
- 频繁的利益所有人会议,以跟踪项目进展 – 平衡的(发布,客户,员工,过程)仪表板更新 – 利益所有者更新 –
你必须拥有预警机制,例如提前了解可能的延迟或偏差。
- 没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。
- 在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
test
[编辑
]
Scrum术语
下面是Scrum用到的术语[4]
:
[编辑
]
角色
产品负责人
负责维护产品订单的人,代表利益相关者的利益。
Scrum主管
为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。
开发团队
由负责自我管理开发产品的人组成的跨职能团队。
Scrum团队
产品负责人,Scrum主管和开发团队。
[编辑
]
工件
冲刺燃尽图
在冲刺长度上显示每天进展的图。
产品订单
按照优先级排序的高层需求。
冲刺订单
要在冲刺中完成的任务的清单。
[编辑
]
其他
冲刺
一个时间周期(通常在2周到1个月之间),开发团队会在此期间内完成所承诺的一组订单项的开发。
分享到:
相关推荐
Scrum精髓_敏捷转型指南高清完整版
Scrum是一种广泛应用于软件开发领域的敏捷框架,它强调团队协作、迭代开发以及持续改进,以适应快速变化的需求。"Scrum精髓_敏捷转型指南高清完整版.zip"这个压缩包文件很可能是提供了一份详尽的Scrum实践指南,帮助...
### Scrum精髓:敏捷转型指南读书笔记 #### 第一章:Scrum的适用范围 - **Cynefin框架**:本书介绍了Cynefin框架作为理解Scrum适用环境的基础。该框架将工作环境划分为五个区域:复杂、繁杂、混乱、简单以及无序。...
scrum精髓,敏捷转型指南;scrum精髓,敏捷转型指南。
Scrum是一种广泛应用于软件开发领域的敏捷框架,它旨在提高团队的效率和灵活性,通过迭代和增量的方式交付高质量的软件产品。Scrum的核心理念是通过自我组织的团队、透明的流程和持续的反馈来应对变化,确保项目的...
Scrum 是一个轻量的框架,它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织 创造价值。 简而言之,Scrum 需要 Scrum Master 营造一个环境,从而: 1. 一名 Product Owner 将解决复杂问题所需的工作...
"Scrum专业Scrum Master II题库" Scrum是一种敏捷项目管理方法,旨在帮助团队更好地协作、更快速地交付价值。Scrum Master扮演着关键角色,是Scrum团队的 facilitator、 coach和servant leader。Scrum Master负责...
### Scrum Master 认证考试知识点解析 #### 标题:Scrum Master 认证考试原题 **解析**:本题目集旨在帮助考生通过Scrum Master (CSM) 认证考试,该考试评估考生对Scrum框架、原则及实践的理解与应用能力。 #### ...
Scrum 教材总结 Scrum 是一种敏捷开发框架,对于软件开发和项目管理非常重要。本文将对 Scrum 的起源、Scrum 模型、Scrum 框架、现状和为什么会失败等方面进行详细的介绍。 一、Scrum 起源 Scrum 的 idea 来自于 ...
Scrum是一种迭代式增量软件开发方法,强调在开发过程中项目的可管理性和控制。Scrum的三个主要组成部分是角色、...Scrum指南自1990年代初期以来应用于管理复杂产品的工作,并不断演进以适应不断变化的开发环境和需求。
1. **自组织团队**:Scrum强调团队的自组织能力,鼓励团队成员根据实际情况灵活调整工作方式。团队成员应该拥有足够的自主权来决定如何完成任务。 2. **迭代式开发**:Scrum通过短周期的迭代(Sprint)来实现产品的...
scrum及常见问题 ,scrum及常见问题处理解决办法等等
### Scrum 在企业中的应用与实践 #### 一、Scrum 概览 Scrum 是一种敏捷开发框架,主要用于管理复杂的产品开发项目。它强调团队合作、迭代开发、自我组织和适应变化。《The Enterprise and Scrum》由敏捷运动领袖 ...
### Scrum概述与核心概念 **Scrum**作为一种敏捷开发框架,在软件开发及项目管理领域内备受推崇。本文旨在帮助读者在短时间内理解Scrum的基本原理及其应用价值。 #### Scrum的核心理念 Scrum被定义为一种简单的...
Scrum是一种敏捷开发框架,由Ken Schwaber和Jeff Sutherland在1990年代初创立,主要用于应对复杂的项目管理问题,特别是在软件开发领域。2010年,他们发布了首版Scrum指南,以帮助全球用户理解和应用Scrum。随着时间...
Redmine 是一个开源的项目管理工具,而"redmine scrum 敏捷组件"是Redmine中的一个扩展,旨在帮助团队采用Scrum敏捷开发方法进行项目管理。Scrum是一种广泛应用于软件开发领域的敏捷框架,强调迭代和增量交付,以...
Scrum敏捷开发方法是一种以人为核心、迭代和增量式的软件开发框架,旨在提高团队的灵活性、效率和产品质量。Scrum最初是在应对瀑布模型在处理需求变更和团队协作方面的不足时发展起来的。瀑布模型强调严格的阶段顺序...
《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近...
《硝烟中的Scrum和XP:我们如何实施Scrum》源自真实的故事,Henrik Kniberg以过来人的身份,回顾了他在一年时间内带领40人团队实施敏捷转型和持续过程改进的亲身经历。在Henrik的领导下,团队经历了不同的规模,不同...