石 研;冯阿芳;张锡琨

摘要:本文介绍敏捷方法的目标、核心理念特点、基本原则和适用范围。

Abstract: The thesis introduces the goal、features of the core concept、basic principles of the agile methodology and the scope of its application.

关键词:软件开发方法;敏捷方法;指导原则

Key word: software development; agile methodology;guiding principle

中图分类号:TP31 文献标识码:A文章编号:1006-4311(2010)04-0052-01

0引言

自从20世纪70年代,软件工程产生以来,人们提出了很多软件开发方法,这些方法大都强调软件开发过程中必须遵守某些严格的规定。而且随着技术的发展,提出在对需求和技术不断变化的情况下实现快速的软件开发的要求。在20世纪90年代后期,一些软件开发人员开始强调灵活性在软件开发过程中所发挥的作用,提出一系列新的软件开发方法,这就是敏捷方法。“敏捷开发”被认为是软件工程的一个重要的发展。它强调软件开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。

1敏捷方法

敏捷开发的总体目标是通过“尽可能早地、持续地对有价值软件的交付”,使客户满意。很多客户都有一些随着时间变化的业务需求,不仅表现在新发现的需求上,也表现在对市场变化做出反应的需求上。通过在软件开发过程中加入灵活性,敏捷方法可以使用户能够在开发周期的后期增加或改变需求。

敏捷方法主要是用于需求模糊或快速变化的前提下,小型开发团队的软件开发活动。敏捷方法能够在保证软件开发成功的前提下,尽量减少开发过程中的活动和纸品,做到“刚刚好”,从而在满足所需的软件质量要求的前提下,力求提高开发的效率。

敏捷方法提出了12个指导原则:(1)在快速不断地交付用户可运行的软件的过程中,把使用户满意放在第一位。(2)以积极的态度对待需求的变化。敏捷方法的过程紧密围绕变化展开并利用变化来实现客户的竞争优势。(3)以几周到几个月为周期,尽快、不断地交付可运行的软件供用户使用。(4)在项目过程中,业务人员和开发人员最好能一起工作。(5)以积极向上的员工为中心建立项目组,给予他们所需的环境和支持,对他们的工作予以充分的信任。(6)在项目组中,最有用、最有效的信息沟通手段是面对面的交谈。(7)项目进度度量的首要依据是可运行的软件。(8)敏捷方法高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。(9)应时刻关注技术上的精益求精和设计的合理,这样能提高软件的快速应变力。(10)简单化(尽可能减少不必要工作的艺术)是基本原则。(11)最好的框架结构、需求和设计产生于组织的项目组。(12)项目组要定期对其运作方面进行反思,提出改进意见,并相应进行细调。

敏捷方法有很多具体的方法,常用的一些具体的敏捷方法有:

极限编程:它是描述敏捷方法最普遍的概念,激发软件人员创造性,是管理负担最小的一组技术。极限编程实际上是敏捷过程的一种具体形式,是提供敏捷方法最一般原则的指导方针。

水晶法:它是基于“每一个不同项目都需要不同的策略、约定和方法论。”理念的一组方法。人对于软件质量有重要影响,因而随着项目质量和软件开发人员素质的提高,项目和过程的质量也随之提高。

并列争球法:它是用迭代的方法,其中把每30天一次的迭代称为一个“冲刺”,并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品。协调是通过简短的日常会议来进行的。

自适应软件开发:在开发过程中,有一个使命作为指导,它设立项目的目标,但是并不描述如何到达这个目标。特征被视作客户价值的关键点,因此项目是围绕着构造的构件来组织并实现特征的。过程中的迭代是很重要的,因此“重做”与“做”同样关键,变化包含其中。变化不被视作改正,而是被视作对软件开发实际情况的调整。确定的交付时间迫使软件开发人员认真考虑每一个生产版本的关键需求,同时风险也包含其中,它使得开发人员首先跟踪最艰难的问题。

敏捷方法的基本原则包括:

客户参与:客户应该在开发过程中始终紧密参与其中。他们的作用是提供和排序新系统的需求并评估系统的反复。

增量式移交:软件以增量的方式进行开发,客户指定在每个增量中将要包含的需求。

人非过程:开发团队的技术应该得到承认和发扬。团队成员应该保持他们自己的工作风格,不落俗套。

接受变更:预计系统需求的变更,并设计系统使之适应这些变更。

保持简单性:致力于所开发的软件和开发过程的简单性。只要可能,就积极地去降低系统中的复杂性。

在实践中,敏捷方法所给予的基本原则有时难于付诸实施,主要有下面一些原因:(1)虽然让客户参与到软件开发过程中来的想法很吸引人,但是它的成功性依赖于有人愿意加入进来,并且肯花时间与开发团队沟通,而且此人还必须能够代表所有的系统相关人员。因此,经常是客户代表屈从于其他压力而不能全身心地投入到软件开发中来。(2)开发团队成员个人可能从性格上不太适应激烈的投入,而这正是敏捷方法的典型特征,因此他们可能做不到与其他成员良好沟通。(3)对变更做出优先级排序可能是极端困难的,尤其是对那些有很多参与者的系统,因为每个参与者会给出不同的优先级。(4)维护简单性需要额外的工作。迫于移交时间表的压力,团队成员会没有时间执行应该有的系统简化过程。

此外,软件需求文档通常是客户和软件开发组织之间合同的一部分内容,而增量描述是敏捷方法的固有内容,因此为此类开发写合同通常比较困难。

敏捷方法对适用范围也有相应的要求,必须满足下列条件才适用:需求不确定并且极易发生变更的场合。由富有责任感并积极向上的开发人员组成的较小的开发团队。用户容易沟通并且能够参与项目开发,开发范围不被限定。

2结束语

作为一种新出现软件生命周期模型,敏捷方法也不是万能的,也具有局限性,那就是适合小规模的项目。在进行具体的软件系统的开发时,每个软件开发组织都需要为它的组织、管理、员工和软件过程确定合适的生命周期模型,而且还要根据当前开发的具体的软件产品的特点适当地改变模型,一般这样的模型应结合各种生命周期模型的适当特点,扬长避短。

参考文献:

[1][美]Shari Lawrence Pfleeger,[加]Joanne M.Atlee.软件工程[M].杨卫东,译.第三版.北京:人民邮电出版社,2007.

[2]梁颖红.软件工程理论与实践[M].哈尔滨工业大学出版社,2008.