2016-10-11 20:34:31 u012755393 阅读数 3896
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 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)敏捷开发与传统软件工程的融合
将具有系统性和预见性的传统软件工程架构嵌套到敏捷开发的每次轻量级的迭代中,将软件架构颗粒化,嵌套到整个敏捷开发,使软件工程兼具软件架构的预见性和敏捷开发的适应性,根据项目的大小来调整嵌套的程度,根据每次迭代项目的大小来选择不同的架构,实现敏捷开发与软件架构融合的双赢。

2017-03-24 10:08:51 u012562943 阅读数 1147
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

1,提要
软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加整个软件项目的风险。
如何在保证效率的基础上还能安计划、保证质量的完成软件项目?于是产生了软件开发的一些方法,这个方法不是指具体有编码阶段的各种设计模式和技巧,而是在整个软件开发策略层面的方法。
传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识。
2,常用的开发模式
(1)传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到交付大概这样的流程,要求每一个开发阶段都要做到最好。特别是前期阶段,设计的越完美,提交后的成本损失就越少。下面就是典型的瀑布模型。


认识敏捷开发
(3)原型模型,原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。
(3)螺旋模型,将瀑布模型和快速原型模型结合,并特别强调项目风险。通常分为四个阶段组成:制定计划、风险分析、实施工程和客户评估。一般第一个原型只是双方交流的参考,随着后面的版本完善,最终达到目标。比较适合大型项目。
(2)新型的敏捷开发,即迭代式开发,不要求非常完美的需求分析、设计、文档,而是在最短时间内完成一个框架,然后不断迭代,不断测试,直至交付。
但它并不是不需要文档,不需要从需求、设计、开发、测试这样一个过程,在每个迭代过程中仍然需要做这样的事情。
但是敏捷开发更加注重人的因素,不像瀑布式开发那样,由专门的需求人员采集用户需求,由设计师完成设计文档。敏捷开发每个人都是需要了解项目的需求,并不断的进行小会议,不断的测试修改,直到提交。
敏捷开发则是以测试驱动开发,而瀑布式开发是以文档驱动开发。
下图是Scrum(敏捷开发的一种)敏捷开发模式


认识敏捷开发
3,传统开发模式和敏捷开发的优缺点
主要对比比较常用的瀑布模型和敏捷开发。
(1)瀑布式开发:
a.讲求阶段明确,严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。 软件生命周期前期造成的Bug的影响比后期的大的多。
b.特别强调文档,在开发的后期才会看到软件的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。
c.流水式的开发,瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等。对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。当然好的方面就是按一定规范开发,如果有人员流失,短时间内可以补上去,除了核心的东西有文档参考外,开发过程本身就是在一定框架内的。
d.进度一目了解,瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。
(2)敏捷开发
a.唯快不破,敏捷即是快之意,不仅思维快节奏,而且行为也是快节奏,因上受到当今快节奏社会的喜爱。
b.以人为本,和瀑布开发对应的文档为主来说,在敏捷开发中更强调人,在细节开发上个人可以发挥主观性,使用自己善长的技术和模式开发,而非机器式的开发,容易激发团队成员兴趣和创造力。除了项目参与者,人的因素中更考虑到与客户的沟通。每个成员都需要从沟通中,会议交流中,不断实现迭代。
c.结果第一,不强调文档,突破束缚,软件的最终结果才是重点,文档等都是为软件开发本身服务的,完成了一个优秀的、质量可靠的软件才是敏捷开发的重中之重。
d.迭代开发,迭代是敏捷开发的核心,不断迭代测试的过程,实际上就是精益求精的过程,正和现在这个社会的工匠精神相吻合。
e.整合不易,快速迭代,就需要分割整体业务,对于复杂的客户需求,如何兼顾分割与整体,并不容易,这个需要在项目设计之初考虑到。
4,敏捷开发管理方法
敏捷开发的管理方法有很多种,比较广泛应用的有XP、Scrum等。既然都是敏捷开发,他们都有共同点,强调高速响应变更、以人为主重视团队成员自身发展,倾向采用迭代式的软件开发生命周期模型。
敏捷开发中,XP和Scrum的区别:
a.迭代周期不同,XP的每个Sprint(冲阶)的长度大概为1~2周,而Scrum为2~4周。
b.迭代周期内专一性不同,XP在一个迭代中,如一个User Story(用户素材,也就是一个用户需求)还未实现,可以考虑另外需求替换,原则是时间当量相等。而Scrum不允许这样,一旦迭代开发会毕,任何需求不允添加进入,并有Master严格把关,使团队不受干扰。
c.User Story优先级机制不同,XP必须遵守优先级(当然需要先确实优先级),Scrum更灵活,可以不遵循优先级。比如依赖关系中,虽然 US-A高于US-B,但由于要完成A需依赖B,则需要先开发B。
d.实施中是否采用工程方法问题两者做法不同,Scrum这点上没有工程实践处方,体现的是以人为本,自我创造;而XP必须严格按TDD,自动测试,结对编程,简单设计,重构等约束团队,似乎看起来XP的方式束缚了团队,但需要看这个约束的程度,过细则会让人感觉与“以人为本,自我创新”思想不符,但优点就是一定程度上的规范更有利于保证软件质量。
一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”
通过区别,看出: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束
5,总结
通过了解传统瀑布开发模式和新型敏捷开发模式的差异,理解敏捷开发的在现在快节奏时代有更好的适用性:唯快不破,以人为本。

