实训专题报告
实训专题报告
题 目:敏捷开发-SCRUM技术的简
介及其应用和扩展
实训名称: 认识实训
班 级: 102013
学 号: 10201318
学生姓名: 周海莹
指导教师: 李健利
哈尔滨工程大学
2011年9月6日
摘 要
随着科学技术的迅猛发展,计算机已成为当今社会必不可缺的一部分,随之应运而生的软件工程的地位也在不断凸显。软件工程中包含需求、设计、编码和测试四个阶段,敏捷开发被认为是软件工程的一个重要的发展。它强调软件开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。它是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。相对于"非敏捷",它更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。
SCRUM方法是目前敏捷软件开发方法中的一个比较新兴的开发方法,它是一种迭代式增量软件开发过程,通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。本文在介绍了敏捷开发SCRUM的组成成员及各个成员在敏捷软件开发过程中所扮演的角色,并分析和归纳了SCRUM方法各阶段特点,同时还涉及了SCRUM在软件开发过程中的应用及其发展趋势。
关键词:敏捷软件开发;SCRUM;沟通合作
近年来,随着科学技术的不断发展,软件工程的发展前景也越来越广阔。作为一种软件开发的方式,敏捷开发被认为是软件工程中一个重要的发展方向,在如今的企业及个软件开发过程中发挥着越来越重要的作用。而作为敏捷软件开发的一种框架,SCRUM的运用也越来越广泛。因此,我们有必要了解他们的应用,更加需要关注它的发展。
1.敏捷开发
1.1敏捷开发总体介绍
简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
1.2敏捷开发的历史
许多人认为,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。但是,实际上敏捷方法,特别是迭代和增量开发方法(IID)起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中,一些极限编程方法如测试先行等也被使用。此后,迭代和增量开发被IBM联邦系统部(FSD)和沃森研究中心(Watson Research Center)采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中,温斯顿.罗伊斯(Winston Royce)建议在一个项目中使用两次瀑布模式,也就是使用两次迭代
[1]。
20世纪70年代,最早的有记载的使用迭代和增量开发的主要项目之一,是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码,进行得非常成功。迭代和增量开发从此开始稳步发展,越来越多的项目开始使用这种开发模式。在1976年,Tom Gilb在他的著作《软件度量》(“Software Metrics”)一书中阐述了他的迭代和增量开发实践,这可能就是第一部阐述这种方法的书籍[2]。迭代和增量开发的另一次出色发挥,是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部(IBM FSD)在1977至1980年完成。一些典型的敏捷做法,如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。
20世纪80年代,更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年,巴里贝母(Barry Boehm)正式定义了使用迭代开发的螺旋模型(Spiral model)。80年代初,在美国国防部发生了一件有趣的事情。美国国防部一直以来都要求其软件开发商在开发过程中使用严格的瀑布开发模型。但是到了1987年末,国防部开始“建议”使用迭代和增量开发作为软件开发模式。后来美国国防部的项目审查显示,早期使用瀑布模式开发的软件项目,有75%以失败告终,有些开发出来的产品根本没有被使用过,只有2%的软件产品无需大量修改就能被正常使用。
20世纪90年代,推荐使用迭代和增量开发的出版物和文献显著增加。在经历了多次有“瀑布心态”(‘waterfall mentality’)项目的失败之后,美国国防部开始“要求”而不是像80年代那样仅仅是“建议”他们的软件开发商使用IID开发模式。Rational统一开发过程(Rational Unified Process)也是在这一时期产生并发展起来的,它具有更规范的迭代渐进过程。到2000年底,更多的敏捷方法被广泛推广并被使用于各种不同的项目中。2001年二月,一组由17位在DSDM,XP,Scrum,FSD等领域的专家组成的代表团齐聚美国犹他州,寻找这些方法的共同点。最终,这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟。
1.3敏捷开发的组成
敏捷开发由几种轻量级的软件开发方法组成。它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等[3]。
1.4 敏捷开发的原则和方法
1.迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。
2.增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。
5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
2.SCRUM
2.1 SCRUM简介
SCRUM是一个敏捷开发框架, 是一个增量的、迭代的开发过程.。在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的迭代周期称为一个Sprint,每个Sprint的建议长度2到4周。SCRUM由一个开发过程,几种角色以及一套规范的实施方法组成。它是一种迭代式增量软件开发过程,通常用于敏捷软件开发,也可以被用来作为一种管理敏捷项目的框架。它包括了一系列实践和预定义角色的过程骨架。SCRUM中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。
2.2 Scrum的发展历史
1986年,竹内弘高和 野中郁次郎阐述了一种新的整体性的方法 ,该方法能够提高商业新产品开发的速度和灵活性:他们将这种新的'整体性方法与橄榄球相比较,前者各阶段相互重叠,并且由一个跨职能团队在不同的阶段完成整个过程,而后者整个团队"tries to go to the distance as a unit, passing the ball back and forth"。他们对来自汽车,照片机器,计算机和打印机等产业的案例进行了研究。1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为 Scrum,在竹内弘高和 野中郁次郎的文章中提到的橄榄球术语。1990年代初,肯·施瓦伯在其公司使用了一种方法Advanced Development Methods(先进开发方法),这种方法后来发展为Scrum。同时,杰夫·萨瑟兰在Easel公司开发了一种类似的方法,并首次称之为Scrum[4]。1995年,在奥斯汀举办的OOPSLA '95上,萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作,将上述的文章,他们的经验,以及业界的最佳实践融合起来,形成我们现在所知的Scrum。2001年,施瓦伯与 麦克·比窦(Mike Beedle)合著了《敏捷软件开发-使用Scrum过程》一书,介绍了Scrum方法。
2.3 SCRAM定义的4种主要的角色:
1、产品拥有者(Product Owner):该角色负责产品的远景规划,平衡所有利益相关者(stakeholder)的利益,确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。
2、利益相关者(Stakeholder):该角色与产品之间有直接或间接的利益关系,通常是客户或最终用户代表。他们负责收集编写产品需求,审查项目成果等。
3、Scrum专家(Scrum Master):Scrum专家负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。
4、团队成员(Team Member):即项目开发人员。
2.4 SCRUM的特点
1.Scrum规定了一个非常简单的开发流程。
2.Scrum是现有设计流程的总结。
3.Scrum以团队为基础,是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
4.Scrum是一个控制由利益和需求冲突导致的混乱的流程。
5.Scrum是改善交流并最优化合作的方式。
6.Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
7.Scrum是最大化生产率的一种方法。
8.Scrum适用于单一的项目到整个企业。Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
9.Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲,并让他们发挥到最佳水平。
2.5 SCRUM框架
Ⅰ 三个角色
1.产品负责人(Product Owner)的职责如下:
• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的profitability of the product (ROI)负责。
• 根据市场价值确定功能优先级。
• 每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)。 • 接受或拒绝接受开发团队的工作成果。
2.ScrunMaster作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。他必须:
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 作为团队和外部的接口,屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
3.团队一般情况人数在5-9个左右,作为团队,需要做到以下几方面
• 团队要跨职能
(包括开发人员、测试人员、用户界面设计师等)
• 团队成员需要全职。(有些情况例外,比如数据库管理员)
图2.1 SCRUM框架
• 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
• 高度的自我组织能力。
• 向Product Owner演示产品功能。
• 团队成员构成在sprint内不允许变化。
Ⅱ 四个仪式
1.Sprint计划会议
• 团队从产品backlog中挑选他们承诺完成的条目。
• 创建Sprint Backlog
•标识具体的任务并为任务做估算
•由团队协作完成,而不是Scrum Master
• 考虑了高层设计
2.Sprint评审会议
Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的干系人参加。
• 团队展示Sprint中完成的功能
• 一般是通过现场演示的方式展现功能和架构
• 不要太正式
•不需要PPT
•一般控制在2个小时
• 团队成员都要参加
• 可以邀请所有人参加
3.每日站会
每日站会开会的时间不是很长,基本是总会昨天做了什么时事,遇到了什么问题,然后今天准备做什么事情。它具有以下优点:
• 时刻了解团队成员的工作情况
• 沟通-- 让我们更加了解对方,了解项目
• 遇到问题时,大家讨论,团队的力量,很快就会有解决方案。
• 每日计划-- 自己不会盲目,不会找不到事情。
• 如果当天没有安排,小组长肯定根据实际情况帮你安排一些事情。
• 至于时间的把握,会随便的每日站会次数的增加,相应的也会有所改进。
4.Sprint回顾会议
• 团队的定期自我检视,发现什么是好的,什么是不好的。
• 一般控制在15-30分钟
• 每个Sprint都要做
• 全体参加
•Scrum Master
•产品负责人
•团队
•可能的客户或其它干系人
在Sprint回顾会议上,全体成员讨论有哪些好的做法可以启动,哪些不好的做法不能再继续下去了,哪些好的做法要继续发扬。
Ⅲ 三个物件
1.产品Backlog
• 一个需求的列表。
• 一般情况使用用户故事来表示backlog条目
• 理想情况每个需求项都对产品的客户或用户有价值
• Backlog条目按照商业价值排列优先级
• 优先级由产品负责人来排列
• 在每个Sprint结束的时候要更新优先级的排列
2.Sprint Backlog
Sprint backlog定义了Sprint的目标,明确了Sprint过程中具体需要完成的任务,管理Sprint的backlog有以下特点:
• 团队成员自己挑选任务,而不是指派任务
• 对每一个任务,每天要更新剩余的工作量估算
• 每个团队成员都可以修改Sprint backlog,增加、删除或者修改任务
3.燃尽图(Burn Down Chart)
燃尽图直观的反映了Sprint过程中,剩余的工作量情况,Y轴表示剩余的工作,X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少,在开始的时候,由于估算上的误差或者遗漏工作量有可能呈上升态势。实例如图所示:
2.6 SCRAM的应用
在当今社会中,许多公司面临着诸如产品投放市场的时间太慢、项目失败的比例高的离谱、投资回报低,经常失败、对变化与变更的响应,难度大且成本高、客户体验及客户为导向很差、软件质量不过关、生产力需要大幅提高、员工士气,动力及责任感很低、需要普遍的微观管理、人员流失率特别高等一系列严峻的问题[5]。在这样的问题面前,Google、IBM、Nokia、Siemens、Philips、Microsoft等越来越多的企业开始使用Scrum解决这些问题。特别是在Yahoo,在全球有超过200个团队(超过两千人)使用Scrum进行面向用户的项目、关键的基础设施项目、分布式项目、全新产品开发或维护型项目。
下面的这份调查的数据是在Yahoo采纳Scrum后18个月时采集的,它反映80个团队的情况。调查采用匿名方式,得到84%的调查响应率。
①团队生产力的对比图2.2燃尽曲线
②士气的对比 图2.3 团队生产力的对比图
图2.4 士气的对比图
③责任感与主人翁意识的对比
图2.5 责任感与主人公意识的对比图
④协作与合作的对比
图2.6 协作与合作的对比图
⑤交付质量的对比
图2.7 交付质量的对比图
⑥有多少人愿意使用SCRUM
图2.8 多少人愿意使用SCRUM图
以上的调查实例的结果显示,SCRUM是一种高效而且人们乐于接受的敏捷开
发形式,这种方式也受到了越来越多的关注与支持,其前景跟是值得期待。
3.敏捷开发-SCRUM的实施过程及应用的拓展
3.1敏捷开发-SCRUM的名词解释
表3.1 敏捷开发的主要名词表 1.Backlog:可以预知的所有任务,包括功能性的和非功能性的所有任务。
2.Sprint:一次跌代开发的时间周期,一般最多以30天为一个周期。在这段时间内,开发团队需要完成一个制定的并且最终成果是一个增量的,可以交付的产品。
3.Sprint backlog:一个sprint周期内所需要完成的任务。
4.ScrumMaster:负责监督整个Scrum进程,修订计划的一个团队成员。
5.Time-box:一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟
6.Sprint planning meeting:在启动每个sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:产品Owner和团队成员将backlog分解成小的功能模块,决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
7.Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目:今天完成了什么?遇到了障碍无法继续下去?明天要做什么?通过该会议,团队成员可以相互了解项目进度。
8.Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。
9.Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。
3.2 敏捷开发-实施SCRUM的过程介绍[6]
Ⅰ 确定Sprint Backlog
将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
Ⅱ 召开sprint planning meeting
划分,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的,并不是按人天计算。
Ⅲ sprint开发周期
进入sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。 Ⅳ 成果演示
整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner。
Ⅴ 回顾
团队成员最后召开Sprint retrospective meeting,总结问题和经验。
3.3敏捷开发-SCRUM宣言
◆个体和交互胜过过程和工具
◆可以工作的软件胜过面面具到的文档
◆可户合作胜过合同谈判
◆响应变化胜过遵循计划
4.敏捷开发-SCRUM的扩展
一般情况一个团队的人数控制在5-9人,在运用到大型项目中时,可以采用多团队,通过team of teams来扩展Scrum[7]。影响扩展的因素有如下几方面
•团队规模
•项目类型
•项目周期
•团队分布
在实际的敏捷开发中,Scrum曾被用于超过1000人团队规模的项目。此时,则需用到Scrum Of Scrums。Scrum of Scrums是把Scrum扩展到大型项目团队一个重要的实践。Scrum of Scrums是跨团队的沟通与交流。一般做法是由各个Scrum团队的代表参加Scrum of Scrums会议,会议同样要采用固定的频率和时间箱机制,频率可以有团队根据自身情况确定,一般可以一周2到3次,不一定要每天。对于会议长度,Ken Schwaber的建议是控制在15分钟,会上提出的问题应及时组织相关人员处理。
5.总结
在当今这个追求效率的时代,高效地开发出有品质的软件对各个行业的企业都是至关重要的,对最终用户尤为重要。软件企业不再能忍受18个月的产品周期,它们正在寻求各种方式变得更加灵活和多变以适应不断变化的市场需求。敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。 它一个渐进的,协作的方法,其目标是有效及时地生产出高质量的软件。
虽然关于敏捷是否过于随意和无纪律的争论还在继续,但有一个事实:人们对敏捷模式和精益开发的关注兴趣越来越强。仅仅在IBM一家,过去的两年中,敏捷项目的数量从5个增加到了200多个。本文基于这一事实,对敏捷开发及其中常见的框架-SCRUM的各个方面进行了详细的解释,并指出了敏捷开发-SCRUM的扩展方向,虽然内容比较简单,但对于初学者疾病不了解敏捷开发的人有一定的参考价值。
参考文献
[1]贾子河.轻松SCRUM之旅[M].北京:电子工业出版社,2009,1(1):90-110.
[2](瑞典)Henrik Kniberg, 李剑译.硝烟中的 Scrum 和 XP[M].
北京:清华大学出版社.2011,1(1):55-68.
[3](美)Ken Schwaber ,李国标译.SCRUM敏捷项目管理[M]. 北京:清华大学出版社.2007 ,3(1):102-105.
[4](美)史威伯.Scrum与企业管理[M].世界图书出版公司.2008,6(2):36-55.
[5]张智海,周国祥.Scrum方法的研究与分析[J]. 合肥工业大学计算机与信息学院.2010,33(2):24-36.
[6]张晶晶.敏捷开发的推行[J]. 武汉大学计算机学院. 2010, 27(8):28-35.
[7]邱强.敏捷开发在软件开发中的应用[J]. 山东大学. 2009, 26(22):79-93.