敏捷开发

2024-08-06

敏捷开发（精选11篇）

敏捷开发篇1

伴随着世界经济和技术的大力发展,计算机技术得到了更加广泛的应用,越来越多的工作需要依赖计算机的智能和高效。新的软件的出现都伴随着新的软件开发模式的出现,新的软件开发模式出现的原因就是解决在固定模式中出现多变的需求。而传统的开发模式存在着面对需求变化困难,维护和扩展性差导致系统的二次开发成本较高,敏捷开发模式应运而生。因为人们的需求各种各样,为了使人们的需求得到解决,软件技术也在进行不断更新完善,所以敏捷技术的产生也为敏捷开发模式的实施提供了有效的保证和可行性。

1 敏捷开发

敏捷开发是由15个科学家共同提出来的,其中包括来自思特沃克公司 ( Thought Works) 著名的软件大师马丁·福勒 ( Martin Fowler)[1]。敏捷开发即一种全新而快捷的软件开发模式,是把人放在第一位,以满足用户不同需求为导向的开发模式[2]。应用敏捷开发的方法,要求团队成员具有很强的主动性,满足了高内聚、松耦合的原则把项目分成了若干个小组。较少的文档准备和分组的新方式缩短了软件开发周期,开发过程中的多次迭代和测试提高了软件的质量[3]。

2 敏捷技术的重要性

从目前敏捷开发的研究现状中,我们可以看到在任何一个软件的开发过程中,任何的一种模式都不是能解决所有问题的万能钥匙,所以在软件开发过程中应全面考虑所有的问题,不管是开发方法、设计模式还是设计架构都是必须考虑的重要因素,而就目前敏捷开发的应用研究来看,敏捷开发的过程,对技术并没有明确的指导思想,这也正是多数项目在应用敏捷开发过程中失败的重要因素。

从根本来说,敏捷开发不仅是一个软件开发过程的方法论,准确地说它更是一种思想,但这种方法是建立在敏捷技术上的,敏捷技术为这一方法的实施提供了可行性,只有敏捷的技术才能支撑敏捷开发的实施[4]。真正的敏捷开发不只是管理层次的敏捷、项目参与人员的敏捷,架构的设计也应该是敏捷的,编程思想也应该是敏捷的,这才是实至名归的敏捷开发。在项目真正进行过程中,为了能更好地发挥敏捷开发的优势应做到管理与技术同步规范。管理与技术是不可分割的,二者相辅相成,技术的敏捷使得敏捷开发方法的实施具有一定可操作性,是敏捷开发方法的基石,如果没有相关技术的支持,敏捷开发是不能完全发挥效应的甚至是不可行的。只有做到管理与技术同步敏捷,在管理的过程中得到相应技术的支撑,敏捷开发方法才能发挥真正的敏捷,才是真正的敏捷思想。

2. 1 简单三层

敏捷开发方法要求在敏捷开发实施过程中,如何保证开发团队的每个开发人员能够独立地进行系统模块开发是敏捷开发能否成功的关键因素。而以往的传统开发技术,并没有将系统模块化,整个系统的耦合性较高,依赖性较强,使用传统的开发技术并不能实施敏捷开发方法,使得敏捷开发提倡的系统各模块之间并行开发成为空想。简单三层却为这一要求提供了可行性。

三层架构由底层至上层分为数据访问层 ( Data AccessLayer,DAL) ,业务逻辑层 ( Business Logic Layer,BLL) ,用户界面 ( User Interface,UI)[5]。简单三层将界面的呈现、业务逻辑的处理以及访问数据库很好的分离开来,因此在系统实现编码过程中不仅可以实现系统各模块的并行开发,而且不要求全能型的开发人员,只需精通其中一层即可参与到项目当中,在保证工作高效且代码质量的同时节约了开发成本[6]。在测试方面,三层也可同步进行,可以解决敏捷开发在测试环节中给项目带来的成本偏高问题,在支持敏捷开发实施的同时,又保证了整个系统的安全,降低了系统的复杂性,无形之中也提高了项目参与人员的积极性,使得敏捷开发能够顺利进行。

2.2 抽象工厂模式

敏捷开发提倡的是拥抱变化,要求在开发过程中进行多次的迭代,项目团队进行周期性的交流沟通,随时应对客户的需求变化,勇敢地面对变化,对于用户的反馈,程序员要有勇气对已经编写好的代码进行适当的修改[7]。敏捷开发里所说的勇于接受变化并不是简单的要求项目团队在客户提出新的要求时,就将之前的系统全部放弃,从头再来,这并不是真正意义上的敏捷开发。但是面对这样的需求敏捷开发只是单纯的提出了要求,并没有对此有进一步的说明和指导,而为了满足更换数据库的需求重新编译数据操作类就相当于项目从头开始,又不是最好的解决办法。如何在面对客户需求的时候,尽可能地减少代码的修改量,代码的复用性是一个关键因素。想要提高代码的复用性,就想到了设计模式,在当前的设计模式中,抽象工厂模式很好地解决了这一问题。

作为创建型模式的抽象工厂模式是23种设计模式中的一种,所谓创建型模式就是不需要自己实例化对象,而是由创建型模式来代替新操作[8]。抽象工厂模式指的是提供一个创建一系列相关或者相互依赖对象的接口,而不需要指定它具体的类[9]。该类设计模式是专门针对需求的变化来达到提高代码复用性目标的一种模式,它就相当于一个实实在在的工厂,只不过与我们现实生活中的工厂不同的是现实生活中的工厂是用来生产产品,但是这里的工厂是用来管理变化的。

使用抽象工厂模式将可变的进行封装,以接口的形式呈现,在三层中应用抽象工厂模式,在不需要修改以前代码的前提下轻松地解决了更换数据库类型这一需求,并且在系统开发完成之后甚至是使用过程中,都可轻松地更换数据库类型,有效地解决了由于需求变化导致开发周期延长,并且为系统的后期维护降低了成本。

2.3 ASP. Net MVC

客户的需求贯穿于整个项目中,虽然敏捷开发中采取先测试再编码的方式有效地应对了客户需求的变化,但是并不排除客户对测试满意,开发完成之后又提出了新要求的可能性存在。对于大多数客户来说需求的变化主要体现在系统功能和界面展示方面,针对这一可能性传统的敏捷开发并没有很好的解决办法,只能重新编写,重新测试,但是这一问题是周而复始的,这样的做法治标不治本。应对这一状况就应考虑到从技术方面入手。

在通常情况下,系统的页面开发都是用网页表格( Web Form) 进行,虽然网页表格 ( Web Form) 操作简单,可以直接拖控件对页面完成布局工作,但是它的页面展示与后台逻辑代码的耦合度较高,在遇到客户对页面布局要求变更的时候,不仅要进行页面布局的修改,还要将相应的页面逻辑进行修改,这无疑多做了很多没有必要的工作,这时ASP. Net MVC框架成了解决这一问题的第一选择。

ASP. Net MVC是微软在2009年对外公开发布的第一个开源的表示层框架[10]。ASP. Net MVC模式是一种表现模式,它可以将表现层分成模型 ( Model ) 、控制器( Controller) 和视图 ( View) 三个组件,有效地分离了页面展示与用户界面 ( UI) 逻辑代码,所以ASP. Net MVC是一个更加倾向于用户界面层 ( UI) 的表现层框架,是网页表格 ( Web Form) 的另一种选择[11]。在面对客户对页面展示需求变化的时候,只需更改相应页面的展示效果即可。

3 敏捷技术应用实例

3. 1 项目简介

本校的博士研究生招生工作在2013年之前均是通过工作人员手工的录入以及核对完成的,因此,本校博士招生工作存在效率低下,管理无序,数据安全性较差等诸多问题,实施办公自动化对于我校的博士招生工作具有重大意义。本项目将采用本文所提及的融合敏捷技术的敏捷开发方法对系统进行开发。

3.2 敏捷技术在开发中的具体应用与实现

根据上述分析,博士研究生招生系统的整体架构见下图。

从上图中我们可以看到,本系统结合了简单三层架构、抽象工厂设计模式和ASP. Net MVC框架三大技术,本系统使用2011年发布的ASP. Net MVC3. 0版本[12]。本论文主要从这三个技术的应用上进行详细论述,来论证敏捷技术对敏捷开发的重要性。

3. 2. 1 抽象工厂模式在数据访问层的应用

对于本系统的开发主要是针对学生各种信息的管理与操作,并且录取的学生信息数据库要与我校现有的各种学生工作系统进行衔接,而所用数据库并不相同,对现在已经使用的系统进行修改并不是一个好办法,只有针对目前着手开发的博士研究生招生系统进行完善,来迎合不同数据库的需求。解决这一需求的办法就是抽象工厂模式。本文以考生登录功能为例进行技术应用说明。

创建抽象工厂类,利用 . Net的反射机制获取数据访问层的程序集和命名空间的名称,通过数据访问接口层来创建user_ infor数据表的实体类,并采用缓存技术来提高系统性能,设置当前应用程序指定Cache Key的Cache值的核心代码如下:

由于数据访问层融合了抽象工厂设计模式的思想,所以业务逻辑层调用数据访问层是通过数据访问接口层创建相对应的数据工厂实例,并没有指定具体的数据操作类,因此,在面对更改数据库类型时,只需修改配置文件的程序集和命名空间的Value值即可,配置文件代码如下:

