码迷,mamicode.com
首页 > 其他好文 > 详细

敏捷开发与传统开发

时间:2016-10-16 01:17:23      阅读:227      评论:0      收藏:0      [点我收藏+]

标签:

 

本文主要介绍和讨论什么是敏捷开发和传统软件开发,分析这两个软件开发方法的特点并作出对比。首先介绍什么是传统软件开发。

 

传统开发

传统软件开发主要指的是传统软件开发的模型。传统的软件开发模型包括瀑布模型、增量过程模型、原型模型、螺旋模型等。这里就主要说这四个模型。

瀑布模型

 技术分享

瀑布模型可以说是狭义上的传统开发模型。1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。瀑布模型由软件开发经典的四个过程组成——分析、设计、编码、测试。(也有分为不同的过程的,有分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护这六个过程(如图所示),在Roger S.Pressman的《软件工程:实践者的研究方法》中又是分为沟通、策划、建模、构建、部署,都大同小异,这里就分为核心的这四个部分)瀑布模型就是从头至尾顺序执行这四个过程。因为整个过程如流水般从上至下流过而不往回走,如同瀑布一般,因此将其形象地取名为瀑布模型。瀑布模型是传统软件开发模型中最典型的,也是其他传统软件开发的模型的基础。在下面的介绍中会看到其他模型都局部使用或者循环、迭代地使用了瀑布模型。

增量过程模型

 技术分享

瀑布模型是在整个软件开发过程中,分析、设计、编码、测试顺序执行一遍。二增量过程模型则是将整个工程分为不同的小部分,每个小部分比上一个小部分都有一定的增量(即多完成了一定的工作,或多开发了一些功能),然后每个小部分中都执行瀑布模型。

原型模型

原型模型就是在需求分析之后,快速构建一个简单的、不完善的模型,对原型进行部署,接着由利益相关者对这个原型进行评价。根据利益相关者对原型给出的反馈信息进一步细化需求,再进行开发。快速构建的模型一般都是临时的系统,在接下来的开发中会被废弃。

螺旋模型 

技术分享

螺旋模型则是结合了原型模型的迭代性质和瀑布模型可控性的特点,把软件开发为一系列的演进版本,螺旋向上地开发出新的原型,并在每次演进的时候进行风险评估。螺旋模型可以说就是迭代地使用原型模型(如图中每一个圈就是一次原型模型开发的过程)。

 

敏捷开发

敏捷开发概述

很难去定义什么是敏捷开发。不同于上面提到的传统软件开发模型,敏捷开发并不是规定了一系列规则或过程的模型,实际上敏捷开发的“敏捷”性质使得了敏捷开发并不能这么做。敏捷开发应该说是软件开发中的一种方法,一种思想。虽然说很难描述敏捷开发是什么,但是从下面的“敏捷软件开发宣言”中,我们可以看出敏捷开发的一些特点

2001年,17位软件开发者发表了“敏捷软件开发宣言”,宣言中声明:

?    Individuals and interactions over processes and tools(个人和个人间的交互胜于开发过程和工具)

?    Working software over comprehensive documentation(可用的软件胜于详尽的文档)

?    Customer collaboration over contract negotiation(与客户的合作胜于合同和谈判)

?    Responding to change over following a plan(响应变更胜于遵循计划)

“敏捷软件开发宣言”也算是敏捷开发比较“官方”一点的定义了。从宣言中我们可以看出,敏捷开发更注重于开发中人的重要性,注重于更多人与人之间的合作交流,偏好于代码、开发出软件而不是花时间在文档,希望能够更好的适应于开发过程中的变化。个人认为,敏捷软件开发(Agile software development)的核心就是Agile(敏捷)。“敏捷”是由Agile这个词翻译过来的,个人觉得有一点点的误导性。“敏捷”这个词让人更觉得是快速的意思,虽然的确敏捷开发提倡快速地开发出可用软件,但我觉得Agile的核心意思更应该是“灵活”,在软件开发过程中需要更灵活。从上面提到的敏捷开发的特点可用看到,敏捷开发以人为本,人是灵活的;偏好于交流,而不偏好于写死的文档,交流中可以更灵活的分析软件工程的需求;适应变更,这个本来就是要求软件开发要灵活可变的意思。

下面要介绍的敏捷开发中最常见的两个开发方法,极限编程(eXtreme Programming)和Scrum,其实也很难去定义是什么,这两者之间也并没有什么一定的区别或某种联系(要说联系的话他们都有一定程度遵循敏捷开发提出的思想),人们在使用这两个开发方法的时候也是各有不同。下面介绍的时候也是介绍人们在利用这两个方法时,比较共性的、重要的内容,也让我们对敏捷开发有更直观一点的认识。

极限编程(XP)

