焦点期刊
在线客服

著作编辑 著作编辑

投稿邮箱: 941198995@qq.com

Scrum敏捷软件开发方法在实践中的改进和应用

时间:2014-09-25 22:31:29 阅读量:0次 所属分类:电子论文

简介。正如敏捷宣言所述:个体和交流胜于过程和工具。坚持应用持续集成和......

  论文导读::简介。正如敏捷宣言所述:个体和交流胜于过程和工具。坚持应用持续集成和测试驱动方法。和测试驱动开发(Test-DrivenDevelopment。

  论文关键词:Scrum,敏捷,持续集成,测试驱动

  0引 言

  随着软件行业的发展,基于详尽的需求分析、系统设计和把需求变更作为梦魇的瀑布模式已经逐渐被开发者们所丢弃了,而能够更快地面向市场、更好地响应客户需求变更的敏捷开发模式深得开发者们的青睐。正如敏捷宣言所述:个体和交流胜于过程和工具;可以工作的软件胜于综合的文档;客户协作胜于合同谈判;应对变化胜于遵循计划[1]。敏捷开发模式更重视软件的生产率,且适用于解决需求模糊或快速变更的问题。现今已经有很多种敏捷方法被付诸到实践中了,广为人知的有极限编程(Extreme Programming,XP)、Scrum、动态系统开发(DynamicSystem Development Method,DSDM)、自适应软件开发(Adaptive Software Development,ASD)、水晶方法(Crystal Clear)、特征驱动开发(Feature-Driven Development,FDD)和测试驱动开发(Test-DrivenDevelopment,TDD)[2]等。敏捷方法在实践中取得了巨大的成功。很多数据和实例告诉我们,敏捷是提高软件生产率不争的事实。然而过程本身不是敏捷的,但人可以敏捷,团队或者组织可以敏捷。如果只是做敏捷而不是敏捷地去做,就会导致敏捷方法应用的失败[3]。在敏捷开发方法实践中需要去体验、分析思考以及进行必要的方法改进,以切实获得采用敏捷方法所带来的最大效益。

  1Scrum简介

  Scrum是当今被广泛应用的敏捷开发模式之一。它有着自己鲜明的优势:客户成为开发团队的一部分、能够频繁提交可以工作的中间增量产品、可以不断更改项目的需求以适应用户需求的变化、不需制定详尽的不切实际的计划和编写冗长的文档使得团队更加灵活自如,自由地自我组织和自我管理使得团队积极主动、敏捷创新[4]。Scrum也有着区别于其他模式的特质。它拥有特定的成员角色:产品的负责人PO(Product Owner),Scrum主管SM(Scrum Master)和团队(Team)(适宜的人数是5到10人)。它拥有独特的实践方式:冲刺(Sprint),计划会议(Sprint Planning Meeting),评审会议(SprintReview Meeting),回顾会议(Sprint Retrospective),每日例会(Daily Meeting),产品订单梳理(ProductBacklog grooming)。它拥有着特殊的工件:产品订单(Product Backlog),燃尽图(Burn Down Chart),完成标准(Definitionof Done),产品增量(Product Increment)[1]。

  Scrum开发过程是以Sprint为增量的迭代开发过程,一般一个Sprint适宜的迭代周期是1到4周。Sprint开始时,团队从已按优先级顺序排列好的产品订单中选择适合本团队的项目,与PO澄清需求并生成同样按优先级顺序排列好的Sprint订单,并且保证在本次Sprint结束前做完。每个工作日团队都要收集汇报彼此的任务进程和余下的任务量。Sprint结束时小组展示最终的项目成果,并收集来自团队之外的反馈,用以下一个Sprint的自我提升。图1描述了Scrum的开发流程。

  2Scrum方法在实践中的灵活运用

  2.1 项目背景

  本文的项目背景是某知名通信设备公司研发中心的开发和测试工作。研发团队具有多年Scrum开发经验,团队任务是研发和测试该公司某一产品线上的几个功能模块,其中包括基于底层Linux操作系统和顶层应用层的中间件模块:启动管理和内存文件管理。

  2.2 Scrum方法的改进

  (1) 改进每日例会的模式

  使用“标题1”样式。用阿拉伯数字1,2,3…,数字之后没有任何符号,如小数点、顿号、逗号等。一般不超过一行。按照Scrum倡导的每日例会形式,每个成员应轮流回答三个经典问题,这使得我们小组的日会在很长一段时间内基本沦为一场激烈的辩论会,而这些讨论往往是徒劳的。对此,我们决定对这种已经背离Scrum宗旨的日会进行改进。改进的主题就是转变角色,让项目任务成为会议的主角,因为Sprint订单原本就是对项目任务的细化。于是新的日会改变了模式:仍然由主管主持,所有成员群视白板,但变成了一种问答形式。如图2所示,主管会按优先级顺序遍历项目,针对细化了的每个项目的每个任务提问三个问题:今天花了多少时间、做到了什么程度(日会安排在下班前一小时)?遇到了什么问题?明天怎么解决、继续做多少?相关负责成员回答问题,其他成员洗耳恭听。如此下来效果非常明显,首先是会议时间平均不超过10分钟,节省的时间等效于一笔宝贵的财富。再者是大家对各项任务的进展一目了然,同时不同项目之间不同任务之间的成员的付出、进度、成果也一目了然。这样改进后完全达到了日会目的,对这种简单高效的会议方式,团队成员是乐此不疲。

  (2) 采用事半功倍的结对编程方法

  Scrum提倡团队配置精英成员,即每个团队成员都可独当一面、技术过硬、开发经验丰富[6]。然而在软件行业起步晚、开发技术还相对落后的国内,鲜有具备十年研发经验的开发人员仍奋战在第一线的情形,一般开发人员都仅具有2到5年的研发经验。我们的团队就是一个典型的例子,8人组成的团队平均开发经验不到3年,其中还有2个新手[3]。因此,团队出现了发布的产品缺陷(Bug)多、生产率低、新手进展慢、一些模块过于依赖某一个人等许多问题。针对这样一个低效局面,我们尝试使用了结对编程方法,每个功能模块都至少由两人负责,这样就避免了因某一人缺席而导致一些模块的研发进展停滞的情况。结对编程的过程就是一个连续代码评审的过程,这无疑会提高代码的质量,并且结对编程可促进成员相互学习、彼此提升,特别是加速了新员工的成长,从而提高了整个团队的工作效率。

  (3) 重视必要的开发文档

  Scrum轻文档重开发的敏捷理念并不是杜绝所有的文档书写。文档可以帮助新人快速熟悉小组项目,也有利于当前项目结束后的维护工作,或者是后续项目的跟进。将客户的体验形成几页纸的说明文档,可以使开发人员对客户的体验有清晰的了解。这样在每次Sprint开始之前,有了定义好的产品订单,本次Sprint便可以持续、平滑地过渡到下一次Sprint[5] 。

  (4) 避免流于形式的回顾会议

  按照Scrum宗旨,回顾会议用以团队的自我提升,其重要性是显而易见的。对于软件开发来说,若不能够高效、进步和创新,则无疑是在走向灭亡。然而在实际应用中,回顾会议往往变得无所回顾,无可总结。渐渐地流于形式,甚至被一部分开发小组所抛弃,这样的例子屡见不鲜。我们团队也无例外地经历过这样的尴尬处境。对此我们采取了改进措施:回顾会议期间之所以无所回顾,究其原因是每个成员对一个月内的众多细节根本无法一一回忆。所以我们在燃尽图旁新增三栏:Good、Bad、和Ugly。团队成员在每个Sprint期间,可以就无论是技术、沟通还是管理方面的问题在这三栏中以即时贴的方式添加自己的意见,提倡的意见放在Good栏,改进意见放在Ugly栏,揭露弊病的意见放在Bad栏。即时贴所写的内容包括事件简述、日期、意见发表者。这样改进后,在回顾会议中就不会再无所回顾了。

  (5) 坚持应用持续集成和测试驱动方法

  对于敏捷模式之一的Scrum,持续集成(ContinuousIntegration)和测试驱动(TDD)同样是其两大基石[7]。在大型复杂项目实施中,软件集成无疑是一个重要的问题。要降低项目的风险、确保产品的质量,尽早且频繁、持续地集成是一种事半功倍的方法[8]。图3是我们持续集成的流程图。

  使用测试驱动可以避免像传统方法那样对测试文档的依赖。通常用户需求的变更会使维护测试文档的成本与日俱增,这样的结果显然不够敏捷,也不符合Scrum方法的宗旨[9]。如果使用测试代码来代替测试文档,就会使问题变得简单多了。测试驱动通过对测试代码不断地重构来推动软件功能代码的编写和完善,不断增加软件新特性,直至实现全部软件功能,如图4所示。这种方法不仅保证了代码的正确性,也体现了灵活适应需求变更的敏捷性。

  2.3 Scrum方法的改进成效

  经过改进Scrum之后,不但团队的生产效率得到了很大的提升,并且团队成员的积极性、工作效率、创新思维都得到了显著的提升。图5和图6是改进前后某两个Sprint的燃尽图。图表中的基准线表示在最理想的情况下每天应按时完成确定的等量任务,这时每天的生产率都是5。燃尽线是实际工作的情况。从图中不难看出,改进前团队的生产率平均不超过5,并且Sprint结束后还有部分任务完不成。改进后,不但按时完成任务而且生产率基本在5之上。

  3结 论

  公司的文化、管理模式不同,开发者的经验不同等等都决定了Scrum方法不能被按部就班地套用。Scrum宗旨是提倡灵活,因此在实际运用中的灵活改进并不有悖于Scrum的原则。相反一味的借鉴模仿只会形似而神不似,导致适得其反的结果。“敏捷”本身就意味着适时地变化,应该在敏捷和不敏捷之间寻找一种合理的折衷方案[3]。在实践中对敏捷模式进行适当的改进和灵活的运用,能够帮助我们更好地抓住敏捷开发方法的精髓,最终达到预期的目标和效果。

  参考文献

  [1]Ken Schwaber, Mike Beedle. Agile Software Development With Scrum[M].Prentice Hall, 2001.

  [2]Dean Leffingwell. 可伸缩敏捷开发:企业级最佳实践[M]. 李冬冬,译. 北京:电子工业出版社,2009.

  [3]Scrum中文网[OL] http://www.scrumcn.com/index.php.

  [4]RobertC Martin. 敏捷软件开发———原则、模式与实践[M]. 邓辉,译. 北京:清华大学出版社,2003.

  [5]敏捷方法需要文档吗?[OL] http://www.infoq.com/cn/news/2007/07/agile-methods-documentation..

  [6]HenrikKniberg. 硝烟中的Scrum和XP——我们如何实施Scrum [M]. 李剑,译. 北京:清华大学出版社,2011.

  [7]青瑞.软件工程之全程建模实现[M]. 北京:机械工业出版社,2010

  [8]柳纯录.系统集成项目管理工程师教程[M]. 北京:清华大学出版社,2009

  [9]贝克(美).测试驱动开发[M]. 孙方,译. 人民邮政出版社,2008


本文链接:https://www.133lw.com/lunwen/dzlw/6444.html