敏捷开发和传统开发的比较_敏捷开发和传统开发 - CSDN
  • 敏捷软件开发传统软件工程的比较

    敏捷软件开发与传统软件工程的比较


                软件工程的开发过程中有两种不同的管理和开发体系,一种是基于“瀑布模型”的预设性传统软件工程,另一种是轻量级的适应性敏捷软件开发。本文简单阐述传统软件工程的开发方法与敏捷软件开发的区别,并通过“瀑布模型”和SCRUM方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出,把传统软件工程和敏捷软件开发相结合,将架构“颗粒化”,在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法,实现预见性和适应性折中。
            随着计算机的发展,对软件的需求越来越大,软件的规模也变得越来越大,结构越来越复杂,软件开发管理困难而复杂,在这个“软件危机”背景下产生的传统软件工程,用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代,但随着社会和科技的发展,对软件的需求变化越来越快,传统的软件工程很难再适应瞬息万变的客户需求,敏捷软件开发应运而生,其轻量级、简单、可快速交付、适应性强收到开发团队的青睐,与传统软件工程并肩,形成软件工程中的两大开发体系。
    (1)传统软件工程
           基于“瀑布模型”的传统软件开发方法中,以软件架构为核心,采用结构化的设计和分析方法将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。并规定他们自上而下,相互衔接的顺序,如同瀑布的流水一般,各个阶段的通过文档相互流通。前期就要设计好整个软件大厦的框架来指导和支撑后面各个方面的开发和维护工作,后面在根据前期设计的蓝图来逐步实现。由架构师完成软件架构设计,开发人员再根据软件大厦的蓝图进行软件开发。这种开发方法的优点是,超前的预见性和每一阶段都要通过严格的审查才能进行下一个阶段,保证了软件的质量。缺点是,软件的框架一旦确定下来就很难改变,甚至会牵一发而动全身,难以适应变换莫测的客户需求。由于各个阶段要自上而下相互衔接,各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。
           瀑布模型是Winston Royce在1970年提出的一种软件开发模型,瀑布式开发是一种传统的计算机软件开发,是最经典的预见性软件开发方法,严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通,每个阶段结束时要进行严格的审查,检查功能设计和实现是否符合上阶段流下了的文档的要求,如果不符合就逆流到上个阶段检查并修正,以此往复,直到流到最后阶段产品通过测试后进行发布及运行期间的维护。

           三个阶段:定义阶段、开发阶段和维护阶段。开发阶段架构师要有预见性地分析客户现在的需求以及以后可能变动的需求,设计规划好大量的功能需求和非功能需求,尽可能多地满足客户后面需求的变动,避免日后重构软件框架带来的成本亏损。设计包括UML图,API接口,数据库表等。开发阶段开发人员根据架构师的对客户需求分析以后设计的蓝图进行软件的开发和测试,实现用户的需求。运维阶段开发团队根据用户使用软件的体验、反馈、软件存在的bug和新增功能需求对软件进行维护,保证软件在保证鲁棒性的前提下尽可能地满足客户的需求。
    六个流程:制定计划、需求分析、软件设计、程序编写、软件测试和运行维护。
           瀑布模型的特点:强调文档:瀑布模型每个阶段之间的沟通和交流就是文档,上一个阶段的输出就是下一个阶段的输入,文档就是前后阶段衔接的介质。缺少开发人员之间面对面的沟通和交流,造成文档臃肿现象。结构明显:按需求分析将整个工程划分为完整的阶段集合,每个阶段都有明确的检查点,当出现问题可以使用顺藤摸瓜式往上检查。当一个阶段结束后通过严格审查,就可以只关注下一个阶段,出现问题再逆流检查。

    (2)敏捷软件开发
           2001年由17位业界专家构成的敏捷开发联盟成立,联盟起草了敏捷宣言:个体与交互胜过过程与工具;可用的软件高于复杂的文档;客户的合作胜过合同的谈判;响应变化胜过遵循计划。敏捷软件开发是一组重视人的主观能动性和开发人员、管理层和产品负责人的沟通,通过迭代式和增量式软件,追求便捷,可快速交付,及时响应客户需求变动的软件开发管理方法。
           敏捷软件开发方法体系主要包括:SCRUM、XP(极限编程)、CRYSTAL(水晶编程)、PPD(特性驱动开发)等。敏捷软件开发的一个精髓就是“刚刚够”思想。用逐步实现的思想替代完整架构,每一步的需求和人员及其沟通、开发成本都刚刚好,通过不断地迭代,在迭代过程中响应客户需求的变化,实现最紧致成本,体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考,总结经验和吸取教训。
    SCRUM方法:
           在敏捷软件开发中,软件项目被切分成很多个子项目,通过选取优先级较高的一组子项目作为敏捷迭代的球心进行迭代,每次迭代都有明确的需求、目标、人员、并且每次迭代之后都要有可交付的产品。就好比从山顶滚雪球,选取优先级较高的需求作为首次迭代的球心,经过增量式迭代,每次迭代加带一定的需求滚下山,下山就可以形成可交付的产品。

    三个角色:管理层(Scrum Master)、产品负责人(Product Owner)和开发团队(Team)。
           三种工件:产品列表(Product Backlog)、迭代列表(Sprint Backlog)和燃尽图(Burn Down Chart)。
           四个会议:Sprint Plan Meeting(Sprint计划会议、需求评审会议)、Daily Scrum Meeting(每日站立会议)、Sprint Review Meeting(验收会议)和Sprint Retrospective Meeting(Sprint回顾会议)。

    五个步骤:
    (1)Product Owner根据需求的优先级确定一个排序好的Product Backlog;
    (2)Scrum Team通过Sprint Plan Meeting根据Product Backlog按优先级选出一组需求作为迭代的目标,即Sprint Backlog。这个阶段一般的时间是4周。
    (3)Scrum Team完成Sprint Backlog过程中需要每天都要进行Daily Scrum Meeting,每个人都要汇报所完成的进度和遇到的问题,总结经验,通过Burn Down Chart记录工作的整个过程。
    (4)当本次Sprint把Sprint Backlog都实现完之后进行Sprint Review Meeting,这个会议总管理层和产品负责人以及开发团队都要参加,讨论本次Sprint交付的产品,以及根据产品负责人的需求变动及时调整。
    (5)最后进行Sprint Retrospective Meeting,回顾本次迭代整个过程中遇到的问题,以及解决方案,为下一轮Sprint做准备。
          总结:
    (1)敏捷开发与传统软件开发的比较
    敏捷开发的优点是轻量级、简单、可快速交付、最大的特点是高度透明、检验和适应,注重开发团队之间以及开发团队与客户的及时沟通,主张响应需求变化,但是不够系统。
    传统软件架构的优点在于预见性和系统性,能在正式开发前预见软件的功能需求和非功能需求,最大的特点是重视文档和结构明显,主张固定的流水开发,很难响应客户需求的变化,难以保证开发的灵活性。
    (2)敏捷开发与传统软件工程的融合
    将具有系统性和预见性的传统软件工程架构嵌套到敏捷开发的每次轻量级的迭代中,将软件架构颗粒化,嵌套到整个敏捷开发,使软件工程兼具软件架构的预见性和敏捷开发的适应性,根据项目的大小来调整嵌套的程度,根据每次迭代项目的大小来选择不同的架构,实现敏捷开发与软件架构融合的双赢。

    展开全文
  • 敏捷开发和传统开发

    2018-07-23 18:56:56
    一般的传统开发是指将整个项目完全开发完交给用户。 但交给用户的时候可能用户感觉没有达到他们想要的效果,所以出现了现在的敏捷开发敏捷开发是指敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法...

    一般的传统开发是指将整个项目完全开发完交给用户。

    但交给用户的时候可能用户感觉没有达到他们想要的效果,所以出现了现在的敏捷开发。

    敏捷开发是指敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。(先交给用户一个小的但包含用户需求的项目,根据用户提出的意见进行修改,是一个不断迭代的过程)。

    展开全文
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点问题摸索出适合自己的一套模式。 大家都知道,创业公司刚开始需要研发出...

    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

    大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

    我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

    现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

    不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

    尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

    传统开发过程
    传统开发过程

    由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

    为什么会失败呢?后来思考了这些问题:

    1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

    2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

    3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

    4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

    不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

    尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

    敏捷开发的主旨

    一:个体及交互比流程与工具更具价值

    二:可用的软件比冗长的文档更有价值

    三:与客户的协作比合同谈判更有价值

    四:对变化的响应比遵循计划更有价值

    而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

    创业公司敏捷开发敏捷流程化
    创业公司敏捷开发敏捷流程化

    敏捷开发简单流程

    1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
    2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
    3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
    4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
    5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
    6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
    7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

    我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

    1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

    • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
      a、测试要验收功能,必须理解业务需求。
      b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
      c、团队大部分是男生,女生推广更有亲和力一些。
    • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

    2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

    3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

    • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
    • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
    • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
    • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在 1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
    • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。

    创业公司敏捷开发任务墙
    创业公司敏捷开发任务墙

    • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
    • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
    • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。

    创业公司敏捷开发结对编程
    创业公司敏捷开发结对编程

    • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

    经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt 给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

    ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

    另曝光一下项目1参与成员:

    项目1敏捷团队 
    项目1敏捷团队
    展开全文
  • 分享一篇关于敏捷开发的好文,希望经理爸爸们喜欢~ 原PO地址:https://www.cnblogs.com/yt96/p/5983265.html 敏捷开发的起源 在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求...

    今日雾霾,忙于赶作业。分享一篇关于敏捷开发的好文,希望经理爸爸们喜欢~

    原PO地址:https://www.cnblogs.com/yt96/p/5983265.html

    敏捷开发的起源

    在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对其弊端进行了改进,提出了敏捷方法。

    2001年2月,由Martin Fowler,Jim Highsmith等17位软件开发专家起草的敏捷宣言发表,敏捷联盟成立。敏捷开发作为一种新的方法正式诞生。敏捷宣言中所表述的价值观分为四个方面:

    (1)个体和互动 高于 流程和工具(2)工作的软件 高于 详尽的文档
    (3)客户合作 高于 合同谈判
    (4)响应变化 高于 遵循计划

    同时敏捷宣言还包括12条原则。这十二条原则是以上四条主要的价值观在实际工作中的体现。

    总体来说,敏捷开发作为一种新的软件工程方法,与传统方法相比更加注重人的因素。不再把开发者当作一个物化的,投入多少时间可以完成相应数量代码的代码开发机器;而是注重开发者之间的互动以及开发者和用户之间的互动,同时因为增加了交流和协作使得开发的项目更加灵活和易于修改。

    敏捷开发的主要特点

    与传统开发方法相比,在敏捷开发的整个过程中,有以下几个主要的特点:

    (1)敏捷开发的过程有着更强的适应性而不是预设性,从敏捷宣言的第四条响应变化高于预设计划便可以看出来。因为软件开发过程的本身的不可预见性,很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。很多对软件的预期都在后期的修改和完善过程中产生。因此高适应性显然更加符合软件工程开发的实际。而敏捷开发实现其适应性的方式主要在于,第一,缩短把项目提交给用户的周期;第二,增加用户,业务人员,开发人员这三者之间的交流;第三,通过减少重构的成本以增加软件的适应性。

    (2)敏捷开发的过程中,更加的注重人的因素。在传统软件工程中,个人的因素很少的被考虑到分工中,每个个体都是只是整个代码开发机器的一个小小的螺丝钉,个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。而在敏捷开发过程中,每个个人的潜力被充分的考虑,应用什么技术很大程度上直接由在第一线开发的技术人员决定;每个人的特点和创造力都可以充分地发挥,这样开发出来的软件更加的具有生命力,因为他融入了开发者的心血和创意,开发者不再是进行机械的乏味的堆砌,而是创造属于自己的艺术品,这样的条件下产生的代码必然在质量上更占优势。

    (3)在敏捷开发的过程中,整个项目是测试驱动的而不是文档驱动的。不仅每个模块有着自己的相应的测试单元,开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试,并且集成测试贯穿了整个开发过程的始终。集成测试每天会进行十几次甚至几十次,而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。这样,在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来,使得更加容易在错误刚刚产生的时候发现问题从而解决问题。这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。

     

     敏捷过程模型的一个实例:极限编程

    敏捷过程作为一种开发过程模型,产生了很多不同的可以应用到实际中的编程方法。这里介绍一种应用的比较广泛的开发方法,极限编程,来具体体现一些敏捷开发过程的特点。

    极限编程过程分为策划、设计、编码和测试四个阶段。

    (1)策划阶段

    首先在策划阶段,用户和开发这进行交流,开发者总结出一系列“用户故事”,描述软件某一部分功能。之后客户对这些功能进行优先级排序,xp团队评估每一个故事的成本。之后客户和xp团队共同决定在开发的下一个版本中将会新增哪些功能。而在版本不断的迭代的过程中,会进行很多次这样的策划过程,每一次客户都可以根据已有的功能来决定是否要新增一些功能,以及要新增哪些功能。

    (2)设计阶段

    在设计阶段,开发人员会根据用户故事,提出这些用户故事的实现方案。设计的过程中主要遵循简洁的原则,也就是尽量使用简介的表述而不是复杂的表述。而设计的另一个方面则是重构,重构是一种通过不改变代码的外部功能的情况下改变软件模块的内部结构从而优化软件系统的功能的过程。这是一种改进代码的设计。

    在设计的这两个层面中,我们可以看到在xp开发过程中,设计和开发是同步进行的。我们在不断实现开始设计的过程中,同时要对到吗进行优化也就是重新设计。这样,大大的增强了整个软件开发的适应性,而不是始终刻板的实现最开始的第一版设计。

    (3)编码阶段

    xp开发的第一件任务不是直接对初步的设计和用户故事进行编码,而是针对这些设计全力开发单元测试。完成了单元测试也就确定了开发者要实现的所有功能。这样开发者就只需要全力通过单元测试,而不必在实现什么功能上再浪费不必要的时间和精力。这正体现了敏捷开发的以测试驱动的特点。

    而在敏捷开发中,很重要的一个提高效率的方式就是结对编程。在结对编程的过程中,两个开发者共用一台电脑,并各有分工。其中一个人进行实际的编码实现,另一个人在旁边考虑代码在宏观上该如何实现,比如针对什么功能应该使用什么样的算法。这样,在编码者工作遇到问题时,两个人交换位置。这时在旁边思考的人更有可能可以解决这一问题。事实上,结对编程的形式不必拘泥于什么规矩。关键在于,两个人共同开发的过程中,两个人的交流可以使得大部分的问题可以在第一时间解决。并且,因为两个人中只有一个人在进行编程这一项比较疲惫的工作,另一个人较为轻松,这样可以保证开发效率一直保持在一个比较高的状态。

    (4)测试阶段

    每一个模块都通过自己的单元测试之后,开发者会将所有的模块集成到一起进行测试。这样可以及时发现每一模块在最近一次改动之中出现的问题同时避免一些兼容性问题。每一次改动一点小问题要比等到最后一次集中修改所有问题要容易得多。

    敏捷开发生态系统

    敏捷开发模型在实际中有着很多表现形式。极限过程开发(xp)时其中的最为广泛应用的一种。还有很多其他的,比如:自适应软件开发、Scrum、动态系统开发、Crystal、特征驱动开发、精益软件开发、敏捷建模、敏捷统一过程等。这里只举两个例子介绍一下其主要的特点。

    自适应软件开发主要从整体上强调软件项目团队具有自我组织的动态性、人与人之间的协作、个人以及团队的学习,从而使团队更有可能取得成功。

    Scrum开发方法,这个开发方法最大的特征就是每日例会。在每日例会中,每个人交流自己昨天干了什么,今天将要干什么,以及自己在工作中遇到了哪些问题。这样大大地加强了团队成员之间的交流。

    我们可以看到,很多人都投入到了敏捷开发的研究和使用中。敏捷开发确实有着非常强大的生命力。

    敏捷开发与传统开发方法的比较

    优势

    敏捷开发的高适应性,以人为本的特性,和轻量型的开发方法即以测试为驱动取代了以文档为驱动,这三个主要的特点,也就是敏捷开发相对与传统开发方式的主要有点。因为他更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    劣势

    与传统开发方式相比,敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求,而在每次新的需求产生时都可能引起整个系统的大幅度的修改。因为开发者在开发上一个版本的时候,完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中,并不一定总是有效的。

    而另一个方面,敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档,这样在一个大型项目比如一个操作系统开发的时候,由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

     

    展开全文
  •  首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行详尽的需求调研,根据需求进行完全的架构设计,之后进入开发过程,在...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发传统的开发模式和敏捷开发模式的...
  • 敏捷开发传统开发

    2017-09-18 11:32:50
    敏捷开发传统开发本文章谨代表个人人观点: 传统开发流程的局限性 传统手工测试的局限性 开发模式的转型 传统开发流程的局限性 1 自由度低 缺乏灵活性 2 缺陷发现晚,无法及时反馈 3 协同合作缺失,容易引起...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 传统开发模型与敏捷开发模型的区别(!!!重点) 传统开发模型有: 瀑布模型, 螺旋模型, 增量迭代模型. 瀑布模型适合 "需求相对稳定或需求变更少"的项目 螺旋模型适合 "复杂度高, 风险大, 规模大"的项目 增量迭代模型...
  • 首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行详尽的需求调研,根据需求进行完全的架构设计,之后进入开发过程,在...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发优点缺点

    2019-10-15 13:20:58
    一、敏捷开发技术的几个特点优势: 1.个体交互胜过过程工具 2.可以工作的软件胜过面面俱到的文档 3.客户合作胜过合同谈判 4.响应变化胜过遵循计划 二、敏捷开发技术的12个原则: 1.我们最优先要做...
  • 敏捷开发流程总结

    2015-12-14 16:36:10
    Agile——敏捷开发,作为CMM...敏捷开发宣言——个体交互 胜过 过程工具可以工作的软件 胜过 面面俱到的文档客户合作 胜过 合同谈判响应变化 胜过 遵循计划虽然右项也有价值,但是我们认为左项具有更大的价值
  • 敏捷软件开发描述了一套软件开发的价值原则, 在这些开发中,需求解决方案皆通过自组织跨功能团队达成。 敏捷软件开发主张适度的计划、进化开发、提前交付与持续改进,并且鼓励快速与灵活的面对开发与变更。 ...
  • 敏捷开发和详细设计

    2013-03-28 10:23:57
    的软件周期来进行,随着敏捷开发方法和敏捷开发工具技巧的发展,软件过程中的 一些步骤被新的开发颠覆甚至忽略。 模块耦合度低的项目,开发人员往往在概要设计、项目结构建立之后,就拿着需求文档在做各自的子...
  • 载。 瀑布开发模式: ...瀑布开发模式有以下显著的特点: ...1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义...2.重视强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的
  • 敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可...
1 2 3 4 5 ... 20
收藏数 40,970
精华内容 16,388
关键字:

敏捷开发和传统开发的比较