XP包含了类似于瀑布模型中的四个过程:需求分析、设计、编码和测试。虽然说过程类似,但过程中所用的思想与方法却与传统开发有所不同。下面简要介绍这四个关键活动。

  • 需求分析——客户应该是项目开发队伍中的一员,而不是和开发人员分开的;因为从项目的计划到最后验收,客户一直起着很重要的作用。开发人员和客户一起,把各种需求变成一个个小的用户故事(UserStory),它们都被记录在一些故事卡(StoryCard)上,客户根据每个模块的商业价值来指定它们的优先级;开发人员要做的是确定每个需求模块的开发风险,风险高的(通常是因为缺乏类似的经验)需求模块将被优先研究、探索和开发;经过开发人员和客户分别从不同的角度评估每个模块后,它们被安排在不同的开发周期里,客户将得到一个尽可能准确的开发计划;客户为每个需求模块指定验收测试(功能测试)。
  • 设计——XP提倡对于简单的设计(SimpleDesign),就是用最简单的方式,使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。
  • 编码——XP就提倡结对编程(PairProgramming)。结对编程的好处是,一个人编写代码时另一个人在思考。如果编码者遇到障碍,他们就交换位置。如果两个人都遇到障碍,他们的讨论可能被在这个区域工作的其他人听到,可能给出帮助。
  • 测试——XP就提倡在开始写程序之前先写单元测试。一个人的单元测试组织到一个“通用测试集”,每天都可以进行系统的集成和确认测试。 

Scrum

技术分享

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。

 

特点分析与对比

瀑布模型的出现使得一开始无序混乱的软件开发变得有序、结构化,为软件开发提供了一套规整的、系统的开发路线,其一开始的确为软件开发带来了很大的好处。但瀑布模型这种单一、线性的模式,其缺点也很快显现出来:

  • 用户必须等到开发的后期才能看到产品,使得产品周期变得很长。
  • 测试与检验都在开发的后期,因此前期一些错误可能会积累到后期才被发现,开发风险大大增加。
  • 阶段固定,需求分析完后需求很难再更改。
  • 各阶段间产生大量文档,极大增加了工作量。

这些都是瀑布模型一些显而易见的缺点。针对其中一些瀑布模型不够灵活的缺点,对瀑布模型进行改进得到其他的传统开发模型。如增量模型、螺旋模型等。这些模型一定程度都改善了瀑布模型,降低了开发风险,增加了开发的灵活性。但在软件需求日益多变的今天,随着产品变更的变多,软件开发日程的增加,开发成本将指数增长。

在上面的介绍中,也讨论了敏捷开发的特点,从其特点可以看出,敏捷开发的方法可以很好地解决上面的问题。

  • 敏捷开发强调可用的产品,敏捷开发过程会尽快开发出可交付的产品,产品周期将会变短。
  • 敏捷开发中要求客户也作为开发团队一部分,强调开发者、客户之间更多的交流,因此能更好地对需求进行理解。
  • 交流的变多同时避免了许多不必要的文档。
  • 短的开发周期、多的交流以及追求简洁的开发原则使得整个开发过程非常便于适应变更。

这样看来敏捷开发似乎是如今软件开发的最佳选择。然而敏捷开发也有其缺点,其最显著的缺点包括以下几条:

  • 敏捷开发欢迎需求的改变,而过多的需求改变可能会扰乱整个软件开发过程。
  • 敏捷开发中需求很多情况是口头或其他非正规形式提出的,这也可能导致最后验收的时候需求与责任的不明确。
  • 敏捷开发缺乏正规的、整体的设计,这也可能导致项目开发完毕之后,系统的可维护性、可移植性等等性能的下降。
  • 过于“偏激”的理解敏捷开发,比如很少甚至不进行设计分析,为了缩短周期过快地进行编码并提交产品,可能会带来很多问题。
  • 敏捷开发里面不少情况有些过于理想化,比如要求人与人之间能很好的理解与沟通,要求人们之间能很好地相互信任、相互支持与鼓励,而在现实中人与人之间协作是很容易出现问题的。

以上等等都是敏捷开发的一些问题。因此我们可以看到敏捷开发也并不是一个万能的开发方法,传统的开发模式也有其适用的地方。在一些需求变化相对较小、规模相对较大、开发者与客户之间利益区分较明显的时候,传统开发还是有其优于敏捷开发的地方。

 

参考资料

1、《软件工程:实践者的研究方法(第七版)》Roger S.Pressman

2、维基百科:软件开发过程 https://en.wikipedia.org/wiki/Software_development_process

3、百度百科:瀑布模型 http://baike.baidu.com/view/551037.htm

4、维基百科:敏捷软件开发 https://en.wikipedia.org/wiki/Agile_software_development

5、百度百科:极限编程 http://baike.baidu.com/view/259207.htm

6、http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

所有图片来源于网络

敏捷开发与传统开发

标签:

原文地址:http://www.cnblogs.com/liu-zheng/p/5965635.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!