由此可见,应用了抽象工厂模式和反射机制加上配置文件的使用,在不需要修改系统代码的前提下轻松实现了异库移植操作,并且为本项目实施敏捷开发时适应了需求且缩短了开发周期。

3. 2. 2 ASP. Net MVC 框架的应用

在ASP. Net MVC中UI逻辑在Controller组件中进行编译,Controller负责将数据从Model取出传递给View[13]。在本系统里,ASP. Net MVC代替网页表格 ( Web Form)作为三层中的用户界面层 ( UI) ,所以在界面展示编译中,ASP. Net MVC框架中的控制器 ( Controller) 组件则负责与业务逻辑层进行对话,从业务逻辑层调用校验用户的方法来获取数据库中的考生登陆信息。判断登陆是否成功的部分代码如下:

前台的页面布局交由视图 ( View) 组件负责,由于它与控制器 ( Controller) 组件的低耦合性,视图 ( View)的页面展示只需单纯的Html标签即可实现,并且不需要将标签ID传到后台,实现了UI展示与UI逻辑的彻底分离。登录页面的视图 ( View) 核心代码如下所示:

从以上代码我们可以看出,视图 ( View) 页面都是由Html标签实现,所以在更换页面布局的时候就不需要考虑前台标签与后台逻辑的绑定问题,不需要修改用户界面 ( UI) 逻辑代码。

4 结论

敏捷开发是一种以需求为导向的驱动开发方法,需求的变化会给整个系统带来副作用,所以需要自动化去支持变化,在应对变化的同时保证敏捷开发方法在项目实施的成功率和系统质量,缩短开发周期,解决敏捷开发在管理上不能解决的问题。结合了简单三层、抽象工厂模式和ASP. Net MVC开源框架的敏捷开发使得开发团队在多变的环境下按时按质按量地完成了本校博士研究生招生系统的开发。由此可见,结合了敏捷技术的敏捷开发将敏捷开发方法发挥到极致甚至在敏捷开发方法的基础上进一步缩短项目周期,提高软件质量和软件的维护性、扩展性。

敏捷开发篇2

敏捷开发，曾经对它的理解就是没有文档的快速开发，先做原型，针对原型面对面交流，按照大家认可的原型再做快速开发，多次的面对面讨论原型，不断迭代原型，针对每次迭代的原型进行快速开发。众所周知，写软件开发文档是每一个程序员都懒于做的事情，认为比较痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过培训学习之后，我对敏捷开发有了一些新的理解。

首先，对敏捷开发下个定义，借用百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。

1、架构师的重要性

首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要眼观大图，并关注最终成果，这就要求领导者及架构师有深厚的行业背景、创新能力、以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块、产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了更高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

2、能够随时应对变化的结构，适应需求变化，并能驾驭需求变化能够随时应对变化的结构，比遵循计划更重要。计划不要考虑太远，因为各种环境都在发生变化，随着软件的提交，需求也许会发生变化。完美的甘特图能够体现对项目的整体控制力，但是详细的甘特图也是不切合实际的。感觉一般做一周的计划，是最切合实际的。

3、尽早地、持续地交付有价值的软件来满足客户需求

经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品成果就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到可以交付的标准。

4、严格执行单元测试

所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。“Y23理论”教导我们不要忽视细小的错误，如果不把细小的错误消灭掉，它会给你带来毁灭性的重创。

5、每日站立会议，面对面交流

各团队成员的工作相对比较独立，对其它成员的工作了解不多，不利于整个项目的发展，每个成员容易歇入研究的死胡同。所以在团队内部，每日站立会议、面对面交流是最具有效果并且富有效率的传递信息的方法。每日站立会议要求每个人必须定点进入会议状态。每日会议前每个人要更新自己的任务面板。每日会议中决定要签出的任务，并在会议后更新任务面板，并在任务便签上注明任务的签出人。

6、关注成果，把工作按照重要性和紧急性进行分类，权衡工作重点团队成员围绕“眼观大图，关注成果”这一导向，把自己的近期工作按照重要性和紧急性进行分类，分为四类：

1、重要、紧急

2、重要、不紧急

3、不重要、紧急

4、不重要、不紧急。根据四类情况对自己的近期工作进行权衡，把握工作重点，紧扣要事，使近期工作得以顺利开展，使远期工作也得以顺利进行。

敏捷开发篇3

“实际上,IBM、HP在美国的影响力已经远远不及在中国,因为它们的某些开发模式已经越来越陈旧。”近日,ThoughtWorks企业创始人及执行董事Roy Singham来到中国,在问及软件企业在产品开发过程中的技术先进性问题时,Roy如此回答。

据悉,Roy和他创办的ThoughtWorks是业界公认的企业架构、敏捷开发、涉及大规模离岸团队的大型软件开发、开源软件、Ruby、.Net、Java和Web Service等领域的专家。

RoySingham认为,传统的软件开发方式是以预测为主的,而敏捷式开发是以适应性为主的。传统的软件开发方法就是把用户所想要的功能详细记录下来,这些需求被固定下来,然后以此作为基础,计划整个项目的开发;敏捷开发的价值衡量从业务实现出发,而不是按时间、按计划完成。敏捷式开发也会在开始做一个详细的计划,但是这个计划是在开发当中不断根据情况来进行调整、变化的。

RoySingham表示,敏捷开发已经在国外的众多软件开发公司中盛行,但在中国还处于普及阶段。他认为,未来在用户的需求下,中国也一定会越来越多地接触敏捷开发。这是因为,公司需要想办法降低开发成本、提高软件可靠性、缩短开发时间,并且确保应用软件真正有助于用户。敏捷编程可通过减少开发人员在设计及开发应用软件中所犯的错误来降低开发成本。

在中国,IT服务较为盛行的部分原因是用户使用的软件需要大量的维护工作,而某种程度上,这种维护工作就可以在软件商开发软件的过程中避免,“敏捷开发就能做到这一点。但是为了利益,现在很多企业还没有应用这种开发方法。” RoySingham说道。

敏捷开发方法综述篇4

1 敏捷开发方法概述

1.1 简介

敏捷开发方法是将一个软件开发项目分成了若干个很小的模块化部分。每个部分在迭代过程中逐个解决, 然后就像是搭积木一样逐渐添加到整个应用软件上, 最后所有部分完成后, 形成一个完整的软件系统。从字面来看敏捷开发方法意味着高效和快捷, 是软件使用过程中的一种轻型的、迅速的、有效的科学方法。[1]在重型方法中, 开发团队往往枉费了太多精力和时间在一些无关紧要和重复的中间环节上, 而敏捷开发方法则有效地避免了这种毫无意义的浪费。在无过程或者说是过于繁琐的过程中, 敏捷开发方法寻找到了一种平衡, 以简洁的步骤获得了满意的效果。

1.2 特点

敏捷开发方法主要有两个特点, 首先[2]它是“适应性”而不是“预设性”的。传统的重型方法是针对软件开发项目的很长的时间跨度内做出详细的规划, 然后按照规划进行开发。而这种规划方法在规划完成之后很难再进行修改, 而敏捷型方法则不然。敏捷开发方法的目的就是要适应计划变化的过程, 甚至通过改变自身以适应新的变化。其次, 敏捷开发方法是面向人的, 而不是面向过程的, 它们努力使软件开发工作能够针对和适用于人的特点, 使软件开发成为一项愉快而非枯燥的活动, 最大可能地发挥人的创造能力

1.3 基本原则

敏捷开发注重的是人再软件开发中的重要作用和迅速适应和应对变化的能力。有效的团队合作、密切关注当前的代码是敏捷软件方法最为强调和重视的两个基本原则。开发人员和管理人员通过当前的代码能够知道当前他们拥有什么, 但是不能保证将来会获得什么, 原因就是不能预期将来的变动。密切关注当前的代码是为了在一个真实可靠的基础上建立开发工作。敏捷开发方法注重的真诚的交流与合作, 相对于读写文档而言, 敏捷开发的信息交流更加方便快捷, 能够大大提高读写文档的效率和时间, 降低文档工作量;设计师们可以共同讨论, 集思广益, 获取最佳设计。总而言之, 有效的团队合作能够获得高质量、快速度的软件开发, 还能有效降低开发成本。

2 几种常见的开发方法

2.1 极限编程

极限编程XP强调的理念是沟通和反馈, 是一种典型的小组开发方法, 适用于十人以下的项目组或是开发地点集中的场合, 在一些需求模糊或者是挥发性强的场合被业界人士广泛应用。在软件开始初期, 极限编程XP并不要求开发人员编制很多的文档。它提倡的是先行测试, 目的是将之后出现bug的几率降到最低。[3]极限编程的目标是将较为模糊、变化较大的客户需求在最短的时间内, 转化为符合客户要求的软件产品。其基本约定是用户与开发人员团结合作, 共同创建出有实际运用价值的软件。用户积极参加整个开发项目的周期, 并指导开发小组如何提升整个极限编程项目生命周期的业务价值。

2.2 自适应软件开发

