Scrum

维基百科,自由的百科全书
跳转至: 导航搜索
Scrum实施讲解
软件开发
软件开发步骤
需求分析 | 软件架构 | 软件设计 | 软件编程 | 软件测试 | 软件部署 | 軟體維護
软件开发模式
敏捷开发 | 無塵室 | 迭代式开发 | RAD | 统一过程 | 螺旋模型 | 瀑布模型 | 极限编程 | Scrum
软件开发辅助领域
配置管理 | 文档编写 | 质量管理 | 项目管理 | 使用者經驗設計
软件开发工具
编译器 | 除错器 | 性能分析 | GUI设计 | 集成开发环境


Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语里是橄榄球运动中争球的意思。

虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。

历史[编辑]

  • 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中的主要角色包括:

  1. 'Scrum Master' 是Scrum教练和团队带头人,确保团队合理的运作Scrum,并帮助团队移除实施中的障碍;
  2. 产品负责人(Product Owner),确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品投資報酬率(ROI)负责;
  3. 开发团队(Team),一个跨职能的小团队,人数3-9人,团队拥有交付可用软件需要的各种技能。

在每一次冲刺(一个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采用了经验方法– 承认问题无法完全理解或定义,而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

Scrum会议一共包含以下四种: 1) Sprint计划会议; 2) 每日站立会议; 3) 评审会议; 4) 回顾会议;

文档[编辑]

产品订单[编辑]

产品订单(product backlog)是整个專案的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要生產什么樣的产品。产品订单是开放的,每个人都可以编辑。产品订单包括粗略的估算,通常以天为单位。估算将帮助产品负责人衡量時程表和優先順序(例如,如果"增加拼写检查"特性的估计需要花3天或3个月,将影响产品负责人对该特性的渴望)。

冲刺订单[编辑]

冲刺订单(sprint backlog)是大大细化了的文档,包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位,没有任务可以超过16个小时。如果一个任务超过16个小时,那么它就应该被进一步分解。冲刺订单上的任务不会被分派,而是由团队成员签名认领他们喜爱的任务。

燃尽图[编辑]

燃尽图(burn down chart)是一个公开展示的图表,显示当前冲刺中未完成的任务数目,或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃盡圖可能在一次衝刺的大部分時間內都維持平坦,但計畫仍然可以按照既定時間進行。

自适应的项目管理[编辑]

以下是一些Scrum的通用实践:

  • 客户成为开发团队中的一部分。(例如客户肯定对开发的结果真正感兴趣。)
  • 和所有其他形式的敏捷软件过程一样,Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件,同时使得项目可以变更项目需求以适应不断变化的需求。
  • 频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解,监测和管理(风险分析)。
  • 计划和模块开发的透明 – 让每一个人知道谁负责什么,以及什么时候完成。
  • 频繁的利益所有人会议,以跟踪项目进展 – 平衡的(发布,客户,员工,过程)仪表板更新 – 利益所有者更新 – 你必须拥有预警机制,例如提前了解可能的延迟或偏差。
  • 没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。
  • 在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。

Scrum术语[编辑]

下面是Scrum用到的术语[4]:

角色[编辑]

产品负责人 
负责维护产品订单的人,代表利益相关者的利益。
Scrum主管 
为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。
开发团队 
由负责自我管理开发产品的人组成的跨职能团队。
Scrum团队
产品负责人,Scrum主管和开发团队。

工件[编辑]

冲刺燃尽图 
在冲刺长度上显示每天进展的图。
产品订单 
按照优先级排序的高层需求。
冲刺订单
要在冲刺中完成的任务的清单。

其他[编辑]

冲刺 
一个时间周期(通常在2周到1个月之间),开发团队会在此期间内完成所承诺的一组订单项的开发。

Scrum在其他领域的应用[编辑]

虽然Scrum最初只应用于软件开发,它也可以被成功地应用于其他产业。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的,增量的过程。

Scrum用于产品开发[编辑]

将Scrum应用于产品开发是在《T新新产品开发游戏》(哈佛商业评论 86116:137-146, 1986年)第一次提出,之后野中郁次郎竹内弘高合著的《创造知识的企业》(牛津大学出版社,1995年)进行了详细的阐述。今天Scrum被用于开发金融产品,互联网产品,以及医药产品。

Scrum用作营销项目管理方法[编辑]

由于市场营销通常以專案的方式运作,许多一般專案管理的原则应用在市场营销上。市场营销也可以像專案管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要,这是因为团队的每一个成员都可以了解其他人在做些什么,以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以:

  • 在早期发现可能的问题,可以更快地,最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”,Scrum鼓励每一个团队成员描述他所遇到的困难,而这个困难可能会对整个团队的工作造成影响。
  • 降低财务风险。 在每一个冲刺周期的开始,企业所有者可以不付出任何代价的改变任何市场营销的因素:包括增加投资以扩大顾客数量,减少投资直至未知风险被减轻,或用于支持其他活动。
  • 使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效,市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的,但重要的任务的交付时间也变得更容易。
  • 使得客户以不同的方式参与。

参见[编辑]

外部链接[编辑]

参考文献[编辑]

  1. ^ Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
  2. ^ Peter DeGrace, Leslie Hulet Stahl, Wicked problems, righteous solutions, 1990, ISBN 0-13-590126-X
  3. ^ Jeff Sutherland, AGILE DEVELOPMENT: LESSONS LEARNED FROM THE FIRST SCRUM, 2004
  4. ^ 4.0 4.1 4.2 4.3 Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X