2016-07-20 17:45:42 nuli888 阅读数 1687
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

个人觉得

敏捷开发强调以人为中心,快速迭代,客户参与多沟通,减少不必要的文档,包括Scrum和XP
优点:快速适应变化,做出的项目比较接近客户需要的
缺点:文档不多,如果人员流动大,维护相对更难


瀑布开发强调文档,就是不同阶段按照顺序自上而下而来,如需求、设计、编码、测试(单元测试、系统测试)、维护,每个阶段尽量做得最好
优点:每个阶段可作为检查点,前一阶段完成只需关注后一阶段
缺点:缺少沟通、反馈,文档比较多,不适应需求快速变化,在生命周期后期才看得到结果,如果有一阶段出了大问题,会影响最终成功

2019-07-19 18:13:12 qq_41137493 阅读数 18
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

敏捷开发并不是一开始就有的,敏捷开发的产生一是为了适应这个快速发展的互联网时代,二是为了解决传统软件研发中遇到的各种问题,那传统的软件研发过程中都会遇到哪些问题呢?
一、传统软件产品研发困境
需求变更:需求变更是软件研发中经常遇到的一种情况,传统的软件研发模式属于瀑布流,后一阶段都是在前一阶段交付后,才开始实施,流程多,周期长,变更起来比较麻烦。

质量管理:传统软件的开发模式都是在开发完成后才进行测试,时间上都会比较晚,当测出来比较大的缺陷,可能导致产品无法准时上线。

员工感受:以上的各种原因如果导致产品上线延期,项目人员加班加点,会对士气造成很大的影响,员工的感受不会太好。

产生大量用不到的功能:传统的软件开发周期比较长,功能都要想好了,想全了才上,但是有些功能并不是用户想要的,根据二八法则,80%的人只用了20%的功能,很多功能花费了大量的研发时间却没有给用户带来相应的价值。

市场瞬息万变:市场需求多样化、个性化持续上升、产品创新性要求持续提升,传统软件开发流程时间长,变更流程官僚且缓慢,对变化反映速度很慢,很难适应瞬息万变的市场。

业务面临的痛点:传统开发流程中产品人员很崩溃的事情是,当你终于赶在截止日期将功能规格说明书更新完毕!不过此时的领导已经重新调整了业务方向,这个时候需要你屁颠屁颠的更新说明书,产品经理一般会崩溃,而且最后做出来的产品有可能并不符合市场需求,这个时候还不如快速实现功能,然后拿去市场验证。

二、为什么要实施敏捷开发
跑马圈地:

随着人口红利的结束,互联网由增量市场变成存量市场,同业务模式下的产品竞争加剧,稍微慢一步,就会竞争对手超越,所以在进入市场的初期,大家都求尽快的交付产品,以求达到跑马圈地的效果。

验证需求

微信之前有做过下拉拍视频这样一个功能,但是后来经过用户反馈和数据分析在下一个版本中又去掉了,可见其反应之快,如果微信团队没有实施敏捷开发,做不到这么快的反应速度,在《张小龙最新内部演讲:警惕 KPI 和流程》这篇文章中,就讲到了敏捷开发。产品大神张小龙是这么描述“敏捷开发”的:

实际上,就这么小的一个团队在后面几年里面做的事情远远超过之前几十人的努力,这个小团队是怎么样工作的?这个小团队是当时用了一个方法,叫敏捷项目管理,这里可能在座的一些同事都已经不太了解这个词了,但是当时在腾讯挺鼓励用这样一种方法,我建议在座的如果没有去好好研究过的可以好好研究一下。我们真的做到一种非常敏捷的一种项目的推进方式。