自适应软件开发与水晶方法实相互借鉴和融合的, 自适应软件开发借鉴的是复杂自适应系统理论, 其目的是通过提高自身的适应性, 以适应互联网时代下的软件需求难于预测并高速变化的软件开发。因为在不可预测的环境中, 开发人员需要用各种方法来应对不可预测性。在对于开发人员的管理中, 需要管理的重点是鼓励开发人员真诚合作、互相沟通, 而不是生硬指使大家应该做什么, 这样才能让开发人员能够有足够的空间提出各具特色的具有创造性的解决方案。

2.3 SCRUM

发挥构件技术和面向对象的开发方法是SCRUM的宗旨和出发点。它是一种迭代的增量化过程, 吸取了各种开发的优势并加以改进, 更加有利于工作的管理和产品的进一步研发。SCRUM把项目分成多个迭代阶段, 每个迭代阶段为期半个月至一个月。在完成每个阶段之前, 开发人员需要明确这一个阶段需要实现的功能。但在每一个阶段, 所有的开发都围绕着迭代, 并且有固定的需求[4]。

3 优势分析

敏捷开发对于信息系统开发周期的有着严格的要求, 这一点与迭代式开发有着共同之处。不同的是, 由于迭代周期过长, 在迭代期间客户是无法改变变化需求的, 这就大大降低了项目估算的准确度;而敏捷开发模式却避免了这一不足之处, 它具有周期时间短和高度协作的优势, 能满足客户需要不断变化的需求, 这样就使得客户的需求更加具有可控性, 而及时有效的沟通和交流大大提高了开发软件的效率。

瀑布式开发体现的是预见性的原则, 对开发过程中的先后顺序有着严格的规定, 这就难以实现开发过程中的灵活性与自由度;而因具有独特的迭代方式, 敏捷开发模式信息系统中的已开发的部分模块一直处于可甩状态, 整个系统已经划分为一些相互独立的子系统, 迭代是以最短的周期进行, 效率和客户满意度得以大大增加。

与前几种模式不同, 快速原型模型与瀑布模型的有机结合, 使螺旋式的开发模式对开发过程中的风险评估十分注重, 与一些较大型的信息系统相比, 螺旋式的开发模式更加适合复杂度较高的系统。它所强调的是可预见的风险, 却难以应对不可预见的随机风险, 但敏捷开发的核心就在于更加重视在不可预知的风险面前系统所具备的适应性, 所以能够更好地避免风险。

摘要：传统的软件工程方法越来越难以适应飞速更新的软件需求, 于是便形成了一些较轻量级的软件开发方法 , 这就是被称为能迅速针对软件变化要求的敏捷开发方法。本文对敏捷开发方法的原理做出详细的分析和介绍, 同时又列举了几种较为常见的开发方法做出了实际应用的相关比较, 以帮助我们在今后的软件开发过程中使用恰当的敏捷型开发方法。

关键词：方法,原理,应用,需求

参考文献

[1]Kiczales G, et a1.Aspect—oriented programming.European Conf.on Object Oriented Programming.Finland.Springer—Verlag LNCS1241.June1997.

[2]林海, 徐晓飞, 潘金贵.计算机科学[J].2005 (2) :125-128, 132.

[3]聂华北, 沈剑翘.计算机系统应用[J].2008 (12) :157-161.

关于敏捷开发的一点小想法篇5

个人不太感冒，或者说持观望态度吧，原因如下：

1、首先概念是国外提出来的，是英文的，翻译成中文往往就会有质的区别，中国人喜欢歪曲外国人的概念，也可能是翻译的问题吧

2、敏捷开发对个人素质的要求是很高的，国外的软件人员要比国内的专业很多

3、对环境的要求也很高，国内环境还不成熟，有待提高

不过个人认为，还是可以在一定程度上使用敏捷开发，但不是一味的追求概念上的一致和做法上的一致如果只是追求形式上的敏捷，有可能造成类似大跃进的闹剧来。

#2楼-05-21 00:26Mien

“概念是国外提出来的”我们就不学？

“国外的软件人员要比国内的专业很多”真的？

“对环境的要求也很高，国内环境还不成熟”不能苟同。

呵呵，凡事积极并力求客观对待－－个人意见，不必参考。

#4楼 [楼主]2008-05-21 09:05virus

@Mien

谢谢

1、概念是国外提出来的，我们要选择的学，不是一概而论的学习，而且要修正很多的东西，比如说方式或者思路什么的，要是照抄不就是拿来主义了吗

2、不得不承认，国外的软件人员普遍要比国内的专业，这个你可以问一些有国外工作经历的

3、是啊，所以我没有苛求环境，我说的就是要根据国内环境变通地学习敏捷开发

#5楼2008-05-21 09:08程序小斯 [未注册用户]

楼主大概还不了解每捷开发的真正内涵吧

敏捷，是一种理念，并不是一种形式

#6楼2008-05-21 09:24小寒

敏捷开发重要的是理解其内涵，具体的表现形式可以依据具体的情况来定

要推行敏捷开发的思想，

首先要让其成员接受敏捷开发的思想，接受这种理念

然后再一步一步地进行从过程开发到敏捷开发的演变

#7楼2008-05-21 09:58坏人

理解好敏捷的思想后，你将不会要求自己把敏捷的手段全部用上，

敏捷代表着灵活与不拘泥。

倘若你只单单去执行敏捷方法论，可能真的会弄巧成拙。

#12楼2008-05-21 10:56球球

敏捷不算是什么新的东西，七年前就开始了，不用太担心。

怕英文变成中文有问题，那就看原版书吧。

国外的普通的软件人员也不一定就比国内强，只不过顶尖的软件人员比国内强，而且人数相对多，敏捷现在最大的问题不是程序员的技术问题，而是有没有客户肯和你玩敏捷的问题。

环境是大家创造的，有条件的话在自己的一亩三分地先在小工程上试验试验好不好用总是应该的，我还是比较看好敏捷的。

#14楼2008-05-21 12:46金色海洋（jyk）

关键看客户是否配合，好像敏捷是根据工作时间来付钱的，现在国内的客户都不会这么认为吧。客户不愿意付钱，那还怎么玩呀？

敏捷对程序员的要求会更高。

#15楼2008-05-21 13:35炭炭

谁说只有素质高，环境好才能用敏捷？

敏捷恰恰是解决你素质不高，环境不好的问题的。

只能说你的客户好糊弄，你对优秀设计追求不高，所以你看不出敏捷的优势

#16楼2008-05-21 13:56路人丙

其实说到底是人的问题，敏捷对程序员跟客户都要求“专业”...

#17楼2008-05-21 16:03坏人

说敏捷要专业要钱要什么什么的，感觉对敏捷的理解只停留在方式方法上。

敏捷开发不仅仅是一个方法论，更是一种思想论。

#20楼2008-05-21 16:05紫色阴影

1. 有多少是国内提出来的？

2. 我们公司很多是应届毕业生，没有开发经验，学了一段时间也很熟练我也是敏捷新人呵呵

3. 什么环境？

敏捷开发篇6

关键词：应用；开发方法；软件维护；敏捷软件

中图分类号：TP311.52

通常，软件维护有几种不同的目的：一是修改软件中存在的各种不足；二是提升软件本身的各种性能；三是提高软件的各种属性；四是让软件适应当前的应用环境。敏捷软件是当前软件维护中最新兴的一款软件，它主要有以下两种开发方法：一是权限编程的方法；二是自适应的开发方法。本文将谈谈敏捷软件拥有的开发方法该如何用于软件维护中。

1 敏捷软件拥有的几种开发方法

敏捷软件中运用最频繁的开发方法：一是权限编程的方法；二是自适应的开发方法。权限编程这种方法遵循着4条基本的开发准则。第一条准则是沟通。第二条准则是简洁。第三条准则是反馈。第四条准则是胆识。自适应的开发方法对收益递增经济给出了合理的解释。这种方法认为：由于经济变化频繁，市场形势难以预料，使得开发过程难以计划和控制，把自适应理论用到开发过程中后，自适应开发将适应迅速变化的市场形势，从而让开发过程变得可控。

2 软件的维护性开发

维护性开发一般来说有4种常用的方法。第一种是适应性维护。硬件设备推陈出新，为了适应新的硬件环境，软件环境的编译系统、操作系统也必须要更新。这种出于更新目的而做的程序修改工作便称之为适应性维护。第二种是纠错性维护。尽管软件在实际完成开发后，开发人员都要先做一次测试处理，但这次测试通常不能把所有错误都检测出来。所以，用户在实际使用中仍然会发现一些错误，并把这些错误告知开发人员，这种情况下，开发人员所做的改善工作就称之为纠错性维护。第三种是预防性维护。为了保障软件在将来能被正常维护，开发人员需要提前做一些维护工作，这些维护工作就称之为预防性维护。第四种是完善性维护。用户使用后可能因为需求的转变向开发人员提出添加功能的请求，这种情况下，开发人员根据用户要求添加相应功能的维护工作就称之为完善性维护。

3 敏捷软件开发方法在软件维护中的应用

3.1 开发背景

维护性开发和新软件的开发有明显的不同，其思路、方法、步骤都有较大的差别，维护性开发本身就受到软件原型的限制，这压缩了开发的范围和空间，但是软件原型也为我们提供了一个很好的模型，在开发时可以根据原型制定出专门的开发方法，在开发时能够很好的利用原型开发界面，并在原开发界面上进行调整，这需要开发部门和其他部门进行充分的沟通，在确保现生产系统能够正常运行的同时又要结合具体的需求进行相应的功能增加或调整。

