敏捷开发与瀑布模型的优势_敏捷开发与瀑布模型的异同 - CSDN
  • 敏捷开发 PK 瀑布模型

    2014-05-19 17:45:34
    以前都是遵循传统的瀑布模型,而新方式的开发思路直接传统的开发思路来了个正面碰撞,擦出了阵阵“火花”。  在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经...

       在去年12月底开始接触高校平台项目,到现在也快有小半年了。这次的开发不同以往。是以敏捷开发作为开发方式。以前都是遵循传统的瀑布模型,而新方式的开发思路直接与传统的开发思路来了个正面碰撞,擦出了阵阵“火花”。


        在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经根深蒂固,再加上对需求不熟悉,对开发环境不熟悉,新方式的开发反而让人感到别扭,麻烦,甚至抵触。


        由于对敏捷开发的不理解,大家也爆发了很多争论,不过也正是这些争论,引导我们逐步走向了敏捷开发的正途上。


        记得当初在做yh收银系统的时候,采用的是传统的瀑布开发模式。自己做需求也是很费力气的,首先整理当前版本的系统功能,收集和整理以往的维护记录,整理客户的建议。然后再加上自己维护过程中发现需要改进的地儿和参考同类软件,历时1周,需求算是基本做出来了,但是还是有很多问题,许多想要的动能,自己也不确定到底是什么样的。以至于到概要设计完成后,发现设计与最终想要的差距太大,最终决定推倒重来,又花费了1周的事件才搞定需求。加上前面浪费的时间,光是做需求,就花费了近一个月的时间了。也就是说这近一个月的时间,小组成员大部分的时间(项目方面的)都荒废掉了的。


        设计花费的时间就更多了,我们采用的是三层架构+2层接口+抽象工厂模式,实现差不多都是组长去设计,然后画出时序图来,再安排小组成员去完成。做的过程中发现当初设计有问题,还得推到重新去设计。结果就造成了代码没花太长时间,而反复修改设计和各种文档花费时间太多了。


        实现过程看着时序图也不一定可以搞定,而且大家当时的水平也的确有待提高,经常被问题卡住,开发停滞了。没有一个例子做参考,做起来也很费劲。甚至有时候为了完成功能,使用简单的但是不安全的方式实现了,以至于后来得反复修改。


        而且开发时间跨度有点大(最终耗时5个月),小组中有抵触情绪蔓延。。。


        当然我这里只是说在使用瀑布模式做yh系统时,所遇到的问题,并不是说我们开发的一无是处。相反我们开发突破了以前许多设计枷锁,让我们的系统变得很人性化,当然这不是本次讨论的重点,就不在这里说了。


        以上这些问题是有部分是能力所限,但是通过改变开发模式也能解决这些问题。而敏捷开发就是其中一种解决方案。


        本次在做高校平台项目时,采用的是Scrum敏捷开发模式,在简单了解了敏捷开发模式后,越发感觉敏捷开发的优势了。瀑布模式是以文档驱动的,而Scrum则是以人为核心,只完成必要的文档即可,它更强调人与人的交流。而且Scrum之所以成为敏捷开发,主要还是因为它能快速响应变化,快速迭代。


        按照Scrum的开发流程,建立backlog,列story,在迭代计划会上大家一起评story优先级(跟scrum稍有不同),然后制定迭代计划,并一起对本次迭代任务进行评估工时。用集体的智慧和知识对“做什么,怎么做”打成共识。每个人只专注分配给自己或者自己领取的任务模块即可。每日立会也是一个很不错的了解开发进度的方式。每次做完任务后,都要叫Scrum Master来检查一遍。而且在迭代中期和末期都有集体审查,在很大程度中减少了系统bug,不至于最后bug遍地,无法集成。


        当然在这过程中也会遇到问题,被一些难的问题卡住了,会在立会中提到,如果不是很重要的问题,给2天时间解决,否则放弃这个任务,换另一个人去做。或者采取结对编程,这个的确很有效。在对一个大家都了解都比较少的,或者一些逻辑复杂的问题上,一般采用2种方式。一是2个人同时领取相同的任务,各自做各自的,谁完成了就用谁的。另一种是结对编程,2个人坐在一起来完成一个任务。我更推荐爱你结对编程,它在这些问题上的投入往往是1+1>2的,绝对是一个very good choice。


        本次开发设计到许多陌生的知识,如果单纯的理解起来,比较费力,不过如果有工具辅助就是另一回事儿了。本次管理上的不论是“禅道还是“JIRA都是非常值得推荐的项目管理软件。也是通过这两款项目管理软件,才使得我能快速了解和熟悉敏捷开发流程。另一个我觉的非常值得推荐的则是Confluence。Confluence则是一个很不错的Wiki,自我感觉要比使用svn更专业,也更方便。


        当然并不是所有的项目都适合用敏捷开发来做,选择哪种开发模式是根据项目而定的。对时效要求比较高的比如互联网产品,比较适合用敏捷开发。而一些大型、超大型的项目如军工、航天的,就不太适合敏捷开发。还是那句话,适合的才是最好的。


    展开全文
  • 瀑布模型开发与敏捷开发的对比     瀑布模型开发: 严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义...

    转自http://www.cnblogs.com/zh2000g/archive/2010/02/22/1671286.html

     

    瀑布模型开发与敏捷开发的对比

     

     

    瀑布模型开发:

    严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。

    使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

     

    强调文档,在开发的后期才会看到软件的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

     

    瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等。对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。

    在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道(本意是为了提到效率,但实际上有时候产生的是互相的理解偏差)。

     

    瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。

     

    既然叫做瀑布,就意味着不应该走回头路。否则如果出现返工,付出的代价会很大。

    软件生命周期前期造成的Bug的影响比后期的大的多。

     

     

    敏捷开发:

    核心是迭代。

    因为最终目标是让客户满意,所以能够主动接受需求变更,这就使设计出来的软件有灵活性,可扩展性。

     

    宣言:

    个体和交互 胜过 过程和工具

    可以工作的软件 胜过 面面俱到的文档

    客户合作 胜过 合同谈判

    响应变化 胜过 遵循计划

     

    简单设计,重复迭代。减少不必要的文档。

    客户最关心的功能最先完成。

    要求客户有时间对每次迭代的成果进行确认,提出改进意见。

     

    沟通是非常重要的,所有的开发人员对项目活动的理解应该是一致的。

     

    开发团队有两个队伍,业务团队和技术团队。如果任何一方控制了沟通,那么项目注定会失败。如果业务一方控制,项目会议上就会不断的要求功能和交付日,而不太担心开发人员是否能够全部完成或开发人员是否明白他们的真正要求;如果开发人员控制了沟通,那么项目会议上技术术语会代替面向客户的业务语言,开发人员也失去了通过倾听来了解客户真正需求的机会。

     

    PMBOK的项目管理是自上而下的命令式管理,而敏捷的管理是团队的自我管理和项目经理的服务式管理。

     

    敏捷开发不能在一开始就给出项目的成本计划。

     

    在有技术问题还没有解决的情况下不适合展开迭代。

    展开全文
  •  瀑布模型核心思想是按工序将问题化简,将功能的实现设计分开,便于分工协作,即采用结构化的分析设计方法将逻辑实现物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和...

    瀑布模型
      瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
      简单的说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

    一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

    迭代模型
    迭代的方式就有所不同,假如这个产品要求6个月交货,我在第一个月就会拿出一个产品来,当然,这个产品会很不完善,会有很多功能还没有添加进去,bug很多,还不稳定,但客户看了以后,会提出更详细的修改意见,这样,你就知道自己距离客户的需求有多远,我回家以后,再花一个月,在上个月所作的需求分析、框架设计、代码、测试等等的基础上,进一步改进,又拿出一个更完善的产品来,给客户看,让他们提意见。

    就这样,我的产品在功能上、质量上都能够逐渐逼近客户的要求,不会出现我花了大量心血后,直到最后发布之时才发现根本不是客户要的东西的情况。

    两种方法的比较:

    瀑布模型:假如我们对用户的需求判断的不是很准确时——这是很常见的问题,一点也不少见——你开发了几个月甚至是几年,当你把产品拿给客户看时,可能与客户原先想要的相差很远。

    迭代模型:相较瀑布较好,但也有自己的缺陷,那就是周期长、成本很高。适合大项目、高风险项目,比如是航天飞机的控制系统时,迭代的成本比项目失败的风险成本低得多,用这种方式明显有优势。


    敏捷开发和迭代不是一回事

    敏捷开发与迭代式开发是整体与局部的关系。打个比方,前者就像地球,而后者像欧亚大陆。

    敏捷开发是一个总体概念,而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)等等。

    展开全文
  • 文章目录瀑布模型/改进的瀑布模型螺旋模型增量和迭代模型原型法快速和敏捷开发关于选择生命周期模型的最后的总结 瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效...

    瀑布模型/改进的瀑布模型(Waterfall Model)

    虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求 ->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以 组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段.

    由于需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个阶段.

    在这里插入图片描述
    瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好 的扩展性和可维护性.但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设计和开发人员往往在项 目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题.

    很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能 够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确, 没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.

    架构设计是软件开发中一个重要的关注点.因此在RUP中也提及到软件开发要以架构为核心.因 此在架构设计完成后系统会被分为相关的子系统和功能模块.每个功能模块间的接口都可以定义清楚.在这种情况下,当模块B的详细设计做完成后往往就没有必要 等到其它模块的详细设计都要完全作完才开始编码,因此在架构设计完成后可以将系统分为多个模块并行开发,每个模块仍然遵循先设计和编码测试的瀑布模型思 路.这是瀑布模型的一种最重要的改进思路,也可以说这是一种增量开发的模型.
    在这里插入图片描述
    当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.

    在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来.

    螺旋模型(Spiral Model)

    首先螺旋模型是遵从瀑布模型的.即需求->架构->设计->开发->测试的路线.螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.
    在这里插入图片描述
    螺旋模型的每一次迭代都包含了以下六个步骤
      1.决定目标,替代方案和约束
      2.识别和解决项目的风险
      3.评估技术方案和替代解决方案
      4.开发本次迭代的交付物和验证迭代产出的正确性.
      5.计划下一次迭代
      6.提交下一次迭代的步骤和方案.

    螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.

    螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.

    螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP提倡 的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代(Rational Unified Process 统一软件开发过程,迭代开发)的目的在于逐步求精而不是仅仅完成瀑布模型某一阶 段的工作.

    增量和迭代模型(Incremental Model)

    增量迭代是RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念.假设现在要开发 A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二 次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐 渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的 基础功能都已经完成.

    RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一 个可以交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很大的关 系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代.如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相 关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.
    在这里插入图片描述
    就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决.但迭代模型在这方面更有优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化.

    业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同时每个增量也可以是独立发布的小版本.由于系统的总体设计 往往对一个系统的架构和可扩展性有重大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统的健壮性和可扩展性.

    原型法(RAPId Prototype Model)

    原型一般都不是单独采用的一种生命周期模型,往往会结合瀑布和增量迭代等方法一起使用.对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期 模型.对于迭代开发来讲,每一个迭代周期的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲,我们在需求阶段也可以进行界面和操作建模,形 成DEMO后和用户做进一部的需求沟通和确认.

    当你的用户没有信息系统的使用经验,你的系统分析员也没有过多的需求分析和挖掘经验的时候,需求分析和调研过程则更需要是一个启发式的过程.而原型则是 这种很好的启发式方法,可以快速的挖掘用户需求并达成需求理解上的一致.否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西.

    原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这种原型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的 产出都是可以独立运行和包含基础功能的系统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完善.

    喷泉模型(fountain model 面向对象的生存期模型,OO模型)

    喷泉模型与传统的结构化生存期比较,具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来,可以落在中间,也可以落在最底部。

    快速和敏捷开发

    我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去 挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周 期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

    关于选择生命周期模型的最后的总结

    1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
      2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
      3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
      4.在需求不稳定情况下尽量采用增量迭代模型
      5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
      6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
      7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
      8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
      9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则。

    引用文章1:软件开发生命周期模型 瀑布模型、增量模型、原型模型、螺旋模型、喷泉模型总结

    引用文章2:瀑布模型、演化模型、螺旋模型、喷泉模型等等的区别

    展开全文
  • 瀑布模型敏捷开发思想并不是二者只选其一的关系,还可能把敏捷开发的思想融入到“流水线工厂式”的管理中。 只有认真分析环境因素(外界+人员素质本身)的变化,才能够选择最适宜的开发方式。要知道,最适合的才...
  • 传统瀑布开发: 敏捷开发 敏捷开发优势 拥抱变化 进度可见
  •  虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求 ->分析->设计->编码->测试的阶段...
  • 最近和朋友谈起敏捷开发(Agile Model)和瀑布开发(Waterfall Model)模式,很多人认为敏捷开发是未来的项目实施的趋势,瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼,联想也在使用敏捷的方式实施一些...
  •  瀑布模型、极限编程、敏捷开发是有代表性的开发模式,在对开发者、客户、最终的产品的关注上的变化,体现了软件开发管理者在管理模式上的变化。   瀑布模型  是一种理想化的开发模型,要求有明确的需求...
  • 敏捷开发瀑布开发

    2019-10-15 17:49:03
    敏捷看来,很多情况下面,我们都无法去了解到全部的内容,或者即使是了解到,我们也不能保证这些内容是不会变化的。所以先根据主路径,完成主要...对于瀑布开发模型来看,似乎依然具备很可靠的工作逻辑,一个工...
  • 瀑布模型/改进的瀑布模型  虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段...
  •  瀑布模型、极限编程、敏捷开发是有代表性的开发模式,在对开发者、客户、最终的产品的关注上的变化,体现了软件开发管理者在管理模式上的变化。   瀑布模型  是一种理想化的开发模型,要求有明确的需求...
  • 瀑布开发、迭代开发,区别【都属于,生命周期模型】  两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说。  传统的瀑布开发,也就是从需求到设计,从设计到编码,从编码...
  • 什么是敏捷开发1.1 敏捷开发的定义1.2 敏捷开发的原则1.3 敏捷开发的特点1.4 传统的开发模式和敏捷开发模式的对比1.5 敏捷开发的分类1.5 Scrum 一. 什么是敏捷开发 1.1 敏捷开发的定义 2001年,由Martin Fowler,...
  • 敏捷开发

    2019-06-24 19:54:47
    文章目录什么是敏捷开发一、概念二、优势三、误区四、特点五、核心原则六、敏捷开发与瀑布模型开发的区别敏捷开发瀑布模型开发:七、总结 什么是敏捷开发 一、概念     简单的说,敏捷开发是一种以人为核心、...
1 2 3 4 5 ... 20
收藏数 1,877
精华内容 750
关键字:

敏捷开发与瀑布模型的优势