我们今天可以想一些与众不同的点子,然后我们可以很快就看到效果,因为我们可以很快把它上线了,然后可以去验证,如果不对就下线,如果还有改进余地,下个星期再去改它。这是一个能够持续实现你的想法的过程。

三、如何实施敏捷开发,只需全部交给CORNERSTONE即可

CORNERSTONE敏捷开发工具,操作界面简洁,支持一站式DevOps全流程服务,包括代码及需求管理,任务管理、迭代管理,测试管理,缺陷管理,还支持持续集成,自动化测试与部署,无需切换任何软件,再也不用为多套系统而头疼。助力团队全面提升协作效率,保障产品交付质量。下面仅介绍部分功能,详细使用入口请访问「CORNERSTONE官网」。

一、需求管理

image.png

需求是产品研发的起点,产品经理进行市场调研以及用户需求调研后,需要将调研结果进行需求分析,找出用户痛点,设计出符合用户需求的产品。

CORNERSTONE可帮助产品经理排出需求的优先级、明确需求流程和责任人、提高协作效率低下,使需求状态一目了然。

二、快速迭代

快速迭代,可以逼迫团队不断优化流程、提升工作效率。如果发布周期过长,就会导致无法尽快发现用户需求,进而无法及时改进产品。

image.png

CORNERSTON透过增量迭代⽅法进⾏敏捷式开发,根据不同版本制定⽬标与评审计划,同步统计⾄天/周 /⽉视图、燃尽图以及完成度。迭代进度 清晰可追溯,助⼒企业敏捷迭代,⼩步快跑。

三、测试与缺陷管理

在软件测试过程中,对于发现的每一个软件缺陷,都要记录其特征和复现步骤等信息,以便相关人员分析和复现软件缺陷。

1、测试用例编写

可依据思维导图一键生成测试用例或单独创建,可批量或单个设定用例分类与责任人。

image.png

2、测试计划

嵌入一体化的测试解决方案,可以一键执行用例,通过即计划完成,否则可一键关联缺陷。

image.png

3、缺陷管理

image.png

CORNERSTON强⼤的缺陷管理与统计功能,通过分组、解决状态、优先级等列表对缺陷进⾏全⽅位记录与跟踪,同时明确缺陷责任⼈,及时跟进解决缺陷;同时⽀持导⼊导出功能,导⼊时⽀持任意格式,不受模板限制。

四、持续集成

对于敏捷开发来说,开发人员需要尽可能做到提早集成,频繁集成,一般每添加进一些新的代码时,最好都做一次集成,不要临到软件发布或者交付的当天才开始集成,也不要很久才集成一次,如此可尽早发现代码中的问题,保持软件的状态一直是可用的。

image.png

CORNERSTON ⽀持将持续集成等结果部署到对应的测试环境,所有部署版本在测试 环境中可随时访问,⽀持灰度发布到⽣产环境中。

五、自动化测试与部署

CORNERSTON可通过技术手段把集成、测试与部署这些非常耗时的操作自动化。对于大型软件开发团队来说,编译、测试过程都是非常耗时的,这时,通过技术手段把这些耗时的纯体力劳动扔给CORNERSTON去做,只需等待结果就好。

image.png

CORNERSTONE支持依赖脚本pipeline实现的DevOps,可持续集成与自动化部署,可直接在可视化的服务器上进行操作,同时满足多种开发语言,彻底解决敏捷开发在运维层面的瓶颈,方便开发人员对项目开发生命周期进行全盘管理。

image.png

2018-04-24 16:44:33 Mr_EvanChen 阅读数 329
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

敏捷开发的起源

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

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


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

优势

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

劣势

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

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

 

参考文献

[1]基于scrum敏捷开发的软件过程管理研究 王敏

[2]敏捷开发在软件开发的过程中的应用研究 彭志楠

[3]敏捷软件开发技术研究 周莹莹

[4]敏捷软件开发应用研究 范洪涛

[5]http://agilemanifesto.org/iso/zhchs/manifesto.html 敏捷软件开发宣言

[6]http://agilemanifesto.org/iso/zhchs/manifesto.html CSDN 敏捷开发的优缺点

[7]http://www.vaikan.com/agile-programming-10-years-on-did-it-deliver/ 外刊IT评论 敏捷十年,成效几何?

[8]http://www.infoq.com/cn/news/2010/02/scrum-failings Bob大叔关于Scrum和敏捷的七条缺陷

本文转载自:https://www.cnblogs.com/yt96/p/5983265.html

没有更多推荐了,返回首页