3.2 开发过程

开发过程分为三个部分。第一部分是名词的解释[1]。第一个名词是行业标准。行业标准的含义是：软件开发中，开发人员必须依据的开发准则。第二个名词是编码规范。编码规范的含义是：开发人员必须依据一定的协议来开发，让代码符合开发的标准。第三个名词是开发人员。开发人员是指：软件开发时负责前期设计、中期开发及后期测试的人员。第四个名词是需求人员。需求人员简而言之就是指用户。第二部分是项目的开发。这个过程是指：软件开发公司在接到某个用户的开发任务后，把公司的开发人员召集起来，组成一个开发小组，并推选出一个小组组长，在小组组长的带领下，每个开发人员各抒己见，讨论前期的设计方案，接着各个开发人员便投入到中期的实际开发中，等到开发结束后，开发人员再对软件做后期的测试工作，最终把产品交给客户。第三部分是文档的开发。这个过程较为简单，它是指开发人员必须给需求分析、系统设计配上必要的文字说明。

3.3 开发实例

2014年6月某公司要求对该公司的运用管理平台进行维护性开发，在开发中运用到了敏捷开发方法，该方法主要是XP极限编程方法。开发组对该公司的管理平台的现有功能进行了详细的分析，并對业务管理的流程进行了仔细的讨论，总结出了几点需要修改的内容，在此基础上对新的业务内容进行补充、定义和开发。

3.3.1 运营管理一期的流程

通过对原有的运营管理系统进行分析，该系统的整体运行模式采用的是单独业务流程定值，例如问题单的管理，其管理的业务主要有如下的几种状态：未提交状态、提交状态、审核中状态、待分配状态、已受理状态、请求关闭状态、关闭状态、未解决关闭状态、确认状态、已确认解决关闭状态。虽然该运营管理平台能够完成日常的问题解决工作，并且运行也较为稳定，但是有些业务流程需要进一步的优化和完善，针对这一期的运营管理平台的使用情况，并结合的该公司的新需求，经过开发组的讨论，得出了新任务的模型。

3.3.2 运营管理系统新业务流程

确认的新业务流程管理的业务状态如下：①开始，开始类型的任务，表示某一个任务开始；②结束，结束类型任务，表示某一个任务结束；③通用，任务的类型为通用性；④提交，提交问题类型的任务，通常是流程的第一个任务；⑤审核；⑥分配；⑦处理；⑧会签；⑨确认；⑩子流程。对于所有的任务，其中可能的任务的状态有以下几种：①非活动状态，表示该状态当前并没有被使用；②活动状态，该状态应用在特定的任务中；③挂起状态，该状态用以保护草稿；④结束状态，用以提交任务；⑤处理状态，该状态应用在引擎出提交问题进行处理后显示的状态；⑥过期状态。

3.3.3 运营管理系统维护性开发的过程

对于该运营管理平台的开发，开发小组对开发的过程进行了统一的规定：①精炼整个开发小组的成员，整个开发小组成员为8人，其中包含项目经理、需求人员、开发人员；②要求整个开发小组进行积极的交流和沟通，对当前面临的问题进行阐述，并共同解决，然后定期的开展项目周例会和需求讨论会，进一步的根据需求来完善软件的开发；③要求在开发中使用统一的开发工具和统一的开发环境，并遵循统一的开发规范；④在对需求进行讨论时，要求和公司的管理人员及时沟通，并提出改进的方案；⑤在系统开发时尽量多利用开发工具和UML图来对需求进行说明和设计，主要的功能由2人共同完成；⑥在整个项目开发过程中，系统的设计、编码、测试需要同时的进行，测试时不但需要测试新功能，同样也需要测试旧功能。在整个开发过程中，开发小组各成员严格按照开发规范和流程进行，并充分和公司人员保持沟通，最终取得了很好的效果。

4 结束语

综上，本文首先阐述了敏捷软件中运用最频繁的开发方法：一是权限编程的方法；二是自适应的开发方法。其次，本文阐述了软件开发中的维护性开发，尤其谈到了维护性开发中的几种常用方法：一是适应性维护；二是纠错性维护；三是预防性维护；四是完善性维护。再次，本文举了一个开发的实例来说明敏捷开发方法该如何在维护性开发中应用。

参考文献：

[1]于世文，王丹丽.敏捷软件开发方法在软件维护中的应用研究[J].计算机仿真技术，2012（15）：13-16.

[2]高宇，冯向忠.敏捷软件开发方法在软件维护中的应用研究[J].科学学研究，2013（10）：11-12.

[3]谢东强.敏捷软件开发方法在软件维护中的应用研究[J].计算机应用与软件，2014（13）：22-24.

作者简介：张桐（1980.01-），男，天津人，2003年毕业于天津理工学院计算机科学与技术专业，软件工程师，研究方向：计算机软件设计与开发。

浅谈敏捷软件开发篇7

自从软件工程产生以来, 我们在降低软件开发项目的风险过程中尝试过多种方法, 虽然面向对象、结构化、CMM等技术有利于帮助软件危机的解决, 然而其复杂的过程使软件行业陷入低效泥沼中。2001年Kent beck Martin Fowler Robert Martin等经验论阵营的头领发起了敏捷联盟向全世界发布了他们的宣言:个体和交互胜过过程和工具;工作软件高于理解文档;客户合作胜过合同谈判;响应变化胜过遵循计划。宣言体现了软件开发方法必须去适应软件变化的特征, 在宣言的基础上就提出了敏捷软件开发方法。

2 敏捷方法概述

截止现在敏捷软件开发方法还没有一个确定的定义。但它的特点是重视软件生产效率的, 适用于软件需求不确定、用户易沟通并且能参与开发、开发人员有责任感并且积极向上、十个人以下的小项目的开发, 是以保证软件开发有成功产出为前提的, 尽可能减少在开发过程中制成品的方法, 体现“刚刚够” (Just enough) 的观点。

人作为核心、循序渐进和迭代算法是敏捷软件开发的宗旨。在敏捷软件开发过程中, 软件项目被分解成很多个小项目, 每个小项目的成果都经过测试, 再把他们集成起来。它的灵活性、协作性和软件的商业价值上作出的贡献是敏捷软件开发方法的优势。这都在“敏捷宣言”的核心原则中得到了体现:交互和独立工作是建立在工具和过程基础上的、软件使用是建立在文档基础上的、客户的协作是建立在合同谈判基础上的、对变更做出的响应是建立在遵循计划基础上的。

3 几种常用的敏捷方法比较

3.1 极限编程 (XP)

极限编程 (简称XP) 是由Kent Beck于1996年提出的, 极限编程要求把它列出的每一个思想和方法都做到极限、做到最好。

极限编程的核心价值是我们在开发中必须注意的:Communication (沟通) 、Simplicity (简单) 、Feedback (反馈) 、Courage (勇气) 、此外还有第五个价值:Modesty (谦虚) 。因为计划赶不上变化, 使用极限编程的软件开发人员只需要在开发的初期做出一些文档。极限编程把软件测试放在首位, 这样以后出现漏洞的几率就会降到最低。

极限编程是一种近螺旋式的开发方法, 它把复杂的开发分解为相对比较简单的小软件;通过沟通、反馈和其它的方法, 客户和开发人员就可以清楚的了解到开发进度、变化、困难和急需解决的问题等, 并及时地调整开发过程。

3.2 SCRUM

SCRUM的宗旨是发挥构件技术和面向对象的开发方法, 对迭代式面向对象方法进行改进, 适用于需求不确定的产品的开发。是迭代的增量化过程, 便于工作管理和产品研发。更综合了各种开发的经验。

SCRUM把项目分成N个为期15-30天的迭代阶段, 称之为“冲刺” (sprint) 。每个“冲刺”之前, 你明确这一个“冲刺”需要实现的功能, 然后让开发人员去完成。但是, 在“冲刺”时, SCRUM的核心是所有开发都围绕着迭代, 需求是固定的。SCRUM方法中只有3中角色:SCRUM主管、开发团队、产品负责人。

3.3 动态系统开发方法 (DSDM)

开发一种面向领域的快速开发方法是产生动态系统开发方法的原因, 动态系统开发方法在技术支持、应用推广、研究改进培训认证和培训认证等方面都比其他方法要完善, 适用于对时间要求很紧的开发项目, 动态系统开发方法应用范围不再仅仅局限于IT行业。

DSDM方法提倡以业务为核心, 快速而有效地进行系统开发, 并提出了探索式开发方法的概念。强调软件使用者一开始就预见所有需求是不可能的。该方法中, 只要进能入下一步, 当前的算法就是可行的。

3.4 水晶方法 (Crystal)

水晶方法是Alistair Cockburn于上世纪90年代末提出的, 水晶方法目的是发展一种提倡“机动性的”方法。

Crystal是根据项目重要性和规模来区别项目的, 并给出相应的办法。所以, crystal是多种方法的组合.它阐明了要把对话和交流放在第一位的观点。Crystal方法中有两条准则: (1) 应用反思工作室促使方法学的自适应, (2) 使用的增量式循环不超过4个月。

