敏捷开发 极限开发_极限编程敏捷开发 - CSDN
  • 敏捷开发极限编程

    2010-03-16 22:57:00
    敏捷开发极限编程简介 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发...

    敏捷开发与极限编程

    简介

          2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发过程的方法很多,主要有:SCRUM, Crystal,特征驱动软件开发(Feature Driven Development, 简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme programming ,简称XP).极限编程(XP)是于1998Smalltalk社群中的大师级人物Kent Beck首先倡导的。

    极限编程(XP)

          极限编程(XP)是敏捷软件开发中最著名的一个,它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

    极限编程 是一门针对业务和软件开发的规则,它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论,XP使开发者能够更有效的响应客户的需求变化,哪怕是在软件生命周期的后期。它强调,软件开发是人与人合作进行的过程,因此成功的软件开发过程应该充分利用人的优势,而弱化人的缺点,突出了人在软件开发过程中的作用。极端编程属于轻量级的方法,认为文档、架构不如直接编程来的直接。XP实际上是一种经历过很多实践考验的一种软件开发的方法,它诞生了大概有5 年,它已经被成功的应用在许多大型的公司,如:Bayeris che LandesbankCredit Swis s LifeDaimlerChryslerFirst Union National Bank Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调,XP 是以开发符合客户需要的软件为目标而产生的一种方法论,XP 使开发者能够更有效的响应客户的需求变化,哪怕在软件生命周期的后期。同时,XP 也很强调团队合作。团队包括:项目经理,客户,开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。XP 强调四种价值:交流,简易,回馈,勇气。XP 程序员之间紧密的相互交流,XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。
    XP
    是与众不同的,它有点象快步的舞蹈。XP 开发过程包括许多的小卡片,独立的看,这些小卡片没有什么意义,但是当它们组合在一起,一幅完整的美丽的图片就可以看见,XP方法有别于传统软件开发,它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
    XP
    属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解,的轻重是指用于软件过程管理和控制的、除程序量以外的文档量的多少。XP等轻量开发方法认识到,在当前很多情况下,按传统观念建立的大量文档,一方面需要消耗大量开发资源,同时却已失去帮助预见、管理、决策和控制的依据的作用。因此必须重新审视开发环节,去除臃肿累赘,轻装上阵。
    一、XP的核心思想
         
    从长远看,早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块,并且强调测试、代码质量和及早发现问题。通常,通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。
    二、XP的十二种方法
         
    规划策略(The Planning Game)
         
    结对编程(Pair programming)
         
    测试(Testing)
         
    重构(Refractoring)
         
    简单设计(Simple Design)
         
    代码集体所有权(Collective Code Ownership)
         
    持续集成(Continuous Integration)
         
    现场客户(On-site Customer)
         
    小型发布(Small Release
         
    每周40小时工作制(40-hour Week
         
    编码规范(Code Standards
         
    系统隐喻(System Metaphor
    三、XP的四个核心价值
         
    极限编程中有四个核心价值是我们在开发中必须注意的:沟通(Communication)、简单(Simplicity)、反馈(Feedback)和勇气(Courage)。

    XP
    沟通、简单、反馈和勇气来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程必须重量才能成功的传统观念。

    XP
    精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键,是用沟通、简单、反馈和勇气的态度来对待XP;轻松愉快地来感受XP的实践思想;自己认真实践后,通过对真实反馈的分析,来决定XP对自己的价值;有勇气接受它,或改进它。

    四、XP 带给我们的变化

    通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗?XP认为事实并非如此。

    一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍,这意味着一个项目每年要花200 万美元在程序员身上,而仅仅花10 万美元在电脑设备上。很多聪明的程序员说:我们如此聪明,发现一种方法可以节省20%的硬件开销,然后他们使得源程序大而且难懂和难以维护,他们会说:但是我们节省了20%或者2 万美元每年,很大的节省。反之,如果我们写我们的程序简单而且容易扩展,我们将至少节省10%的人力开销,一笔更大的节省,这是你客户一定会注意到的一些事情。

    另外一个对客户来说很重要的问题就是程序的BUGS XP 不只是强调测试,而且要求正确的测试。测试必须是能自动进行的,以便为程序和客户提供一个安全的环境。在编码的所有阶段,我们不断增加测试用例。当找到 bug 时,我们就添加新的测试,一个紧密的安全网就这样产生了。同一个BUG 不出现两次,这些一定会引起用户的注意。你的客户必须注意的另外一件事情:XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

    一般情况下,客户只有在系统被开发完成以后能真正去体会它。XP 却不一样,它通过加强客户的反馈来缩短开发的周期,同时获得足够的时间来改变功能和获得用户的认同。在XP 中,你的客户应该明确的知道这一点。

    XP
    开发过程的大多的革命是在软件开发的方法上,代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

    五、我们什么时候用XP

    XP
    方法的产生是因为难以管理的需求变化,从一开始你的客户并不是很完全的知道他们要的系统是怎么样的,你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变,这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内,需要一个相当难开发的系统,而且对于你的项目组来说,这个系统是一个新的挑战(从来没有做过),那风险就更大了,如果这个系统对于整个软件行业来说都是新的挑战,那么它的风险就更大了,采用XP 将可以减少风险,增加成功的可能。

    XP
    方法是为小团体开发建立的,在2-10 个人之间。假如你的团体恰好合适,你就不需要用其他的软件工程方法了,就用XP ,但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意,在需求一惯呈动态变化或者高具有高风险的项目中,你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

    XP
    方法需要一个扩展的开发团体,XP 团体不仅仅包括开发者,经理、客户也是其中的一员,所有的工作一环扣一环,问问题,商讨方法和日程,增加功能测试,这些问题的解决不仅仅涉及到软件的开发者。

    另一个需要是可测试性,你必须能增加自动的单元测试和功能测试,然而在你进行这个需求的时候,你会发现有许多的问题很难测试,这需要充分发挥你的测试的经验和智慧,而且你有时还要改变你的设计以便它可以更容易的进行测试。记住:那儿有需求,那儿就应该有测试的方法。

    XP方法的好处的清单上,最后一条是生产力。在同样的合作环境下,XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是:在规定的时间生产出满足客户需要的软件。假如对于你的开发来说,这是很重要的方面,你就可以选择XP 了。

    下面是极限编程的有效实践:

    1.     完整团队XP项目的所有参与者(开发人员,客户,测试人员)一起工作在一个开放的场所中,他们是同一个团队的成员,这个场所的墙壁上随意悬挂着大幅的,显著的图表以及其它一些显示他们进度的东西。

    2.     计划游戏计划是持续的,循序渐进的,每两周,开发人员就为下两周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。

    3.     客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

    4.     简单设局团队保持设计恰好和当前的系统功能相匹配,它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西。并且包含尽可能少的代码。

    5.     结对编程所有的产品软件都是由两个程序员,并排坐在一起在同一台机器上构建的。

    6.     测试驱动开发编写单元测试是一个验证行为,更是一个涉及行为。同样,他是一种编写文档的行为,编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。

    7.     改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净,具有表达力。

    8.     可持续的速度,团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑,极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程,极限编程是一种优良的,通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

     

    敏捷开发

    人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。

    敏捷软件开发宣言:

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

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

    客户合作        胜过  合同谈判

    响应变化        胜过  遵循计划

    虽然右项也有价值,但是我们认为左项具有更大的价值

    我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意。

    即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势。

    经常性地交互可以工作的软件,交互的间隔可以从几个星期到几个月,交互的时间间隔越短越好。

    在整个项目开发期间,业务人员和开发人员必须要天天都在一起工作。

    围绕被激励起来的个体构建项目,给他们提供所需的环境和支持,并且信任他们能够完成工作。

    在团队工作内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

    工作的软件是首要的进度度量标准。

    敏捷过程提倡可持续的开发速度,责任人,开发者和用户应该能够保持一个长期的,恒定的开发速度。

    不断地关注优秀的技能和好的设计增强敏捷能力。

    简单是最根本的。

    最好的构架,需求和设计出于自组织团队。

    每隔一定的时间,团队会在如恶化才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    敏捷团队依靠变化来获取活力,团队几乎不进行预先设计,因此,不需要一个成熟的初始设计,他们更愿意保持设计尽可能的干净,简单,并使用许多单元测试和验收测试作为支援,这保持了设计的灵活性,易于理解性,团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计,为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则加以避免,这些原则是:

     单一职责原则(SRP)

    就一个类而言,应该仅有一个引起它变化的原因

    开放-封闭原则(OCP)

    软件实体应该是可以扩展的,但是不可修改。

    Liskov替换原则(LSP)

    子类型必须能够替换掉它们的基类型。

    依赖倒置原则(DIP)

    抽象不应该依赖于实现细节,细节应该依赖于抽象。

    接口隔离原则(ISP)

    重用发布等价原则(REP)

    重用的粒度就是发布的粒度

    共同封闭原则(CCP)

    包中所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生产生影响,而对于其他的包不造成任何影响

    共同重用原则(CRP)

    一个包中的所有类应该是共同重用的

    无依赖原则(ADP)

    在包的依赖关系图中不允许存在环

    稳定依赖原则(SDP)

    朝着稳定的方向进行依赖

    稳定抽象原则(SAP)

    包的抽象程度应该和其稳定程度一致

    敏捷设计是一个过程,不是一个事件,它是一个持续的应用原则,模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能简单,干净和富有表现力。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

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

    敏捷开发的起源

    在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

    展开全文
  • 敏捷开发极限编程

    2019-06-27 03:38:17
    敏捷软件开发(Agile software development): 它是一种用来应对软件需求的不断变更的新的软件开发技术。 强调整个开发过程中业务人员和开发人员紧密协作在一起,面对面交流,频繁性的交付...极限编程是敏捷开发中...

    敏捷软件开发(Agile software development):

    它是一种用来应对软件需求的不断变更的新的软件开发技术。

    强调整个开发过程中业务人员和开发人员紧密协作在一起,面对面交流,频繁性的交付软件,随时应对需求的变更。追求在尽可能短的时间内交付较小的可用的功能,并在整个项目周期中持续改善和增强。

    极限编程(Extreme programming,简XP):

    极限编程是敏捷开发中最富有成效的几种方法学之一。

    XP是一种近螺旋式开发方法,它将复杂的开发过程分解成一个个小的开发周期,对需求分析、设计、编码、测试进行反复迭代。在小的开发周期中通过客户、业务人员和开发人员的积极交流可以非常清楚软件开发过程中现存的问题并进行及时调整。

    需求:

    把需求分为很多小的模块(功能),客户根据模块的商业价值进行优先级排序,开发人员确定每个模块的风险,保证高风险的模块先被开发,综合评估后将每个模块安排到开发过程中不同的时期。

    设计:

    XP内层的过程是一个个基于测试驱动的开发周期,即先进行测试再编码。每个开发周期开始都有很多相应的单元测试,最开始因为还未开发所有测试都是失败的,通过需求模块的不断完成,通过的单元测试也越来越多。XP设计的最终目标就是每个简单需求模块写出来的程序都能通过所有相关的单元测试。

    编程:

    提倡结对编程(PairProgramming),即两个人一起合作完成。

    测试:

    在开发之前就写好单元测试,开发人员将每次开发好的模块整合到一起进行单元测试,发现bug就要增加相应的测试。除了单元测试之外,还有集成测试、功能测试、压力测试和系统测试等。

    转载于:https://www.cnblogs.com/tobecool/p/6523175.html

    展开全文
  • 极限编程与敏捷开发

    2014-04-27 19:17:01
    极限编程与敏捷开发  在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。 -- Jack Reeves 简介  2001年,为了解决许多公司的软件...

    极限编程与敏捷开发

       在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。
    -- Jack Reeves
    简介
        2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

    极限编程
        设计和编程都是人的活动。忘记这一点,将会失去一切。
    -- Bjarne Stroustrup

        极限编程(XP)是敏捷方法中最箸名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。
    下面是极限编程的有效实践:
    1、    完整团队
    XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
    2、    计划游戏
    计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
    3、    客户测试
    作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
    4、    简单设计
    团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
    5、    结对编程
    所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
    6、    测试驱动开发
    编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
    7、    改进设计
    随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
    8、    持续集成
    团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
    9、    集体代码所有权
    任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
    10、编码标准
        系统中所有的代码看起来就好像是被单独一人编写的。
    11、隐喻
        将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
    12、可持续的速度
        团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。
        极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

    敏捷开发
        人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。
    -- Tom DeMacro和Timothy Lister

    敏捷软件开发宣言:
    n    个体和交互        胜过    过程和工具
    n    可以工作的软件    胜过    面面俱到的文档
    n    客户合作        胜过    合同谈判
    n    响应变化        胜过    遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    敏捷宣言遵循的原则:
    n    我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    n    即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    n    经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
    n    在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    n    围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
    n    在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
    n    工作的软件是首要的进度度量标准。
    n    敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    n    不断地关注优秀的技能和好的设计会增强敏捷能力。
    n    简单是最根本的。
    n    最好的构架、需求和设计出于自组织团队。
    n    每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。
    n    僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
    n    脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
    n    牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
    n    粘滞性: 做正确的事情比做错误的事情要困难。
    n  3B  不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
    n    不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
    n    晦涩性: 很难阅读、理解。没有很好地表现出意图。

    敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
    为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:
    n    单一职责原则(SRP)
    就一个类而言,应该仅有一个引起它变化的原因。
    n    开放-封闭原则(OCP)
    软件实体应该是可以扩展的,但是不可修改。
    n    Liskov替换原则(LSP)
    子类型必须能够替换掉它们的基类型。
    n    依赖倒置原则(DIP)
    抽象不应该依赖于细节。细节应该依赖于抽象。
    n    接口隔离原则(ISP)
    不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
    n    重用发布等价原则(REP)
    重用的粒度就是发布的粒度。
    n    共同封闭原则(CCP)
    包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
    n    共同重用原则(CRP)
    一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
    n    无环依赖原则(ADP)
    在包的依赖关系图中不允许存在环。
    n    稳定依赖原则(SDP)
    朝着稳定的方向进行依赖。
    n    稳定抽象原则(SAP)
    包的抽象程度应该和其稳定程度一致。
        上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。
        
        下面举一个简单的设计问题方面的模式与原则应用的示例:
    问题:
        选择设计运行在简易台灯中的软件,台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着,也可以让灯打开或关闭。

    解决方案一:
        下面图1是一种最简单的解决方案,Switch对象可以轮询真实开关的状态,并且可以发送相应的turnOn和turnOff消息给Light。


                                    
    解决方案二:
        上面这个设计违反了两个设计原则:依赖倒置原则(DIP)和开放封闭原则(OCP),DIP原则告诉我们要优先依赖于抽象类,而Switch依赖了具体类Light,对OCP的违反是在任何需要Switch的地方都要带上Light,这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案,可以采用ABSTRACT SERVER模式,在Switch和Light之间引入一个接口,这样就使得Switch能够控制任何实现了这个接口的东西,这也就满足了DIP和OCP原则。如下面图2所示:



    解决方案三:
        上面图2所示解决方案,违返了单一职责原则(SRP),它把Switch和Light绑定在一起,而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决,适配器从Switchable 派生并委托给Light,问题就被优美的解决了,现在,Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示:



        敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。


    展开全文
  • 极限编程是敏捷开发的一种方法,极限编程针对小型的开发团队来说是一个不错的方法,极限编程本质是务实主义的体现,快速稳定的实现每一个用户要求,是极限编程的基本要求。 1.客户尽量和开发人员在一起,一是可以...
  • 软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的观点...
  • 敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量,不但不...
  • 极限编程是敏捷开发软件开发使用最为广泛的一个方法,作为面向对象方法的推荐开发范型,它包含了策略,设计,编码,测试4个框架活动的规则和实际。 策划:  》倾听一系列的用户故事,描述即将建立的软件的需要的...
  • 极限编程(XP)和SCRUM大概是2种最著名的敏捷开发方法。二者有啥区别呢? 一、XP的特点 1、迭代周期更短,并强调持续反馈 2、测试驱动,自动化测试 3、项目初期迅速生成总体计划,之后迭代发展和完善 4、持续演化 5...
  • 敏捷开发极限编程的简介 什么是敏捷开发?一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一...
  • 敏捷开发极限编程

    2019-06-28 09:39:18
    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。在以前的开发过程中,很多规则已经难于遵循,很多流程复杂而难于理解,很多项目中文档的制作过程正在失去控制。人们试图提出更...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 【引自Jack zhai 的博客】软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的 工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的...
  • 敏捷开发极限编程

    2011-06-27 00:35:22
    什么是敏捷开发?一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和 可运行的特征。简言之,就是把一个大项目分为多个相互联系...
  • 敏捷开发流程总结

    2015-12-14 16:36:10
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...
  • 其实,极限编程是敏捷开发的一个主流开发方法。和传统方法学的本质不同在于它更强调可适应性而不是可预测性。他们相信,和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比,有能力在项目周期的...
  • 极限编程( ...大会,并接受了媒体的采访,谈论了敏捷开发的相关问题。   记者:你能谈论一下敏捷宣言和极限编程( XP )吗?   Ken Beck :在极限编程( XP )后面的基本设想是,肯定有一些对...
1 2 3 4 5 ... 20
收藏数 11,177
精华内容 4,470
关键字:

敏捷开发 极限开发