3.5 特性驱动开发 (FDD)

特性驱动开发是一个强调快速迭代、特性驱动的软件开发方法, 适用于周期短的开发。它既能保证文档和质量, 又能保证软件的快速开发, 并提出划分的每一个功能开发时间不超过两星期, 要求两星期内生产出可见的、能运行的代码。

特性驱动开发方法认为简单的过程和良好的定义就能很好地被执行, 它强调的是实用、简化、易于被开发人员接受, 是一个特性驱动快速迭代的过程, 适用的项目为软件需求经常变动。

3.6 自适应软件开发 (ASD)

自适应软件开发方法的理论来源是复杂自适应系统理论, 目的是通过提高自适应性用来应对互联网时代下的软件需求难于预测并高速变化的软件开发, 它与水晶方法正在相互借鉴和融合。

在一个环境中, 结果是不可预测的, 把计划看成是一个自相矛盾的。在计划中, 偏离计划就是错误的, 要纠正。而在一个适配性环境里, 偏离计划恰恰是在引导开发人员走向正确的目标。在不可预测的环境中, 需要我们用各式各样的方法来应对不确定性。在管理中, 重点在于鼓励大家交流沟通, 而不是告诉大家需要做什么, 从而使开发人员能自己提出具有创造性的解决方案。

4 结语

不同的开发方法对于不同的开发人员来说, 意义是不同。不同的项目规模, 不同的开发环境, 也决定了开发团队采用哪种开发方法, 本文仅仅对敏捷开发方法做了一个简单介绍, 相信能为开发团队在实践中选择方法提供一个比较客观的参考。

参考文献

[1]杨帆, 徐俊刚.一种改进的Scrum敏捷软件开发方法[J].电子技术, 2011.

敏捷开发中相关技术的应用篇8

现代企业中,流程时时刻刻在发生着变化。传统的内部管理系统的结构固定,维护和二次开发的成本都居高不下,难以适应企业快速发展的需要。因此,更快地适应业务流程的变化,成为敏捷开发被需要的理由。

1 敏捷开发

1.1 敏捷开发的特点

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法[1]。

在敏捷开发过程中,整个软件项目被切分成多个子项目,各个项目经测试后分别运行,逐项完成。因此,在此过程中软件一直处于可使用状态。

与传统开发方法相比,敏捷开发具备了以下技术特点和优势:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。

敏捷开发技术特别适用于:人数较少的项目团队;经常发生变更的项目;实施风险较高的项目;开发人员可以参与决策的项目。

2 敏捷型管理系统开发中的技术及应用

更快、更小、更敏捷是现代企业管理系统开发的新方向和新思路。从本质上讲,敏捷开发是一种思维方式和软件过程方法论,但这种方法是建立在相应技术上的。Spring、Struts和Hibernate等相关技术则为这一目标提供了可行性。

2.1 Spring,更好地并行开发

在一个开发团队中,如何使得成员之间能够相对独立地进行模块开发,是对整个开发流程并行进行的很大考验。在传统技术中,系统各个模块间的耦合度高,互相依赖情况严重,这使得各个模块间的并行开发遇到很大的阻碍[2]。如何摆脱这样紧耦合呢?幸运的是,Spring给了我们答案。

Spring是一个开源框架,是由Rod Johnson创建,为简化企业级应用应运而生的。Spring具有许多功能,可以归纳为几个核心部件,其中最为重要的特性是依赖注入DI(Dependency Injection)和面向方面编程AOP(Aspect-Oriented Programming)[3]:

(1)依赖注入(DI)依赖注入是Spring提供的一种松耦合的技术。

(2)面向方面(AOP)被定义为一种编程技术,用来在软件系统中提升业务的分离[4]。

2.2 Hibernate,摆脱JDBC的冗长和复杂

数据库是任何管理系统所必备的。在传统的开发过程中,JDBC通常作为连接应用程序和数据库的桥梁。然而,JDBC冗长和复杂的异常处理,事务控制代码经常使得程序员不得不面临许多业务逻辑外的调试。程序员不但要对数据库中的表结构了如指掌,更要亲自操心每一行业务逻辑代码到数据库语言的转换。Hibernate就是基于框架去处理这些样板代码,而不是每次都手工地重复它们。

Hibernate是一种Java语言下的对象关系映射解决方案。它为面向对象的领域模型到传统的关系型数据库的映射,提供了一个使用方便的框架。当我们的需求不仅仅是取出数据库的字段,而是包含以下的复杂功能时,Hibernate是目前应用最为广泛的解决方案之一:

(1)延迟加载延迟加载让我们只在需要的时候加载全部关系数据。

(2)期望获取利用这一特性在需要一个查询里获得整个对象图表的关系,只用一个操作就可以获取全部数据,从而避免了反复进行数据库连接和断开的通信开销。

(3)级联有时候对一个数据库表的修改会导致其他表也发生变化。Hibernate使得以级联方式操作几个相关的表关系变得简单而富有效率。Hibernate的对象关系映射ORM(ObjectRelational Mapping)机制甚至使得程序员无需对于数据库十分精通便能够轻松地操控数据库中的记录。

2.3 Struts2,MVC概念上的提升

Struts2 不是一个Struts的新的发布版本,而是一个全新的框架。Struts2是第二代基于MVC模型的Web应用框架,是Java企业级Web应用的可扩展性的框架。它是Web Work和Struts社区合并后的产物。Struts2接近于原先版本Struts,并且会更容易使用[6]。

Struts2 相比Struts1.x在易用性上有很大的提升[5]。从开发者角度看,Struts2中需要显示给用户的数据可以直接从Action中获取,而不像Struts1.x那样,必须把相应的Bean存到Page、Request或者Session中才能获取[7]。另外,在线程模式上,Struts1.x Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。而Struts2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。

3 敏捷型管理系统技术开发应用实例

下面以一个运用敏捷技术开发的人力资源管理系统为例,列举了Spring、Hibernate、AOP等敏捷开发相关技术在具体开发中的运用与实现。系统的总体设计目标是构建一个企业人力资源管理系统,系统由以下核心模块构成:

(1)基本资料管理提供员工基本资料的CRUD功能(C Create写入,R Read读取,U Update更新,D Delete删除)。

(2)知识技能管理提供员工基本知识技能的CRUD功能,并提供多维度查询接口给manager角色,方便经理查询具有特殊技能员工的信息。

(3)职位升迁及绩效评定管理提供从员工入职到离职的全部记录,以及绩效评定功能,方便企业对于员工进行年度考核、升迁管理等。

系统整体架构图如图1所示。

下面介绍在系统开发过程中主要使用的核心技术。

3.1 基于Spring的面向方面的组件交互

(1)面向方面的日志服务

日志服务在整个系统中属于一个典型的交叉业务。当系统中的核心业务触发时,日志业务被依赖注入到每个业务中,从而在每个方法的开始、结束以及异常发生时都自动装载日志发生器,将行为记录在日志系统中。

将日志通知以Aspect J切点方式注入到核心业务代码的XML配置:

</bean>

注:Aspect J切点语言是一种真正的切点表达语言。

(2)面向方面的事务服务

原子性(Atomic),一致性(Consistent),隔离型(Isolated),持久性(Durable)是事务中最重要的四个特性[6]。

Spring使用了一种回调机制,将真正的事务实现从业务代码中抽取出来。事实上Spring采取仍然是AOP方式的事务实现,将事务定义为一个切面并注入到核心代码之中。

定义Hibernate的事务管理器:

3.2 Hibernate的DAO设计模式的运用

DAO(Data Access Object)模式实际上是两个模式的组合[7],如图2所示,即Data Accessor模式和Active Domain Object模式,其中Data Accessor模式实现了数据访问和业务逻辑的分离,而Active Domain Object模式实现了业务数据的对象化封装。

本系统的底层数据调用层正是使用了DAO模式。以下是在本系统中的员工对象Employee的Java和Hibernate映射结构:

对象映射文件:Employee.hbm.xml

在本系统中,服务对象通过接口访问DAO类。DAO类代表“数据访问”对象,他的作用在于提供一种手段来读取和写入数据库,并通过接口方式来提供这种服务,让程序的其他部分能够访问他们。在系统具体实现中,业务逻辑核心代码位于Service相关类中,在Service类中通过接口声明,并在启动时候由Spring自动将数据库访问类DAO注入到Service类中。DAO数据库接口类则是由Spring向其注入由Local Session Factory Bean辅助类提供的session Factory,实现由Hibernate控制的数据库访问ORM结构。

3.3 Struts2中的Action运用

不同于Struts1.x中Action Form处理表单,Action处理业务的分工方式,Struts2将这两者的功能非常简便地合成在了一起,成为Struts2中的新Action。基于CRUD设计模式的设计,使得Action的每个方法都能够高度地被复用。图3显示了几个核心Action模块的架构。其中主要包括:Employee Action:员工管理;PEAction:绩效管理(Performance Evaluation);Payment Action:薪酬管理;Skill Action:知识技能管理;Job Action:职位管理等。

Employee Action类中的具体方法举例:

Employee Action在Struts2框架中的配置文件:

<result name="success">/Employee/edit.jsp</result></action>

由此可见,Struts2在配置和代码机构上比Struts1.x要灵活和方便的多。

4 总结与展望

敏捷开发强调市场和需求驱动,拥抱变化。每一个新的功能和修改的功能,都可以影响到其他功能,造成副作用,所以,需要自动化去支持变化,在变化的同时保证质量和开发速度。本例在Spring的开源框架、Hibernate的ORM机制和Struts2第二代基于MVC模型的Web应用框架的结合应用,在人力资源管理多变的环境下,是一个很好的案例。

敏捷开发作为一个新的Java技术热点,今后的应用必将更加广泛。在Struts2等框架渐渐向敏捷迈进的今天,我们应该多去思考如何将这些新技术更好地整合到现有的技术和框架中,从而重整冗长的传统开发流程,让我们的管理系统更轻、更小、更符合需求变化。

摘要：更快,更小,更敏捷是现代企业管理系统开发的新方向和新思路。Spring、Struts和Hibernate等相关技术则为这一目标提供了可行性。Spring提供了依赖注入和面向方面编程的利器,配合Struts的新一代框架Struts2,以及Hibernate在ORM上的优势,使得构建一个敏捷的、快速适应需求的管理系统变得更轻松。以Spring及面向方面编程技术为基础,研究如何将Spring、Struts、Hiber-nate等技术更好地结合,从而改进传统开发流程,实现企业内部管理系统的敏捷开发。

关键词：Spring,面向方面,依赖注入,Struts2,Hibernate

参考文献

[1]Agile software development.http://en.wikipedia.org/wiki/Agile_software_development.

[2]敏捷开发技术的优势.http://blog.csdn.net/netHibernate/archive/2007/09/07/1776488.aspx.

[3]Craig Walls,Ryan Breidenbach.Spring in Action.Manning Publica-tions,2008:76-126.

[4]James Shore,Shane Warden.The Art of Agile Development.O'ReillyMedia,Inc,2009.

[5]http://zh.wikipedia.org/wiki/Struts2.

[6]Christian Bauer,Gavin King.Java Persistence with Hibernate.TuringPublications,2008:320-349.

敏捷开发篇9

计算机游戏可以说是与计算机同步发展的最流行的软件。谈到游戏软件，大多数人都认为其神妙莫测，高不可及。而一般游戏软件也确实具有很高的技术难度，随着开发工具及软件开发方法学的不断发展，动手开发游戏也不是十分困难的。五子棋是一种古老而又有趣的游戏，五子棋游戏软件不计其数，并且不断推陈出新。网上就有好多关于实现的复杂算法和设计，其难度让一般初学者望而却步，本文旨在提出一种简单而不愚蠢的敏捷软件开发方法。

敏捷软件开发是一种相对传统软件开发方法而言的轻型方法。认为只要能适应软件需求变化的开发方法都是敏捷的。解决需求变化之路强调以人为本，强调个人能力及素质重于过程，强调能够工作的代码胜过面面俱到的文档。以下是以Delphi为开发工具的一个开发过程。

2 需求获取及系统设计

敏捷开发不再像传统过程把开发过程分成明显的阶段，在开始时，进行简单设计。在需求获取上，不是从细节上过分细致地讨论，而是稍微粒度大些，抽象出关键的、主要的类，简单设计的意思是不做过分设计复杂的算法，尽快做出能工作的软件或原型，在后面需求变化中不断调整目标。根据软件开发的一般步骤，进行需求分析，开始时不可能一步得到最终详尽的软件需求规格说明，只能对需求进行粗略描述：给出五子棋盘，供两个玩家对弈，可以人人对弈，也可人机对弈。从此可以看出，应设置两个类：棋类和玩家类。棋类提供棋盘，接受棋子，供玩家读棋盘状态。考虑到棋手只是一个参与者，只要会给出位置就以了，不必设置类只需增设一全局变量player表示当前棋手是黑或白即可。因此可写出棋类说明如下：

通过编写测试用例容易验证其正确性。

3 界面设计

界面设计与实现相分离，都以接口为中心，面向接口设计。具体的实现依赖抽象的接口，在开发的过程中，算法可能不断改进，可以在基类的基础上进行派生，利于实现封闭-开放性原则。根据类设计的相关原则，下棋、棋盘显示等都不应由棋类负责，其它的功能先由表单实现。根据单一职责原则适当的时刻分离出新的类来。新建表单form1,在其内添加一image对象，设置其picture属性为一棋盘BMP文件。当鼠标按下时，通过对位置的转换向棋类发出行列信息，即可实现下棋。

以上代码已能实现两人在计算机前下棋，但需要人工判赢。

4 不断响应需求变化进行增量迭代

如果要让计算机自动判赢，根据单一职责原则，增设一计算机类，让其判断在一条线上的某类棋子的数目，在棋盘中，有四个方向，在一条直线可能是由一点向两个相反方向的射线组成，根据抽象原则，应设置从某点向八个方向中的某个方向试探的方法。

在判赢时只要函数four(player,x,y)为真即为赢。到此想到，让计算机下棋就是让计算机找合适的、有利的位置，首先能守。当对手的棋子四个一线时，上述函数可以完成此功能。同样，对手的三个棋子相连也是需要防守的，以及两线交叉的致胜点等，因此计算机类增加以下方法：

在procedure TForm1.Image1MouseDown中的form1.drawxy(y DIV 35+1,x DIV 35+1);之后加上computer.select(player)就可实现人机对弈了。此时计算机具有一定的防守和攻击能力。

5 重构让代码清洁，以利于响应变化

代码是最重要文档，为了让代码利于交流、传播，必须不断对代码重构。根据重构的原则，在代码重复时，就要考虑重构，在一个方法中，如果语句行数起过30行，就要考虑重构，来保障代码的清晰易读。发现在computer类中有许多重复的语句，分别对它们进行重构。特别是对select重构时，发现一缺陷，只凭优先级找到的点，太简单，不能实现既对自己有利又堵了对方，另外，每一方法都是进行一遍扫描，即多次双重循环，就考虑用一个双重循环，经过分析设计得出按优先级加权求和的方法，并修改four等返回类型为整数类型。通过重构，代码更简洁清晰，并且以后很容易响应规则的变化，以利于软件的深度开发。以下是计算机类的一部分代码：

通过重构，此程序具有了较高的攻守能力，能达到中级棋手水平。容易增加模块实现网上两个选手的对弈，以及丰富其他功能。

6 总结

敏捷软件开发强调简单设计，不是设计复杂的扩展接口，而是重视代码的质量，及时重构，利于增加功能。代码即为设计，实行结对编程，利于交流和知识的传播。进行敏捷开发不仅是开发的性走之路，也是个人技术、素质提高的最好方式。

摘要：敏捷软件开发是一种相对传统软件开发方法而言的轻型方法,强调以人为本,尽可能少的约束开人员,利于发挥开发人员的的创造性,也是提高软件质量的根本。开发人员必须遵循敏捷开发实践,提高自身水平,游戏软件的开发是进行实践的好方式,本文以五子棋游戏开发为例,给出敏捷开发的一些关键实践,需求的敏捷获取、代码的重构及测试驱动等响应需求变化的敏捷开发方法。

关键词：游戏,敏捷开发,增量迭代,重构

参考文献

[1]Martin R C.敏捷软件开发[M].邓辉,译.北京:清华大学出版社,2003.

[2]Ken Auer Roy Miller.应用极限编程[M].唐东铭,译.北京:人民邮电出版社,2003.

敏捷开发篇10

敏捷开发方法是一种与传统的“瀑布式”模型和CMM截然相反的开发方法。这一开发方法注重开发团队成员之间关系而不是已开发的进程使用的工具为重点, 注重开发的软件产品而不是追求广泛的文档编制, 注重开发过程中与客户的协同工作而不以签订合同的谈判为工作重心, 注重在开发过程中随时调整计划而不同意完全遵循某一开发计划, 以实现所谓开发过程的敏捷[2,3]。

1 敏捷开发概述

敏捷开发是一种以人为核心, 迭代、循序渐进的开发方法。是为了解决项目的复杂性, 以最快的方式实现需求的开发方法。在敏捷开发中, 软件项目的构建被切分成多个子项目和多个子阶段, 各个子项目和各个子阶段的成果都经过测试, 具备集成和可运行的特征, 而各个子阶段是在上一个子阶段经过测试审查完成以后才开始下一个子阶段。

敏捷开发方法的应用是以小组为前提的。小组包含有两种角色:产品所有者 (Productor Owner) 和开发团队, 产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的目标, 告知对于软件系统预期的功能以及展现形式, 确定功能的优先级以便开发团队总是在完成最有价值的工作, 回答开发团队提出的疑问等。开发团队里的人员包括了系统架构师、需求分析师、软件工程师、测试人员以及文档编写者。敏捷开发小组需要定期开讨论会就不合需求之处讨论实施方案。

2 敏捷开发系统实例分析

2.1 项目背景及需求分析

2014年8月, 笔者为某公司开发技术支持信息平台, 以提高该公司运作效率, 节约成本。前期需求分析用了比较长的时间。首先开发团队进驻该公司, 向各个部门管理人员和工作人员深入了解各个岗位的具体工作内容并做了详细记录;其次从该公司人事部门获取了组织机构图及各个岗位的人员安排, 并将软件架构设计及数据结构设计讨论形成完整的方案, 形成了前期需求文档。依照该方案约定, 设计了系统框架, 再次跟客户讨论, 对不合理之处进行了调整。接下来进行功能需求调研, 调研之后发现该公司存在如下问题。

1) 由于该公司业务特性, 大部分员工长期在项目服务机构工作, 甚至有部分海外项目, 短期内无法回本部, 当遇到政策或技术等问题时无法获取本行业相关实时资料, 从而造成了项目潜在风险。

2) 由上级公司以及国家相关部门发布的体系文件、规范标准、法律法规等文件公司必须及时获取并提供给公司全员以作为引导, 但线下资料共享困难, 以至于对国家及总公司的政策响应缓慢。

3) 由于驻外项目组成员工作随意性较大, 公司管理人员对驻外人员管理效率低下, 驻外人员是否在岗, 工作进展等实时情况反馈不及时。

4) 企业管理人员、项目经理、项目成员、各部门工作人员之间沟通、协作困难。

5) 项目员工之间缺乏经验交流。

2.2 系统技术架构

通过本文依托的系统需求, 结合系统目标进行分析, 提出以Microsoft.NET平台为系统架构基础。.NET Framework是一种新的计算平台, 它简化了高度分布式Internet环境中的应用程序开发。.NET Framework具有两个主要组件[4]:公共语言运行库和.NET Framework类库。公共语言运行库是.NET Framework的基础。可以将运行库看作执行是管理代码的代理, 它提供核心服务, 而且还强制实施严格的类型安全以及可确保安全性和可靠性的其他形式的代码准确性[5]。.NET Framework的另一个主要组件是类库, 是一个综合性的面向对象的可重用类型集合。建立在.NET Framework之上的ASP.NET提供了一个Web应用程序模型, 并且包含使生成ASP Web应用程序变得简单的控件集和结构。ASP.NET包含封装公共HTML用户界面元素的控件集, 这些控件在Web服务器上运行, 并以HTML的形式将数据推送至用户界面上。在服务器上, 这些控件公开一个面向对象的编程模式, 为Web开发人员提供了面向对象的编程的丰富性。该系统引入Developer Express控件集合替代ASP.NET控件集, 并结合Java Script脚本语言为用户提供了更好的使用体验以及更为强大的数据提取和处理功能。

为遵循敏捷开发原则, 系统使用Visual Studio2012内集成的Team Foundation Server服务平台, 使系统开发人员进行源代码共享、代码审阅和数据收集, 为更加准确的实现系统功能做好铺垫。

文中系统架构主要基于以Microsoft Visual Studio2012.Net集成开发环境为开发工具。采用面向对象语言C#与Developer Express无缝结合, 为系统通信和相关服务提供支持, 以SQL Server为底层数据支持。为了开发的便利和数据安全的考虑, 系统采用多重数据备份和加密工作。搭建系统的操作系统采用了Windows Server2008 R2虚拟机的形式使用Hyper-V虚拟化技术存放在Windows Server2012服务器系统中。硬件方面采用了双机热备技术, 以保障数据安全性。

2.3 系统功能模块

该系统开发进程遵循敏捷开发原则, 参照针对客户的中期需求调研情况和无纸化办公、解决实际存在的问题为目标, 对主要功能采取逐个突破原则。据此, 将系统功能模块进行了有效划分, 包括门户网站和技术支持平台两个主要板块。技术支持系统以用户管理、项目管理、机构管理、岗位管理、权限管理为核心的系统架构体系, 以及技术支持、公司业务、人员动态、交流论坛四个主要功能以及个人信息、通知通告、证书管理、周月报汇总、证书汇总, 员工信息汇总等辅助功能。

2.3.1 系统架构

系统架构是一步步搭建并走向成熟的, 从页面和代码的分离以及数据结构基础设计到三层架构, 再到现在的多层, 每一步的发展, 使得程序逻辑更加清晰, 代码可复用性更强, 可读性更高, 可维护性更好。用户体验方面, 初期添加新的以部门为顶层的树状组织机构只能由开发人员更改XML数据文件进行添加, 到现在由客户完全自主配置。

2.3.2 开发过程

企业信息系统的开发有其自身的特点。一旦系统架构确定下来, 剩下的工作就是在这个架构体系下, 不断做重复工作实现所有规划的系统功能。

第66页图1为一个敏捷开发小组针对一个功能块的完全开发流程, 前四个角色共同组成开发团队, 最后一个角色是产品所有者。在前期需求调研完成的情况下, 项目经理制定一个灵活的开发计划, 计划的时间不宜太长, 否则因为客户需求的不断变化, 执行起来就会非常困难。开发计划交由需求分析员进行详细设计, 需求分析员需要画出具体图形或者制作静态网页将具体功能设计出初始形状, 在提交由项目经理进行评审。如评审通过, 则向开发组分配任务, 开发组开始功能。当开发组开发完结后交由测试组进行代码整合并集成测试;如评审未通过, 需求分析员需要对详细设计方案进行调整或重新设计。测试组测试无误, 则交由客户代表进行业务层面测试;如测试组发现BUG, 则开发人员需修改代码, 消除BUG。客户代表如测试通过, 则此功能开发完成;如果客户有异议则将问题提交至系统测试组, 再做重新调整。

2.3.3 功能开发实例

该系统开发的第一个主要功能就是技术支持。技术支持是一个信息共享平台, 针对该公司上级单位制定的体系文件、国内外法律法规文件、行业内的成功经验以及公司内部开展的培训课件等体量庞大的文件系统, 建立在线共享平台。

客户代表向项目经理提出要包括9大目录板块 (包括体系文件、法律法规、规范标准、培训课件、事故案例、公司业务、办公文件、知识分享及学习园地) , 每个大目录需要其做到其公司系统管理员可以自行配置, 区分上传文件 (包括下载和查看) 、下载文件 (包括查看) 、查看文件3种不同权限。项目经理制定了1个月的开发计划, 交由需求分析员进行详细设计, 由于在架构设计阶段已经将权限分配体系基础搭建完成, 需求分析员在2天以内设计出了技术支持的功能界面。得到项目经理认可后交由开发组进行开发, 开发组花9天时间将功能原型开发完成。

交测试组进行集成测试, 测试组在向开发组提交并确认了两次代码BUG后交客户代表测试。

当测试组将交由客户代表进行体验层测试时, 客户代表确认了展现形式, 但向某一目录下上传了50个文件, 该目录打开变慢, 继续上传了100个文件后, 技术支持功能打开变得异常缓慢, 并将问题反馈至开发团队测试组。测试组在经过同样测试后得到类似结果并将问题反馈至开发组, 开发组在进行单步调试以后提出两个结论:第一个是文件显示控件在提取大量文件时默认读取了文件数据字段导致变慢;第二个是功能加载将对应数据表中所有数据全部提取以致速度变慢。并就此确定了解决方案, 更改WEB展示风格, 提升了加载速度。

在此交由客户代表测试后, 客户代表提出, 由于公司业务拓展, 需要将第六部分公司业务从技术支持提取出来形成独立功能模块, 每项业务下包含有历年项目, 需将项目按年分类并按从新到旧的顺序排列。针对客户需求, 开发组将项目数据与技术支持数据进行了组合查询, 并在导航树设立虚拟的年份结点, 从而将公司业务功能完成。

如此不断迭代循环, 经过大概两个月的修改以后最终获得了客户代表的认可, 技术支持系统的功能开发就此完成。

2.4 系统应用评价

通过该系统的实施不仅解决了企业资源无法实时共享的问题, 而且帮助管理者提高了管理、监控和决策水平, 缩短了解决问题的时间。同时, 由于系统本身的B/S架构特性, 使得该公司所有员工随时随地都可感受到系统带来的便利。

3 敏捷开发经验总结

3.1 快速适应需求的变化

敏捷开发方法能够尽可能容易和有效地适应变化。尽管大多数人都同意反馈很重要, 但是他们忽视了一个重要的问题, 就是反馈结果往往代表的就是变化。敏捷开发能够驾驭这种变化, 因为推动变化比企图阻止变化更加有效。实际工作中, 开发团队和客户对于软件开发方面往往站在不同的角度, 理解容易产生分歧, 只有不断地沟通才能达到预定目标。在该项目中, 客户不断向开发团队反馈使用中的种种体验方面的问题, 而开发团队则积极响应客户诉求, 同客户一起讨论有效的解决方案。

3.2 降低软件开发风险

来自需求的风险是软件开发项目必须直面的问题。敏捷开发方法同时也要求至少有一位系统实际用户实时与开发团队讨论需求, 回答开发团队的问题, 对开发完成的功能进行确认。这是解决软件开发中需求不确定的切实有效的办法。假如客户只认为给出开发团队模糊需求就撒手不管, 造成的结果极有可能是返工重做或大面积修改, 这也就为软件失败埋下伏笔。

3.3 形成明确的代码规范

敏捷开发对于编程规范的要求很高, 通过制定严格的代码规范来进行团队内部沟通。一个明确的代码规范不仅可以节约时间, 而且可以大幅提升代码的复用性, 同时还可以提升软件品质。软件开发人员的编程习惯不同, 是软件项目失败的重要原因, 彼此短时间读不懂对方代码, 就无从下手, 从而造成大量时间浪费。项目开发团队由项目技术负责人搭建系统架构, 指定代码规范, 经过短时间磨合, 所有成员形成默契, 开发效率不断提高。

参考文献

[1]柴益萍, 龚报钧.中国企业管理发展之路[J].信息管理系统, 1999 (2) :14-15.

[2]Robert C.Mahaney, Albert L.Lederer.Information system projects project management:anagency theory interpretation[J].The Journal of System and Software, 2003 (68) :1-9.

[3]Robert C.Martin.Aglic Software Development Principles, Patterns, and Practices[M].北京:中国电力出版社, 2003.

[4]东方人华.微软Visual Studio.NET程序员开发系列丛书C#编程技术[M].北京:清华大学出版社, 2001.

敏捷开发的软件测试过程概述篇11

1 软件测试的方法

1.1 根据透明度分类

透明度分类是将软件按照不同的透明度归类为黑盒测试和白盒测试。黑盒测试是把软件当作已经放入到一个黑盒子中的一个东西进行测试,测试时无需了解软件的实现过程,是以用户使用的角度进行的测试。白盒测试则是把软件当作放在一个打开的盒子里的东西进行测试,因为盒子是打开的,测试时会对软件的实现与构造一目了然,是深入到软件内部的一种测试。

1.2 根据开发过程分类

1.2.1 单元测试

单元测试属于白盒测试的一种,以盒子打开的形式对软件的代码单元进行测试,在函数式语言中以函数为单元测试。测试的方法是对单元进行编写代码,利用编写的代码进行测试。

1.2.2 集成测试

集成测试属于灰盒测试。灰盒测试是介于黑盒测试与白盒测试之间,测试时同黑盒测试一样,不需要考虑内部实现,也不用像白盒测试那样深入到软件结构中进行测试,只需要测试模块间的接口与配合的关系即可。

1.2.3 系统测试

系统测试属于黑盒测试,不需要了解软件的实现方法,但需要根据软件的规格需求进行测试。软件测试实际是由系统测试演化而来的,系统测试是开发中必要的测试环节,而大多数软件在开发过程中对单元测试和集成测试的要求很少。

1.2.4 验收测试

验收测试是用来验收软件是否能够达到用户的满意度,属于黑盒测试。上文提到的Alpha测试是内部测试,是用户在开发环境或者模拟测试环境下的测试;Beta测试是外部测试,是由软件的一个或多个用户在实际使用环境下进行的测试。两种测试方法均可在验收测试中使用。

1.3 针对性测试

针对性测试是针对软件的某一个或几个质量特性进行测试,比如软件的可靠性、易用性、可维护性等等,是将上文提到的几种测试方法相融合。测试中可能还需要对软件的安全性、性能、内存做针对性测试,测试不仅跨越各个开发阶段,同时也具有白盒和黑盒测试的特质。

1.4 安全性测试

安全性测试主要针对软件的使用安全性,随着互联网的发展,应用软件更容易受到威胁,软件的安全测试就显得尤为重要。可以通过语法、故障注入、模型安全及模糊测试的方法对软件的安全性进行测试。

1.5 性能测试

性能测试是为了验证软件是否能够达到用户提出的性能指标,同时发现存在的瓶颈,起到优化软件的目的。性能测试一般通过自动化的工具完成,如LoadRunner等。,软件性能的好坏往往是决定软件能否赢得用户的重要因素。

1.6 内存测试

内存测试是测试软件运行时的内存是否越界,对于泄漏、缺陷等问题进行检测,能够有效的检测出软件中存在的安全隐患。

2 敏捷开发的定义

敏捷开发(agile development)的概念是在2004年产生的,它是一种以人为本、循序渐进的软件开发方法。敏捷开发中,软件项目被划分为多个子项目,各个子项目的功能通过测试后便可运行。

敏捷开发主要是针对中小企业,这类企业的发展需要团队具有高效工作、满足需求和顺应变化的条件,因此提出了敏捷软件开发的理念。敏捷开发的方法很多,包括Crystal、自适应软件开发(Adaptive Software Develoment,ADS)、特征驱动软件开发及极限编程(Extreme Programming,XP)。

3 敏捷测试人员的定位

敏捷开发近年来受到社会各界的重点关注,原因是它能够应对客户多变的需求并不断进行相应调整开发的一种高效开发模式。敏捷开发中的测试人员也可以叫做QA (质量保证)人员。因此软件从开始设计时就需要与QA人员达成一致,双方的目标都是注重质量,构建软件形成,达到零缺陷的软件开发过程。QA人员需要站在客户的角度去思考,辅助开发人员完成设计和软件的实现,并对软件整体进行掌握,及时提出架构上的问题。QA人员还需要对客户反馈的信息进行统计,以便团队更好的改进问题。此外也需要与开发人员紧密合作,双方形成互补,避免敏捷测试对软件开发无用以及测试不完整的问题出现。

4 敏捷开发的软件测试过程概述

敏捷开发的测试方法不同于传统的测试,在敏捷开发测试中,测试决定整个项目组的去向,明确指出问题所在和改正方向,促使项目组在敏捷测试信息中做出正确的决定,测试人员根据检测出的错误,辅助开发人员进行修正。

4.1 初期测试工作重点

测试人员需要从软件开发初期便进行检测,对开发软件的测试重点是文档的完整性、严密性和功能设计的可测性。测试人员在软件开发初期,需要对软件做好需求分析,对设计做好逻辑分析,将每一环节中的检测结果积极、迅速的反馈给设计和开发人员。

4.2 测试用例设计及评审

敏捷开发的过程中,开发人员可以和客户直接沟通,确定每个功能的优先级。测试人员根据已经通过审核的设计方案编制测试计划,再设计相应的测试用例。测试的主要依据是软件产品设计文档,而这些设计文档也需要项目经理和开发人员一同对其进行审核。

4.3 测试执行

为了方便衡量软件当前的质量和判断测试是否达到出口标准,可以每天对测试结果进行分析,提供问题走势图,将每天新发现的缺陷问题和已被解决的问题的数量制成图表展示。在测试执行的开始阶段,缺陷问题数量会呈上升趋势,到中后期被解决的问题数量会上升,新发现的缺陷数量下降,最终发现的问题数量曲线趋于稳定并向零值趋近。

在发布软件版本之前,测试人员还需要根据发布的版本情况进行说明,对版本的说明应至少包括三方面的内容:已经修复的上个版本中存在的错误、新的功能、此版本还存在哪些问题。

4.4 需求管理

所采用的敏捷开发模式中,客户的需求变更较为频繁,因此对客户的需求进行管理是非常重要的工作。在软件开发过程中,不断的有新变化的需求,这就意味着软件测试的重点和方向需要根据新需求的变化而不断地调整。对于新变化的需求需要进行相应的记录,将每次的变更需求整理记录到文档中,文档始终保持在更新的状态,与客户的需求变化保持一致,方便后期的管理和维护。在敏捷测试中,这项工作由测试人员执行更为合理有效,一方面方便测试人员及时理解需求的变更内容,快速完成用例设计,执行测试;另一方面也能有效的起到质量保证的作用,检查开发人员开发出的产品是否符合变更后的要求。4.5清理Bug

在软件敏捷开发接近尾声时,可以进行一次整体的软件Bug问题大清理,这样做的好处是可以利用测试以外的多方力量,全方位、多角度的发现软件的遗留问题。可以在项目的时间进度安排里预留一个时间段完成这项工作,参与测试的人员需要集中的进行一次检测。需要注意以下几点:(1)参加检测的人员不仅需要包括测试人员,还需要有项目经理和开发人员甚至高层管理人员的加入,便于对发现问题的及时了解,并且集思广益快速解决问题。(2)鼓励各部门之间进行交叉测试,通过不同的思路和视角发现更多的错误。(3)还可以将软件检测进行专题分类,比如安全性检测、用户体验检测、国际化或本地化检测等等。

5 结论

综上所述,为了适应客户对软件产品的要求不断变化而出现了敏捷开发模式,相应地产生了敏捷测试的概念。在敏捷开发的测试过程中,核心关键是快速的响应、完成测试并反馈结果,并与开发同步及时展开测试。。敏捷开发测试不仅是一种高效的检测模式,还能够提高软件质量并且对软件进行预防错误处理。对于敏捷开发测试的发展,社会各界一直持有高度关注,相信通过科学技术的不断探索前进,能够更好的带动敏捷开发测试的应用及发展。

参考文献

[1]徐炳.基于CARD/1的高智能化互通立交设计系统的研究与开发[D].电子科技大学,2013.

[2]宋易欣.基于看板管理方法的敏捷软件开发研究[D].北京邮电大学,2013.

[3]胡丹.基于关键链的敏捷软件开发项目进度管理研究[D].浙江工业大学,201 3.

[4]谢业亮,昊群飞,戴勇.浅谈敏捷软件开发在电力系统信息化建设中的应用与发展[A].中国电机工程学会电力信息化专业委员会.电力行业信息化优秀论文集2013[C].中国电机工程学会电力信息化专业委员会,201 3(07).

【敏捷开发】推荐阅读：

敏捷开发模型09-03

敏捷思想05-26