精华内容
参与话题
问答
  • 什么是极限编程

    2004-10-28 20:43:00
    Extreme Programming(极限编程,简称XP)由Kent Beck在1996年提出的。Kent Beck在九十年代初 期与Ward Cunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有 效。Kent仔细地...
    Extreme Programming(极限编程,简称XP)是由Kent Beck在1996年提出的。Kent Beck在九十年代初
    期与Ward Cunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有
    效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月,
    Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

    XP是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观
    是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简
    单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个
    相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚
    开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。



    什么是软件开发

    软件开发的内容是:需求、设计、编程和测试!
    需求:不仅仅是用户需求,应该是开发中遇到的所有的需求。比如,你首先要知道做这个项目是为了解
    决什么问题;测试案例中应该输入什么数据……为了清楚地知道这些需求,你经常要和客户、项目经理
    等交流。
    设计:编码前,肯定有个计划告诉你要做什么,结构是怎样等等。你一定要按照这个来做,否则可能会
    一团糟。
    编程:如果在项目截止日,你的程序不能跑起来或达不到客户的要求,你就拿不到钱。
    测试:目的是让你知道,什么时候算是完成了。如果你聪明,你就应该先写测试,这样可以及时知道你
    是否真地完成了。否则,你经常会不知道,到底有哪些功能是真正完成了,离预期目标还差多远。

    软件开发中,客户和开发人员都有自己的基本权利和义务。
    客户:
     • 定义每个用户需求的商业优先级;
     • 制订总体计划,包括用多少投资、经过多长时间、达到什么目的;
     • 在项目开发过程中的每个工作周,都能让投资获得最大的收益;
     • 通过重复运行你所指定的功能测试,准确地掌握项目进展情况;
     • 能随时改变需求、功能或优先级,同时避免昂贵的再投资;能够根据各种变化及时调整项目计划;
     • 能够随时取消项目;项目取消时,以前的开发工作不是一堆垃圾,已开发完的功能是合乎要求的,
    正在进行或未完成的的工作则应该是不难接手的。
    开发人员:
     • 知道要做什么,以及要优先做什么;
     • 工作有效率;
     • 有问题或困难时,能得到客户、同事、上级的回答或帮助;
     • 对工作做评估,并根据周围情况的变化及时重新评估;
     • 积极承担工作,而不是消极接受分配;
     • 一周40小时工作制,不加班。

    这就是软件开发,除此之外再还有其它要关心的问题!



    灵巧的轻量级软件开发方法

    一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规
    则、流程和相关的文档工作。灵巧的轻量级开发方法,其规则和文档相对较少,流程更加灵活,实施起
    来相对较容易。

    在软件工程概念出现以前,程序员们按照自己喜欢的方式开发软件。程序的质量很难控制,调试程序很
    繁琐,程序员之间也很难读懂对方写的代码。1968年,Edsger Dijkstra给CACM写了一封题为GOTO 
    Statement Considered Harmful 的信,软件工程的概念由此诞生。程序员们开始摒弃以前的做法,转
    而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格,人们陆续制定
    了很多规则和做法,发明了很多软件工程方法,软件质量开始得到大幅度提高。随着遇到的问题更多,
    规则和流程也越来越精细和复杂。

    到了今天,在实际开发过程中,很多规则已经难于遵循,很多流程复杂而难于理解,很多项目中文档的
    制作过程正在失去控制。人们试图提出更全面更好的一揽子方案,或者寄希望于更复杂的、功能更强大
    的辅助开发工具(Case Tools),但总是不能成功,而且开发规范和流程变得越来越复杂和难以实施。
    为了赶进度,程序员们经常跳过一些指定的流程,很少人能全面遵循那些重量级开发方法。

    失败的原因很简单,这个世界没有万能药。因此,一些人提出,将重量级开发方法中的规则和流程进行
    删减、重整和优化,这样就产生了很多适应不同需要的轻量级流程。在这些流程中,合乎实际需要的规
    则被保留下来,不必要的复杂化开发的规被抛弃。而且,和传统的开发方法相比,轻量级流程不再象流
    水生产线,而是更加灵活。

    Extreme Programming(XP)就是这样一种灵巧的轻量级软件开发方法。



    为什么称为“Extreme”(极限) 

    “Extreme”(极限) 是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、
    做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目,其
    开发过程应该是平稳的、高效的和快速的,能够做到一周40小时工作制而不拖延项目进度。 



    XP的软件开发是什么样

    1 极限的工作环境

    为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务,XP要求把工作环境也
    做得最好。每个参加项目开发的人都将担任一个角色(项目经理、项目监督人等等)并履行相应的权利
    和义务。所有的人都在同一个开放的开发环境中工作,最好是所有人在同一个大房子中工作,还有茶点
    供应;每周40小时,不提倡加班;每天早晨,所有人一起站着开个短会;墙上有一些大白板,所有的
    Story卡、CRC卡等都贴在上面,讨论问题的时候可以在上面写写画画;下班后大家可以一起玩电脑游
    戏……。

    2 极限的需求

    客户应该是项目开发队伍中的一员,而不是和开发人员分开的;因为从项目的计划到最后验收,客户一
    直起着很重要的作用。开发人员和客户一起,把各种需求变成一个个小的需求模块(User Story),例
    如“计算年级的总人数,就是把该年级所有班的人数累加。”;这些模块又会根据实际情况被组合在一
    起或者被分解成更小的模块;它们都被记录在一些小卡片(Story Card)上,之后分别被程序员们在各
    个小的周期开发中(Iteration,通常不超过3个星期)实现;客户根据每个模块的商业价值来指定它们
    的优先级;开发人员要做的是确定每个需求模块的开发风险,风险高的(通常是因为缺乏类似的经验)
    需求模块将被优先研究、探索和开发;经过开发人员和客户分别从不同的角度评估每个模块后,它们被
    安排在不同的开发周期里,客户将得到一个尽可能准确的开发计划;客户为每个需求模块指定验收测试
    (功能测试)。

    每发布一次开发的软件(经过一个开发周期),用户都能得到一个可以开始使用的系统,这个系统全面
    实现了相应的计划中的所有需求。而在一些传统的开发模式中,无论什么功能,用户都要等到所有开发
    完成后才能开始使用。 

    3 极限的设计 

    从具体开发的角度来看,XP内层的过程是一个个基于测试驱动的开发(Test Driven Development)周
    期,诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试
    (Unit Test)。刚开始,因为什么都没有实现,所以所有的单元测试都是失败的;随着一个个小的需
    求模块的完成,通过的单元测试也越来越多。通过这种方式,客户和开发人员都很容易检验,是否履行
    了对客户的承诺。XP提倡对于简单的设计(Simple Design),就是用最简单的方式,使得为每个简单
    的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式(Big 
    Design Up Front),因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计
    复核(Review)、代码复核以及重整和优化(Refectory),所有的这些过程其实也是优化设计的过
    程;在这些过程中不断运行单元测试和功能测试,可以保证经过重整和优化后的系统仍然符合所有需
    求。 

    4 极限的编程 

    既然编程很重要,XP就提倡两个人一起写同一段程序(Pair Programming),而且代码所有权是归于整
    个开发队伍(Collective Code Ownership)。程序员在写程序和重整优化程序的时候,都要严格遵守
    编程规范。任何人都可以修改其他人写的程序,修改后要确定新程序能通过单元测试。 

    5 极限的测试 

    既然测试很重要,XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到
    一起(Continuous Integration),每次整合后都要运行单元测试;做任何的代码复核和修改,都要运
    行单元测试;发现了BUG,就要增加相应的测试(因此XP方法不需要BUG数据库)。除了单元测试之外,
    还有整合测试,功能测试、负荷测试和系统测试等。所有这些测试,是XP开发过程中最重要的文档之
    一,也是最终交付给用户的内容之一。 

    XP中的重要惯例和规则

    1 项目开发小组(Team)

    在XP中,每个对项目做贡献的人都应该是项目开发小组中的一员。而且,这个小组中必须至少有一个人
    对用户需求非常清晰,能够提出需求、决定各个需求的商业价值(优先级)、根据需求等的变化调整项
    目计划等。这个人扮演的是“客户”这个角色,当然最好就是实际的最终用户,因为整个项目就是围绕
    最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员,他们帮助
    客户制订验收测试;有分析员,帮助客户确定需求;通常还有个Coach(教练),负责跟踪开发进度、
    解决开发中遇到的一些问题、推动项目进行;还可以又一个项目经理,负责调配资源、协助项目内外的
    交流沟通等等。项目小组中有这么多角色,但并不是说,每个人做的工作是别人不能插手或干预的,XP
    鼓励每个人尽可能地为项目多做贡献。平等相处,取长补短;这就是最好的XP开发小组。

    2 计划项目(Planning Game)、验收测试、小规模发布(Small Releases)

    XP开发小组使用简单的方式进行项目计划和开发跟踪,并以次预测项目进展情况和决定未来的步骤。根
    据需求的商业价值,开发小组针对一组组的需求进行一系列的开发和整合,每次开发都会产生一个通过
    测试的、可以使用的系统。

    •  计划项目

    XP的计划过程主要针对软件开发中的两个问题:预测在交付日期前可以完成多少工作;现在和下一步该
    做些什么。不断的回答这两个问题,就是直接服务于如何实施及调整开发过程;与此相比,希望一开始
    就精确定义整个开发过程要做什么事情以及每件事情要花多少时间,则事倍功半。针对这两个问题,XP
    中又两个主要的相应过程:

    软件发布计划(Release Planning)。客户阐述需求,开发人员估算开发成本和风险。客户根据开发成
    本、风险和每个需求的重要性,制订一个大致的项目计划。最初的项目计划没有必要(也没有可能)非
    常准确,因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且,这个计划会在实施过程
    中被不断地调整以趋精确。

    周期开发计划(Iteration Planning)。开发过程中,应该有很多阶段计划(比如每三个星期一个计
    划)。开发人员可能在某个周期对系统进行内部的重整和优化(代码和设计),而在某个周期增加了新
    功能,或者会在一个周期内同时做两方面的工作。但是,经过每个开发周期,用户都应该能得到一个已
    经实现了一些功能的系统。而且,每经过一个周期,客户就会再提出确定下一个周期要完成的需求。在
    每个开发周期中,开发人员会把需求分解成一个个很小的任务,然后估计每个任务的开发成本和风险。
    这些估算是基于实际开发经验的,项目做得多了,估算自然更加准确和精确;在同一个项目中,每经过
    一个开发周期,下一次的估算都会有更过的经验、参照和依据,从而更加准确。
    这些简单的步骤对客户提供了丰富的、足够的信息,使之能灵活有效地调控开发进程。每过两三个星
    期,客户总能够实实在在地看到开发人员已经完成的需求。在XP里,没有什么“快要完成了”、“完成
    了90%”的模糊说法,要不是完成了,要不就是没完成。这种做法看起来好象有利有弊:好处是客户可以
    马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等;坏处是客户看到做
    出来的东西,可能会很不满意甚至中止合同。实际上,XP的这种做法是为了及早发现问题、解决问题,
    而不是等到过了几个月,用户终于看到开发完的系统了,然后才告诉你这个不行、那个变了、还要增加
    哪个内容等等。

    •  验收测试

    客户对每个需求都定义了一些验收测试。通过运行验收测试,开发人员和客户可以知道开发出来的软件
    是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间,最好能
    将这些测试过程自动化。

    •  频繁地小规模发布软件(Small Releases)

    每个周期(Iteration)开发的需求都是用户最需要的东西。在XP中,对于每个周期完成时发布的系
    统,用户都应该可以很容易地进行评估,或者已经能够投入实际使用。这样,软件开发对于客户来说,
    不再是看不见摸不着的东西,而是实实在在的。XP要求频繁地发布软件,如果有可能,应该每天都发布
    一个新版本;而且在完成任何一个改动、整合或者新需求后,就应该立即发布一个新版本。这些版本的
    一致性和可靠性,是靠验收测试和测试驱动的开发来保证的。

    3 简单设计,Pair Programming,测试驱动开发,重整和优化

    XP程序员不但做为一个开发小组共同工作,还以两个人为一个小开发单元编写同一个程序。开发人员们
    进行简单的设计,编写单元测试后再编写符合测试要求的代码,并在满足需求的前提下不断地优化设
    计。

    •  简单设计

    XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求,前提是按照这些简单设
    计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了,不需要任何
    画蛇添足的设计,而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

    在XP中,没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中,设计过程几乎一直贯
    穿着整个项目开发:从制订项目的计划,到制订每个开发周期(Iteration)的计划,到针对每个需求
    模块的简捷设计,到设计的复核,以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不
    断前进和发展的过程。从这个角度看,XP是把设计做到了极致。

    •  Pair Programming

    XP中,所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实
    施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过,代码、设计和测试的质量因
    此得到提高。看起来这样象是在浪费人力资源,但是各种研究表明事实恰恰相反。—— 这种工作方式
    极大地提高了工作强度和工作效率。

    很多程序员一开始是被迫尝试这点的(XP也需要行政命令的支持)。开始时总是不习惯的,而且两个人
    的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统
    计,在所有刚开始Pair Programming的程序员中,90%的人在两个月以后都很认为这种工作方式更加高
    效。

    项目开发中,每个人会不断地更换合作编程的伙伴。因此,Pair Programming不但提高了软件质量,还
    增强了相互之间的知识交流和更新,增强了相互之间的沟通和理解。这不但有利于个人,也有利于整个
    项目、开发队伍和公司。从这点看,Pair Programming不仅仅适用于XP,也适用于所有其它的软件开发
    方法。

    •  测试驱动开发

    反馈是XP的四个基本的价值观之一——在软件开发中,只有通过充分的测试才能获得充分的反馈。XP中
    提出的测试,在其它软件开发方法中都可以见到,比如功能测试、单元测试、系统测试和负荷测试等;
    与众不同的是,XP将测试结合到它独特的螺旋式增量型开发过程中,测试随着项目的进展而不断积累。
    另外,由于强调整个开发小组拥有代码,测试也是由大家共同维护的。即,任何人在往代码库中放程序
    (Check In)前,都应该运行一遍所有的测试;任何人如果发现了一个BUG,都应该立即为这个BUG增加
    一个测试,而不是等待写那个程序的人来完成;任何人接手其他人的任务,或者修改其他人的代码和设
    计,改动完以后如果能通过所有测试,就证明他的工作没有破坏愿系统。这样,测试才能真正起到帮助
    获得反馈的作用;而且,通过不断地优先编写和累积,测试应该可以基本覆盖全部的客户和开发需求,
    因此开发人员和客户可以得到尽可能充足的反馈。

    •  重整和优化 (Refactoring)

    XP强调简单的设计,但简单的设计并不是没有设计的流水帐式的程序,也不是没有结构、缺乏重用性的
    程序设计。开发人员虽然对每个USER STORY都进行简单设计,但同时也在不断地对设计进行改进,这个
    过程叫设计的重整和优化(Refactoring)。这个名字最早出现在Martin Fowler写的《Refactoring: 
    Improving the Design of Existing Code》这本书中。

    Refactoring主要是努力减少程序和设计中重复出现的部分,增强程序和设计的可重用性。Refactoring
    的概念并不是XP首创的,它已经被提出了近30年了,而且一直被认为是高质量的代码的特点之一。但XP
    强调,把Refactoring做到极致,应该随时随地、尽可能地进行Refactoring,只要有可能,程序员都不
    应该心疼以前写的程序,而要毫不留情地改进程序。当然,每次改动后,程序员都应该运行测试程序,
    保证新系统仍然符合预定的要求。

    4 频繁地整合,集体拥有代码(Collective Code Ownership),编程规范

    XP开发小组经常整合不同的模块。为了提高软件质量,除了测试驱动开发和Pair Programming以外,XP
    要求每个人的代码都要遵守编程规范,任何人都可以修改其他人写的代码,而且所有人都应该主动检查
    其他人写的代码。

    •  频繁地整合 (Integration )

    在很多项目中,开发人员往往很迟才把各个模块整合在一起。在这些项目中,开发人员经常在整合过程
    中发现很多问题,但不能肯定到底是谁的程序出了问题;而且,只有整合完成后,开发人员才开始稍稍
    使用整个系统,然后就马上交付给客户验收。对于客户来说,即使这些系统能够通过终验收测试,因为
    使用时间短,客户门心里并没有多少把握。

    为了解决这些问题,XP提出,整个项目过程中,应该频繁地,尽可能地整合已经开发完的USER STORY
    (每次整合一个新的USER STORY)。每次整合,都要运行相应的单元测试和验收测试,保证符合客户和
    开发的要求。整合后,就发布一个新的应用系统。这样,整个项目开发过程中,几乎每隔一两天,都会
    发布一个新系统,有时甚至会一天发布好几个版本。通过这个过程,客户能非常清楚地掌握已经完成的
    功能和开发进度,并基于这些情况和开发人员进行有效地、及时地交流,以确保项目顺利完成。

    •  集体拥有代码(Collective Code Ownership)

    在很多项目开发过程中,开发人员只维护自己的代码,而且很多人不喜欢其他人随意修改自己的代码。
    因此,即使可能有相应的比较详细的开发文档,但一个程序员却很少、也不太愿意去读其他程序员的代
    码;而且,因为不清楚其他人的程序到底实现了什么功能,一个程序员一般也不敢随便改动其他人的代
    码。同时,因为是自己维护自己的代码,可能因为时间紧张或技术水平的局限性,某些问题一直不能被
    发现或得到比较好的解决。针对这点,XP提倡大家共同拥有代码,每个人都有权利和义务阅读其他代
    码,发现和纠正错误,重整和优化代码。这样,这些代码就不仅仅是一两个人写的,而是由整个项目开
    发队伍共同完成的,错误会减少很多,重用性会尽可能地得到提高,代码质量是非常好。

    为了防止修改其他人的代码而引起系统崩溃,每个人在修改后都应该运行测试程序。(从这点,我们可
    以再次看到,XP的各个惯例和规则是怎样有机地结合在一起的。)

    •  编程规范

    XP开发小组中的所有人都遵循一个统一的编程标准,因此,所有的代码看起来好像是一个人写的。因为
    有了统一的编程规范,每个程序员更加容易读懂其他人写的代码,这是是实现Collective Code 
    Ownership的重要前提之一。

    5 Metaphor(系统比喻),不加班

    XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的,因
    为这说明关于项目进度的估计和安排有问题。 

    •  Metaphor(系统比喻)

    为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能,XP开发小组用很多形象的比喻
    来描述系统或功能模块是怎样工作的。比如,对于一个搜索引擎,它的Metaphor可能就是“一大群蜘
    蛛,在网上四处寻找要捕捉的东西,然后把东西带回巢穴。”

    •  不加班

    大量的加班意味着原来的计划是不准确的,或者是程序远不清楚自己到底什么时候能完成什么工作。而
    且,开发管理人员和客户也因此无法准确掌握开发速度;开发人员也因此非常疲劳。XP认为,如果出现
    大量的加班现象,开发管理人员(比如Coach)应该和客户一起确定加班的原因,并及时调整项目计
    划、进度和资源。

    XP中一些基本概念的简介

    User Story:开发人员要求客户把所有的需求写成一个个独立的小故事,每个只需要几天时间就可以完
    成。开发过程中,客户可以随时提出新的User Story,或者更改以前的User Story。

    Story Estimates和开发速度:开发小组对每个User Story进行估算,并根据每个开发周期
    (Iteration)中的实际情况反复计算开发速度。这样,开发人员和客户能知道每个星期到底能开发多
    少User Story。

    Release Plan和Release Scope:整个开发过程中,开发人员将不断地发布新版本。开发人员和客户一
    起确定每个发布所包含的User Story。

    Iteration(开发周期)和Iteration Plan:在一个Release过程中,开发人员要求客户选择最有价值的
    User Story作为未来一两个星期的开发内容。

    The Seed:第一个开发周期(Iteration)完成后,提交给客户的系统。虽然这不是最终的产品,但它
    已经实现了几个客户认为是最重要的Story,开发人员将逐步在其基础上增加新的模块。

    Continuous Integration(整合):把开发完的User Story的模块一个个拼装起来,一步步接近乃至最
    终完成最终产品。

    验收测试(功能测试):对于每个User Story,客户将定义一些测试案例,开发人员将使运行这些测试
    案例的过程自动化。

    Unit Test(单元测试):在开始写程序前,程序员针对大部分类的方法,先写出相应的测试程序。

    Refactoring (重整和优化) :去掉代码中的冗余部分,增加代码的可重用性和伸缩性。 



    小结

    XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终
    都能自信地面对客户需求的变化。XP强调团队合作,经理、客户和开发人员都是开发团队中的一员。团
    队通过相互之间的充分交流和合作,使用XP这种简单但有效的方式,努力开发出高质量的软件。XP的设
    计简单而高效;程序员们通过测试获得客户反馈,并根据变化修改代码和设计,他们总是争取尽可能早
    地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。

    XP很象一个由很多小块拼起来的智力拼图,单独看每一小块都没有什么意义,但拼装好后,一幅美丽的
    图画就会呈现在你面前。 

    展开全文
  • ExtremeProgramming(极限编程,简称XP)由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有效。Kent仔细地观察和分析了...

    ExtremeProgramming(极限编程,简称XP)是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月,Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。
    XP是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

    为什么称为“Extreme”(极限)

    “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目,其开发过程应该是平稳的、高效的和快速的,能够做到一周40小时工作制而不拖延项目进度。

    XP的软件开发是什么样

    1极限的工作环境

    为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务,XP要求把工作环境也做得最好。每个参加项目开发的人都将担任一个角色(项目经理、项目监督人等等)并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作,最好是所有人在同一个大房子中工作,还有茶点供应;每周40小时,不提倡加班;每天早晨,所有人一起站着开个短会;墙上有一些大白板,所有的Story卡、CRC卡等都贴在上面,讨论问题的时候可以在上面写写画画;下班后大家可以一起玩电脑游戏……。

    2极限的需求

    客户应该是项目开发队伍中的一员,而不是和开发人员分开的;因为从项目的计划到最后验收,客户一直起着很重要的作用。开发人员和客户一起,把各种需求变成一个个小的需求模块(UserStory),例如“计算年级的总人数,就是把该年级所有班的人数累加。”;这些模块又会根据实际情况被组合在一起或者被分解成更小的模块;它们都被记录在一些小卡片(StoryCard)上,之后分别被程序员们在各个小的周期开发中(Iteration,通常不超过3个星期)实现;客户根据每个模块的商业价值来指定它们的优先级;开发人员要做的是确定每个需求模块的开发风险,风险高的(通常是因为缺乏类似的经验)需求模块将被优先研究、探索和开发;经过开发人员和客户分别从不同的角度评估每个模块后,它们被安排在不同的开发周期里,客户将得到一个尽可能准确的开发计划;客户为每个需求模块指定验收测试(功能测试)。

    每发布一次开发的软件(经过一个开发周期),用户都能得到一个可以开始使用的系统,这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中,无论什么功能,用户都要等到所有开发完成后才能开始使用。

    3极限的设计

    从具体开发的角度来看,XP内层的过程是一个个基于测试驱动的开发(TestDrivenDevelopment)周期,诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试(UnitTest)。刚开始,因为什么都没有实现,所以所有的单元测试都是失败的;随着一个个小的需求模块的完成,通过的单元测试也越来越多。通过这种方式,客户和开发人员都很容易检验,是否履行了对客户的承诺。XP提倡对于简单的设计(SimpleDesign),就是用最简单的方式,使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式(BigDesignUpFront),因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计复核(Review)、代码复核以及重整和优化(Refectory),所有的这些过程其实也是优化设计的过程;在这些过程中不断运行单元测试和功能测试,可以保证经过重整和优化后的系统仍然符合所有需求。

    4极限的编程

    既然编程很重要,XP就提倡两个人一起写同一段程序(PairProgramming),而且代码所有权是归于整个开发队伍(CollectiveCodeOwnership)。程序员在写程序和重整优化程序的时候,都要严格遵守编程规范。任何人都可以修改其他人写的程序,修改后要确定新程序能通过单元测试。

    5极限的测试

    既然测试很重要,XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起(ContinuousIntegration),每次整合后都要运行单元测试;做任何的代码复核和修改,都要运行单元测试;发现了BUG,就要增加相应的测试(因此XP方法不需要BUG数据库)。除了单元测试之外,还有整合测试,功能测试、负荷测试和系统测试等。所有这些测试,是XP开发过程中最重要的文档之一,也是最终交付给用户的内容之一。


    XP中一些基本概念的简介

    UserStory:开发人员要求客户把所有的需求写成一个个独立的小故事,每个只需要几天时间就可以完成。开发过程中,客户可以随时提出新的UserStory,或者更改以前的UserStory。

    StoryEstimates和开发速度:开发小组对每个UserStory进行估算,并根据每个开发周期(Iteration)中的实际情况反复计算开发速度。这样,开发人员和客户能知道每个星期到底能开发多少UserStory。

    ReleasePlan和ReleaseScope:整个开发过程中,开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory。

    Iteration(开发周期)和IterationPlan:在一个Release过程中,开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。

    TheSeed:第一个开发周期(Iteration)完成后,提交给客户的系统。虽然这不是最终的产品,但它已经实现了几个客户认为是最重要的Story,开发人员将逐步在其基础上增加新的模块。

    ContinuousIntegration(整合):把开发完的UserStory的模块一个个拼装起来,一步步接近乃至最终完成最终产品。

    验收测试(功能测试):对于每个UserStory,客户将定义一些测试案例,开发人员将使运行这些测试案例的过程自动化。

    UnitTest(单元测试):在开始写程序前,程序员针对大部分类的方法,先写出相应的测试程序。

    Refactoring(重整和优化):去掉代码中的冗余部分,增加代码的可重用性和伸缩性。


    小结

    XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终都能自信地面对客户需求的变化。XP强调团队合作,经理、客户和开发人员都是开发团队中的一员。团队通过相互之间的充分交流和合作,使用XP这种简单但有效的方式,努力开发出高质量的软件。XP的设计简单而高效;程序员们通过测试获得客户反馈,并根据变化修改代码和设计,他们总是争取尽可能早地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。

    XP很象一个由很多小块拼起来的智力拼图,单独看每一小块都没有什么意义,但拼装好后,一幅美丽的图画就会呈现在你面前。

    什么时候来避免极限编程

    极限编程,有时也被叫做XP,已经被证明了是许多项目经理和项目程序员开发项目的成功的开发方法,具有很好的开发风格。但是它并不适用与所有的情况或所有的项目团体。如果你不考虑你的开发小组、开发部门或开发公司的情况,而去试图选择极限编程作为你的核心开发方法,这才是本末倒置。你应该确保你的开发单位是适用于这个极限编程开发方法的特殊需要的。

     
      

    在简单的团队中,极限编程把开发者而不是项目经理作为项目开发的核心人员,它选择使用开发人员来进行项目的决策。这个技术可以提高开发效率,也可以使管理接口的麻烦最小化,但是极限编程会给你带来你不曾有的问题,它爱管闲事,并缺乏有效的管理。另外,管理应该在合适的时候添加进来,如果不进行开发管理将对你的项目开发有害无益。

    -=====================================

    借口编程(Excuse Programming)。是的,这就是很多项目团队,尤其是项目经理们一直在做的事情。他们总是一直在给出一个又一个的借口。为没有很好地进行需求开发和需求管理找借口,为没有跟踪项目风险和项目问题并且系统化地、及时地解决它们找借口。

    最常见的借口就是时间,也就是没有时间。为什么会没有时间呢?因为时间都被浪费到做错误的事情上了,所以他们就需要加班。他们是在做片面的极限编程,或者,应该说是额外编程(Extra Programming),这是一个恶性循环,他们需要走出这个怪圈,让事情走上正轨。但屡见不鲜的情况是,项目经理往往过于自负,很难走出这个怪圈。他们总在给出一个又一个的借口,没有例外管理,而是借口管理。

    请注意:我们是支持极限编程XP的,但极限编程是适用于那些非常清楚自己在做什么的人。极限编程不适用于那些为了伪装他们所作所为的人,极限编程适合于专家,而不是冒牌货。极限编程不是借口编程,它不是一个用于你不做正确的事情的借口。

    从借口编程到极限编程
    我们认为每个开发人员、经理——每个软件开发社区的专业人士,都应该思考哪些是他们知道的,哪些是是他们不知道的,对自己和别人都应该绝对诚实。我们也应该十分认真和充满热情地提高我们的技能。除此之外,没有其他捷径,请不要再找借口了。

    所以让我们非常坦诚地面对问题。但人们(例如项目经理等)的问题往往是他们并不知道他们自身的问题。他们还没有意识到这一点。如果你试图说服他们意识到他们有问题,你会寻找出更多的问题。别忘了他们都是借口编程高手。你并没有看清所有的问题。所以,有时,人们从自身的错误中学习,有些人从不学习也会侥幸成功,有些人从不学习并重复地犯相同的错误。

    但是也有少数人会总是问自己:我如何才能做得比昨天更好?幸运地是,我们周边还有一些这样的人。当你给他们建议时,他们可能会反对,但当他们回到家里,冷静下来,开始思考,然后他们会回来找你。这些人还是有希望的。有希望的是,我们有越来越多这样的人。

    一旦借口编程被驯服,我们可以原谅他们的过去。一切都可以被原谅。我们可以开始教育他们正确的方式,常常地我们甚至可以从他们身上学到不少东西。有很多种方式来武装他们,他们可以阅读书籍等,他们也可以从导师那里寻找帮助,甚至是虚拟的导师。

    作为一个经理或客户,你总是需要以挑剔的眼光来选择谁来做你的项目,一个团队(尤其是她的领导)的选择是一个非常关键的要素。如果他们是专家那就最好了,否则,寻找那些有潜力的,并设计一种策略让他们以最快的速度前进——如何以最快的速度进行,这又是另一个话题。

     --------------------------------------

     敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

          敏捷开发是全新理论吗?答案莫衷一是。细心的人们可以发现,敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有更多。

          改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

    敏捷肯定是奔着软件本身去的。

    抛开软件本身谈过程,没有技术的积累去谈敏捷风格的项目管理,那都是扯谈。

    什么过程,设计,集成,测试都是以软件本身为主导的。

    适度的 unit test 用例,自动化构建/自动化测试,那是敏捷的外在表现。

    一个适度设计,持续改进的构思,是敏捷的精髓。最后把这些都反映到代码上,那就是一个敏捷的实施了。

    如果能够围绕这些构造一个良好的技术讨论氛围,互助的精神,那就实现了敏捷的胜利以及价值了。

    对不懂代码,没有做过编程的人,关于敏捷,我们没什么好谈的

    敏捷开发有什么缺点?
      
    1、敏捷开发以人为本,对PM的要求比较高,管人是需要一些艺术的.PM如果控制不好,整个项目的风险会比较大!

    2、敏捷开发在平衡过程中,必然会对某些方面带来忽略,容易在这些方面出现问题

    3、敏捷开发对团队成员要求很高,水平不能相差太远,否则节奏不好控制
     


    参考来源:

    http://tech.acnow.net/Html/Program/soft_project/SoftMethod/2005-8/7/230147673.shtml

    http://hi.baidu.com/mayig/blog/item/dbf2f81f0c093ef5e0fe0b58.html

    http://zhidao.baidu.com/question/5153690.html

     

    本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/lovingprince/archive/2007/04/25/1584258.aspx

    展开全文
  • 什么是xp(极限编程)

    2010-11-19 21:12:37
    极限编程简介 What is Extreme Programming? 什么是极端编程? Ron Jeffries 11/08/2001 翻译: xlp223 2001/12/06
  • 什么是极限编程

    千次阅读 2008-12-27 18:29:00
    极限编程(XP,eXtreme Programming)一种软件工程方法学,敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者...
     
    

    极限编程(XP,eXtreme Programming)是一种软件工程方法学,是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象,是软件项目开发中不可避免的、也是应该欣然接受的现象;他们相信,和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比,有能力在项目周期的任何阶段去适应变化,将是更加现实更加有效的方法。

    XP为管理人员和开发人员开出了一剂指导日常实践的良方;这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信,这些在传统的软件工程中看来是“极端的”实践,将会使开发过程比传统方法更加好的响应用户需求,因此更加敏捷,更好的构建出高质量软件。

    历史

    极限编程的创始者是肯特·贝克(Kent Beck)、沃德·坎宁安( Ward Cunningham)和罗恩·杰弗里斯(Ron Jeffries),他们在为克莱斯勒综合报酬系统(Chrysler Comprehensive Compensation System )(C3) 的薪水册项目工作时提出了极限编程方法。Kent Beck在1996年3月成为C3的项目负责人,开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书,并且于1999年10月将之发行,这就是《极限编程解析》(2005第二版出版)。克莱斯勒在2000年2月取消了实质上并未成功的C3项目,但是这个方法学却一直流行在软件工程领域中。至今2006年,很多软件开发项目都一直以极限编程做为他们的指导方法学。

    该书阐述了如下的极致编程的哲学思想 :

    一种社会性的变化机制
    一种开发模式
    一种改进的方法
    一种协调生产率和人性的尝试
    一种软件开发方法
    把极致编程一般化并用于其它型别的专案称为极致专案管理。

     未来的方向

    极限编程的推广之一为把不同的敏捷软件实践和传统实践节奏地结合起来,弹性地合用于不同企业开发环境。这就是软件开发节奏(Software Development Rhythms)的中心思想

    XP的目标

    极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中(如SDM),系统需求是在专案开发的开始阶段就确定下来,并在之后的开发过程中保持不变的。这意味着专案开发进入到之后的阶段时出现的需求变更—而这样的需求变更在一些发展极快的领域中是不可避免的—将导致开发成本急速增加。这一概念可以用下图来表示:

    Image:Costofchange.jpg

    极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发专案在应对需求变更时将显得更为灵活。下图展示了这一降低变更成本的目的:

    Image:Costofchangexp.jpg

    XP 核心的实践

    极致编程实践作业的核心,正如 Extreme programming explained 所描述的,可以被区分为以下四个范围(12个实践作业):

    小规模回馈

    反覆性程序而不是批量的

    • 持续整合
    • 设计最佳化(原名:软件重构
    • 小型发布

    共同认识(共识)

    • 简单的设计
    • 系统隐喻
    • 集体程式码所有
    • 程式设计标准/程式设计规约

    程式设计师的利益

    • 恒定速路
    • 可反覆性速率(原名:每周40小时)

     

    在第二版的Extreme programming explained中,在主要实践之外,还列出了一系列延伸的实践。

    核心实践源自被广泛接受的最佳实践,并且被推向极至:

    开发人员和客户之间的交互是有益的. 因此,一个极致编程的小组从理论上要求需要一个软件使用者在身边,这个使用者制定软件的工作需求和优先等级, 并且尽可能在各种问题出现的时候马上就能回答(实际工作中,这个角色是由客户代理商完成的).
    如果学习是好的, 那么就把它做到底: 这样减少了开发和回馈周期的长度,测试也能更早完成.
    简单的代码更可能工作。所以极致编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码,这样或多或少降低了代码的复杂性和重复性.
    如果简单的代码是好的, 那么把变得复杂的代码改写成简单的.
    代码评审是好的。因此,极致编程的程序设计师以两人搭档的方式工作. 他们共享一个屏幕和键盘,增加了队员之间的交流,也让代码在一被写出的时候就被人评审了.
    测试代码是好的。因此,在极致编程中,测试用例在实际代码之前就被写出来了. 代码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软件系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.
    一般来说,极致编程被认为对于少于12人的小团队很有用。一些人认为极致编程可以用于大的团队,但是其它人认为统一软件程序更适合大的团队。然而,极致编程在一些超过100人的开发小组中获得成功. 并不是极致编程不能够推广到更大的团队,而是很少有更大的团队来试著用它. 极致编程的人员也拒绝去随便推测这个问题.

     XP的价值
    最初,极限编程技术只提出了四条价值标准,而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准:

    沟通
    简单
    回馈
    勇气
    尊重(最新添加的价值)

     软件重构
    构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中,这一任务是通过文档来完成的。

    极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角,而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标,极限编程支持设计、抽象、还有用户-程序员间交流的简单化,鼓励经常性的口头交流与反馈。


     简单
    极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于,它只关注于对当前的需求来进行设计、编码,而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的,即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点,因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看,设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。


     反馈
    在极限编程中,“反馈”是和系统开发的很多不同方面相关联的:

    来自系统的反馈:通过编写单元测试,程序员能够很直观的得到经过修改后系统的状态。
    来自客户的反馈:功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次,这样客户可以非常容易的了解、掌控开发的进度。
    来自小组的反馈:当客户带着新需求来参加项目计划会议时,小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。
    反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷,可以通过编写单元测试,简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据,对系统进行周期性的测试。用Kent Beck的话来说:“编程中的乐观主义是危险的,而及时反馈则是解决它的方法。”


     勇气
    极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码,不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历:他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得,而第二天回来以一个全新而清醒的角度来考虑,在半小时内就轻松解决了问题。


     尊重
    尊重的价值体现在很多方面。在极限编程中,团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量,坚持通过重构的手段来为手头的工作找到最好的解决设计方案。


     原则
    组成极限编程基础的原则,正是基于上面描述的那几条价值。在系统开发项目中,这些原则被用来为决策做出指导。与价值相比,原则被描述的更加具体化,以便在实际应用中更为简单的转变为具体的指导意见。


     快速反馈
    当反馈能做到及时、迅速,将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间,一般被用来掌握新情况以及做出修改。与传统开发方法不同,与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他/她能够在整个开发过程中及时给出反馈意见,并且在需要的时候能够掌控系统的开发方向。

    单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中,应需求变更而做出修改的系统将出现怎样的反应,正是通过单元测试来给出直接反馈的。比如,某个程序员对系统中的一部分代码进行了修改,而假如这样的修改影响到了系统中的另一部分(超出了这个程序员的可控范围),则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。


     假设简单
    假设简单认为任何问题都可以"极度简单"的解决。传统的系统开发方法要考虑未来的变化,要考虑程序码的可重用性。极致编程拒绝这样作。


     增量变化
    极限编程的提倡者总是说:罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说,可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式,使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。


     包容变化
    可以肯定地是,不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度,而应该包容它们。比如,在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员,必须包容这些变化,并且拟定计划使得下一个阶段的产品能够满足新的需求。


     活动
    XP 描述了在软件开发过程中四种基本的行为。 XP describes four basic activities that are performed within the software development process.


     编码
    XP的提倡者争辩说在系统开发过程的产物中真正重要的只有编码


     软件测试
    没有经过测试的程序码什么都不是。如果你没有测试,客户可能感觉不到,很多软件在发布的时候没有经过完整的测试,它们还都在工作(或多或少的工作)。 在软件开发程序中,极致编程认为,如果一个函数没有经过测试就不能认为它可以工作。


     实践

     策划游戏
    在极致编程中主要的策划程序称为策划游戏。 本节将通过程序模型介绍这个程序。

    策划程序分为两部分:

    发布策划:
    反覆状态:
    Image:Planninggame.gif


     送出状态 – 发布计划
    这一阶段涉及成本、利润和计划影响这三个因素,包含四个部分:

    按照价值排序:业务方按照商业价值为使用者故事排序。
    按风险排序:开发方按风险为使用者故事排序。
    设定周转率:开发方决定以怎样的速度开展专案。
    选择范围:挑选在下一个发布中需要被完成的使用者故事,基于使用者故事决定发布日期。

     价值排序
    业务方按照商业价值为使用者故事排序。它们会被分为三类:

    关键:没有这些故事系统无法运作或变得毫无意义。
    重要的商业价值:有重要业务价值的非关键使用者故事。
    最好能有:并没有重要商业价值的使用者故事;例如在可用性或使用者界面上的改进。

     风险排序
    程序设计师按照风险对使用者故事进行排序。他/她们将使用者故事的风险划分成三类:低、中、高。以下是这种方式的一个范例:

    决定风险索引:依照以下因素给每个使用者故事一个0到2的索引:
    完全度(我们是否已经了解所有的故事细节?)
    完全(0)
    不完全(1)
    未知(2)
    发散性(可能会发生变化吗?)
    低(0)
    中(1)
    高(2)
    复杂度(是否难以建构?)
    简单(0)
    标准(1)
    复杂(2)
    为每个使用者故事增加所有这些索引后,给这些使用者故事指定一个风险索引:低(0–1),中(2–4),高(5–6)。


    激励状态 – 发布计划
    在作业阶段开发人员和业务人员可以“操纵”整个程序。这意味着,他们可以做出改变。个体的使用者故事,或是不同使用者故事的相对优先等级,都有可能改变;预估时间也可能出现误差。这是做出相应调整的机会。


    探索阶段- 反覆计划
    反覆计划中的探索阶段是关于建立任务和预估实施时间。

    收集使用者故事:收集并编辑下一个发布的所有使用者故事。
    组合/分割任务:如果程序设计师因为任务太大或太小而不能预估任务完成时间,则需要组合或分割此任务。
    预估任务:预测需要实作此任务的时间。

    约定阶段 - 反覆计划
    在反覆计划的约定阶段以不同使用者故事作为参考的任务被指派到程序设计师。

    程序设计师接受任务:每个程序设计师都挑选一个他/她负责的任务。
    程序设计师预估任务:由于程序设计师对此任务负责,他/她必须给出一个完成任务的估计时间。
    设定负载系数:负载系数表示每个程序设计师在一个反覆中理想的开发时间。比如:一周工作40小时,其中5小时用于开会,则负载系数不会超过35小时。
    平衡:当团队中所有程序设计师都已经被配置了任务,便会在预估时间和负载系数间做出比较。任务配置在程序设计师中达到平衡。如果有一个程序设计师的开发任务过重,其它程序设计师必须接手他/她的一部分任务,反之亦然。

    作业阶段 - 反覆计划
    各个任务是在反覆计划的作业阶段中一步步实作的。

    取得一张任务卡片:程序设计师取得一张由他/她负责的任务的卡片。
    找寻一名同伴:这个程序设计师将和另一位程序设计师一同完成开发工作。这在实施结队程序设计中会做更深入的探讨。
    设计这个任务:如果需要,两位程序设计师会设计这个任务所达成的功能。
    编辑单元测试:在程序设计师开始编辑实作功能的程序码之前,他/她们首先编辑自动测试。这在实施单元测试中会做更深入的探讨。
    编辑程序码:两位程序设计师开始编辑程序码。
    执行测试:执行单元测试来确定程序码能正常工作。
    执行功能测试:执行功能测试(基于相关使用者故事和任务卡片中的需求)。

    结对程序设计
    结对程序设计的意思是所有的程序码都是由两个人坐在一台电脑前一起完成的。一个程序设计师控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构,不断的对第一个程序设计师写的程序码进行评审。

    结对不是固定的: 我们甚至建议程序设计师尽量交叉结对。这样,每个人都可以知道其它人的工作,每个人都对整个系统熟悉,结对程序设计加强了团队内的沟通。 (这与程序码集体所有制是息息相关的).


    集体所有制
    集体所有制意味着每个人都对所有的程序码负责;这一点,反过来又意味着每个人都可以更改程序码的任意部分。结队程序设计对这一实践贡献良多:借由在不同的结队中工作,所有的程序设计师都能看到完全的程序码。集体所有制的一个主要优势是提升了开发程序的速度,因为一旦程序码中出现错误,任何程序设计师都能修正它。

    在给予每个开发人员修改程序码的权限的情况下,可能存在程序设计师引入错误的风险,他/她们知道自己在做什么,却无法预见某些依赖关系。完善的单元测试可以解决这个问题:如果未被预见的依赖产生了错误,那么当单元测试执行时,它必定会失败。

     现场客户
    在极致编程中,“客户”并不是为系统付帐的人,而是真正使用该系统的人。极致编程认为客户应该时刻在现场解决问题。例如:在团队开发一个财务管理系统时,开发小组内应包含一位财务管理人员。


     单元测试
    单元测试是用以测试一小段程序码的自动测试(例如:类,方法)。在极致编程中,在程序码编辑前就编辑单元测试。这种方式的目的是激励程序设计师设想他/她的程序码在何种条件下会出错。极致编程认为当程序设计师无法再想出更多能使他/她的程序码出错的情况时,这些程序码便算完成。


     重构
    由于XP教条提倡编辑程序时只满足目前的需求,并且以尽可能简单的方式实作。有时会碰上一套僵硬的系统,所谓僵硬的系统,表现之一是需要双重(或多重)维护:功能变化需要对多份同样(或类似)的程序码进行修改;另一种表现是对程序码的一部分进行修改时会影响其它很多部分。XP教条认为当这种情况发生时,意味着系统正告诉你通过改变系统架构以重构程序码,使它更简单、更泛用。参见重构。

    极致编程的特征
    极致编程方法的基本特征是:

    增量和反覆式的开发 - 一次小的改进跟着一个小的改进。
    反覆性,通常是自动重复的单元测试,回归测试。参见JUnit。
    结对程序设计
    在程序设计团队中的使用者交互(在场的客户)
    软件重构
    共享的程序码所有权
    简单
    回馈
    用隐喻来组织系统
    可以忍受的速度
    这些内容属性来源于那些被认为是有效的原则,并把它们发挥到极致:

    开发人员和客户之间的交互是有益的. 因此,一个极致编程的小组从理论上要求需要一个软件使用者在身边,这个使用者制定软件的工作需求和优先等级, 并且尽可能在各种问题出现的时候马上就能回答.
    如果学习是好的, 那么就把它做到底: 这样减少了开发和回馈周期的长度,测试也能更早完成.
    简单的程序码更可能工作。所以极致编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的程序码,这样或多或少降低了程序码的复杂性和重复性.
    如果简单的程序码是好的, 那么把变得复杂的程序码改写成简单的.
    程序码评审是好的。因此,极致编程的程序设计师以两人搭档的方式工作. 他们共享一个屏幕和键盘,增加了队员之间的交流,也让程序码在一被写出的时候就被人评审了.
    测试程序码是好的。因此,在极致编程中,测试用例在实际程序码之前就被写出来了. 程序码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软件系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.
    一般来说,极致编程被认为对于少于12人的小团队很有用。一些人认为极致编程可以用于大的团队,但是其它人认为统一软件程序更适合大的团队。然而,极致编程在一些超过100人的开发小组中获得成功. 并不是极致编程不能够推广到更大的团队,而是很少有更大的团队来试着用它. 极致编程的人员也拒绝去随便推测这个问题.


    争论的观点
    极致编程也有其被争论的一面:

    没有书面的详细的规格说明书
    客户代表被安排在专案中
    程序设计师以结对的方式工作
    测试驱动的开发
    绝大多数设计活动都匆匆而过,并渐进式的,开始一个“最简单的可能工作的东西”并当其需要时(测试失败)才增加复杂性。单元测试促成为了设计纪律。


    极致编程中的沟通
    建构软件系统的一个基本任务是向系统的开发人员传达系统的需求。在形式的软件开发方法学中,沟通是通过文件完成的。

    极致编程方法可以被看作为在开发团队成员间快速建构和散布统一的知识的一种方法。目的在于给所有开发人员一个共享的关于系统的看法,这个看法与使用者持有的看法相一致。为了这个目的,极致编程热衷于简单的设计,隐喻,使用者与程序设计师之间的合作,频繁的口头沟通和回馈。

    展开全文
  • 什么是xp极限编程

    2009-11-04 08:53:00
    历史:ExtremeProgramming(极限编程,简称XP)由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有效。Kent仔细地观察和...

          历史:ExtremeProgramming(极限编程,简称XP)是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时,就一直共同探索着新的软件开发方法,希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月,Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。
          特点:XP是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。
    什么是软件开发

    软件开发的内容是:需求、设计、编程和测试

    需求:不仅仅是用户需求,应该是开发中遇到的所有的需求。比如,你首先要知道做这个项目是为了解决什么问题;测试案例中应该输入什么数据……为了清楚地知道这些需求,你经常要和客户、项目经理等交流。

    设计:编码前,肯定有个计划告诉你要做什么,结构是怎样等等。你一定要按照这个来做,否则可能会一团糟。

    编程:如果在项目截止日,你的程序不能跑起来或达不到客户的要求,你就拿不到钱。

    测试:目的是让你知道,什么时候算是完成了。如果你聪明,你就应该先写测试,这样可以及时知道你是否真地完成了。否则,你经常会不知道,到底有哪些功能是真正完成了,离预期目标还差多远。

    软件开发中,客户和开发人员都有自己的基本权利和义务。
    客户:
    定义每个用户需求的商业优先级;
    制订总体计划,包括用多少投资、经过多长时间、达到什么目的;
    在项目开发过程中的每个工作周,都能让投资获得最大的收益;
    通过重复运行你所指定的功能测试,准确地掌握项目进展情况;
    能随时改变需求、功能或优先级,同时避免昂贵的再投资;能够根据各种变化及时调整项目计划;
    能够随时取消项目;项目取消时,以前的开发工作不是一堆垃圾,已开发完的功能是合乎要求的,正在进行或未完成的的工作则应该是不难接手的。

    开发人员:
    知道要做什么,以及要优先做什么;
    工作有效率;
    有问题或困难时,能得到客户、同事、上级的回答或帮助;
    对工作做评估,并根据周围情况的变化及时重新评估;
    积极承担工作,而不是消极接受分配;
    一周40小时工作制,不加班。

    这就是软件开发,除此之外再还有其它要关心的问题!


    灵巧的轻量级软件开发方法

         一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规则、流程和相关的文档工作。灵巧的轻量级开发方法,其规则和文档相对较少,流程更加灵活,实施起来相对较容易。

          在软件工程概念出现以前,程序员们按照自己喜欢的方式开发软件。程序的质量很难控制,调试程序很繁琐,程序员之间也很难读懂对方写的代码。1968年,EdsgerDijkstra给CACM写了一封题为GOTOStatementConsideredHarmful的信,软件工程的概念由此诞生。程序员们开始摒弃以前的做法,转而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格,人们陆续制定了很多规则和做法,发明了很多软件工程方法,软件质量开始得到大幅度提高。随着遇到的问题更多,规则和流程也越来越精细和复杂。

          到了今天,在实际开发过程中,很多规则已经难于遵循,很多流程复杂而难于理解,很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案,或者寄希望于更复杂的、功能更强大的辅助开发工具(CaseTools),但总是不能成功,而且开发规范和流程变得越来越复杂和难以实施。

         为了赶进度,程序员们经常跳过一些指定的流程,很少人能全面遵循那些重量级开发方法。

         失败的原因很简单,这个世界没有万能药。因此,一些人提出,将重量级开发方法中的规则和流程进行删减、重整和优化,这样就产生了很多适应不同需要的轻量级流程。在这些流程中,合乎实际需要的规则被保留下来,不必要的复杂化开发的规被抛弃。而且,和传统的开发方法相比,轻量级流程不再象流水生产线,而是更加灵活。

         ExtremeProgramming(XP)就是这样一种灵巧的轻量级软件开发方法。


    为什么称为“Extreme”(极限)

        “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目,其开发过程应该是平稳的、高效的和快速的,能够做到一周40小时工作制而不拖延项目进度。

    XP的软件开发是什么样

    1极限的工作环境

          为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务,XP要求把工作环境也做得最好。每个参加项目开发的人都将担任一个角色(项目经理、项目监督人等等)并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作,最好是所有人在同一个大房子中工作,还有茶点供应;每周40小时,不提倡加班;每天早晨,所有人一起站着开个短会;墙上有一些大白板,所有的Story卡、CRC卡等都贴在上面,讨论问题的时候可以在上面写写画画;下班后大家可以一起玩电脑游戏……。

    2极限的需求

          客户应该是项目开发队伍中的一员,而不是和开发人员分开的;因为从项目的计划到最后验收,客户一直起着很重要的作用。开发人员和客户一起,把各种需求变成一个个小的需求模块(UserStory),例如“计算年级的总人数,就是把该年级所有班的人数累加。”;这些模块又会根据实际情况被组合在一起或者被分解成更小的模块;它们都被记录在一些小卡片(StoryCard)上,之后分别被程序员们在各个小的周期开发中(Iteration,通常不超过3个星期)实现;客户根据每个模块的商业价值来指定它们的优先级;开发人员要做的是确定每个需求模块的开发风险,风险高的(通常是因为缺乏类似的经验)需求模块将被优先研究、探索和开发;经过开发人员和客户分别从不同的角度评估每个模块后,它们被安排在不同的开发周期里,客户将得到一个尽可能准确的开发计划;客户为每个需求模块指定验收测试(功能测试)。

          每发布一次开发的软件(经过一个开发周期),用户都能得到一个可以开始使用的系统,这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中,无论什么功能,用户都要等到所有开发完成后才能开始使用。

    3极限的设计

          从具体开发的角度来看,XP内层的过程是一个个基于测试驱动的开发(TestDrivenDevelopment)周期,诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试(UnitTest)。刚开始,因为什么都没有实现,所以所有的单元测试都是失败的;随着一个个小的需求模块的完成,通过的单元测试也越来越多。通过这种方式,客户和开发人员都很容易检验,是否履行了对客户的承诺。XP提倡对于简单的设计(SimpleDesign),就是用最简单的方式,使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式(BigDesignUpFront),因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计复核(Review)、代码复核以及重整和优化(Refectory),所有的这些过程其实也是优化设计的过程;在这些过程中不断运行单元测试和功能测试,可以保证经过重整和优化后的系统仍然符合所有需求。

    4极限的编程

         既然编程很重要,XP就提倡两个人一起写同一段程序(PairProgramming),而且代码所有权是归于整个开发队伍(CollectiveCodeOwnership)。程序员在写程序和重整优化程序的时候,都要严格遵守编程规范。任何人都可以修改其他人写的程序,修改后要确定新程序能通过单元测试。

    5极限的测试

        既然测试很重要,XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起(ContinuousIntegration),每次整合后都要运行单元测试;做任何的代码复核和修改,都要运行单元测试;发现了BUG,就要增加相应的测试(因此XP方法不需要BUG数据库)。除了单元测试之外,还有整合测试,功能测试、负荷测试和系统测试等。所有这些测试,是XP开发过程中最重要的文档之一,也是最终交付给用户的内容之一。


    XP中的重要惯例和规则

    1项目开发小组(Team)

         在XP中,每个对项目做贡献的人都应该是项目开发小组中的一员。而且,这个小组中必须至少有一个人对用户需求非常清晰,能够提出需求、决定各个需求的商业价值(优先级)、根据需求等的变化调整项目计划等。这个人扮演的是“客户”这个角色,当然最好就是实际的最终用户,因为整个项目就是围绕最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员,他们帮助客户制订验收测试;有分析员,帮助客户确定需求;通常还有个Coach(教练),负责跟踪开发进度、解决开发中遇到的一些问题、推动项目进行;还可以又一个项目经理,负责调配资源、协助项目内外的交流沟通等等。项目小组中有这么多角色,但并不是说,每个人做的工作是别人不能插手或干预的,XP鼓励每个人尽可能地为项目多做贡献。平等相处,取长补短;这就是最好的XP开发小组。

    2计划项目(PlanningGame)、验收测试、小规模发布(SmallReleases)

           XP开发小组使用简单的方式进行项目计划和开发跟踪,并以次预测项目进展情况和决定未来的步骤。根据需求的商业价值,开发小组针对一组组的需求进行一系列的开发和整合,每次开发都会产生一个通过测试的、可以使用的系统。

    计划项目

           XP的计划过程主要针对软件开发中的两个问题:预测在交付日期前可以完成多少工作;现在和下一步该做些什么。不断的回答这两个问题,就是直接服务于如何实施及调整开发过程;与此相比,希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间,则事倍功半。针对这两个问题,XP中又两个主要的相应过程:

           软件发布计划(ReleasePlanning)。客户阐述需求,开发人员估算开发成本和风险。客户根据开发成本、风险和每个需求的重要性,制订一个大致的项目计划。最初的项目计划没有必要(也没有可能)非常准确,因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且,这个计划会在实施过程中被不断地调整以趋精确。 

           周期开发计划(IterationPlanning)。开发过程中,应该有很多阶段计划(比如每三个星期一个计划)。开发人员可能在某个周期对系统进行内部的重整和优化(代码和设计),而在某个周期增加了新功能,或者会在一个周期内同时做两方面的工作。但是,经过每个开发周期,用户都应该能得到一个已经实现了一些功能的系统。而且,每经过一个周期,客户就会再提出确定下一个周期要完成的需求。在每个开发周期中,开发人员会把需求分解成一个个很小的任务,然后估计每个任务的开发成本和风险。这些估算是基于实际开发经验的,项目做得多了,估算自然更加准确和精确;在同一个项目中,每经过一个开发周期,下一次的估算都会有更过的经验、参照和依据,从而更加准确。这些简单的步骤对客户提供了丰富的、足够的信息,使之能灵活有效地调控开发进程。每过两三个星期,客户总能够实实在在地看到开发人员已经完成的需求。在XP里,没有什么“快要完成了”、“完成了90%”的模糊说法,要不是完成了,要不就是没完成。这种做法看起来好象有利有弊:好处是客户可以马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等;坏处是客户看到做出来的东西,可能会很不满意甚至中止合同。实际上,XP的这种做法是为了及早发现问题、解决问题,而不是等到过了几个月,用户终于看到开发完的系统了,然后才告诉你这个不行、那个变了、还要增加
    哪个内容等等。

    验收测试

          客户对每个需求都定义了一些验收测试。通过运行验收测试,开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间,最好能将这些测试过程自动化。

    频繁地小规模发布软件(SmallReleases)

         每个周期(Iteration)开发的需求都是用户最需要的东西。在XP中,对于每个周期完成时发布的系统,用户都应该可以很容易地进行评估,或者已经能够投入实际使用。这样,软件开发对于客户来说,不再是看不见摸不着的东西,而是实实在在的。XP要求频繁地发布软件,如果有可能,应该每天都发布一个新版本;而且在完成任何一个改动、整合或者新需求后,就应该立即发布一个新版本。这些版本的一致性和可靠性,是靠验收测试和测试驱动的开发来保证的。

    3简单设计,PairProgramming,测试驱动开发,重整和优化

         XP程序员不但做为一个开发小组共同工作,还以两个人为一个小开发单元编写同一个程序。开发人员们进行简单的设计,编写单元测试后再编写符合测试要求的代码,并在满足需求的前提下不断地优化设计。

    简单设计 

         XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个小需求,前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了,不需要任何画蛇添足的设计,而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

         在XP中,没有那种传统开发模式中一次性的、针对所有需求的总体设计。在XP中,设计过程几乎一直贯穿着整个项目开发:从制订项目的计划,到制订每个开发周期(Iteration)的计划,到针对每个需求模块的简捷设计,到设计的复核,以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看,XP是把设计做到了极致。

    PairProgramming

         XP中,所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过,代码、设计和测试的质量因此得到提高。看起来这样象是在浪费人力资源,但是各种研究表明事实恰恰相反。——这种工作方式极大地提高了工作强度和工作效率。 

         很多程序员一开始是被迫尝试这点的(XP也需要行政命令的支持)。开始时总是不习惯的,而且两个人的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统计,在所有刚开始PairProgramming的程序员中,90%的人在两个月以后都很认为这种工作方式更加高效。

         项目开发中,每个人会不断地更换合作编程的伙伴。因此,PairProgramming不但提高了软件质量,还增强了相互之间的知识交流和更新,增强了相互之间的沟通和理解。这不但有利于个人,也有利于整个项目、开发队伍和公司。从这点看,PairProgramming不仅仅适用于XP,也适用于所有其它的软件开发方法。

    测试驱动开发

         反馈是XP的四个基本的价值观之一——在软件开发中,只有通过充分的测试才能获得充分的反馈。XP中提出的测试,在其它软件开发方法中都可以见到,比如功能测试、单元测试、系统测试和负荷测试等;与众不同的是,XP将测试结合到它独特的螺旋式增量型开发过程中,测试随着项目的进展而不断积累。另外,由于强调整个开发小组拥有代码,测试也是由大家共同维护的。即,任何人在往代码库中放程序(CheckIn)前,都应该运行一遍所有的测试;任何人如果发现了一个BUG,都应该立即为这个BUG增加一个测试,而不是等待写那个程序的人来完成;任何人接手其他人的任务,或者修改其他人的代码和设计,改动完以后如果能通过所有测试,就证明他的工作没有破坏愿系统。这样,测试才能真正起到帮助获得反馈的作用;而且,通过不断地优先编写和累积,测试应该可以基本覆盖全部的客户和开发需求,因此开发人员和客户可以得到尽可能充足的反馈。

    重整和优化(Refactoring)

         XP强调简单的设计,但简单的设计并不是没有设计的流水帐式的程序,也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个USERSTORY都进行简单设计,但同时也在不断地对设计进行改进,这个过程叫设计的重整和优化(Refactoring)。这个名字最早出现在MartinFowler写的《Refactoring:ImprovingtheDesignofExistingCode》这本书中。

          Refactoring主要是努力减少程序和设计中重复出现的部分,增强程序和设计的可重用性。Refactoring的概念并不是XP首创的,它已经被提出了近30年了,而且一直被认为是高质量的代码的特点之一。但XP强调,把Refactoring做到极致,应该随时随地、尽可能地进行Refactoring,只要有可能,程序员都不应该心疼以前写的程序,而要毫不留情地改进程序。当然,每次改动后,程序员都应该运行测试程序,保证新系统仍然符合预定的要求。

    4频繁地整合,集体拥有代码(CollectiveCodeOwnership),编程规范

         XP开发小组经常整合不同的模块。为了提高软件质量,除了测试驱动开发和PairProgramming以外,XP要求每个人的代码都要遵守编程规范,任何人都可以修改其他人写的代码,而且所有人都应该主动检查其他人写的代码。

    频繁地整合(Integration)

          在很多项目中,开发人员往往很迟才把各个模块整合在一起。在这些项目中,开发人员经常在整合过程中发现很多问题,但不能肯定到底是谁的程序出了问题;而且,只有整合完成后,开发人员才开始稍稍使用整个系统,然后就马上交付给客户验收。对于客户来说,即使这些系统能够通过终验收测试,因为使用时间短,客户门心里并没有多少把握。

         为了解决这些问题,XP提出,整个项目过程中,应该频繁地,尽可能地整合已经开发完的USERSTORY(每次整合一个新的USERSTORY)。每次整合,都要运行相应的单元测试和验收测试,保证符合客户和开发的要求。整合后,就发布一个新的应用系统。这样,整个项目开发过程中,几乎每隔一两天,都会发布一个新系统,有时甚至会一天发布好几个版本。通过这个过程,客户能非常清楚地掌握已经完成的功能和开发进度,并基于这些情况和开发人员进行有效地、及时地交流,以确保项目顺利完成。

    集体拥有代码(CollectiveCodeOwnership)

          在很多项目开发过程中,开发人员只维护自己的代码,而且很多人不喜欢其他人随意修改自己的代码。因此,即使可能有相应的比较详细的开发文档,但一个程序员却很少、也不太愿意去读其他程序员的代码;而且,因为不清楚其他人的程序到底实现了什么功能,一个程序员一般也不敢随便改动其他人的代码。同时,因为是自己维护自己的代码,可能因为时间紧张或技术水平的局限性,某些问题一直不能被发现或得到比较好的解决。针对这点,XP提倡大家共同拥有代码,每个人都有权利和义务阅读其他代码,发现和纠正错误,重整和优化代码。这样,这些代码就不仅仅是一两个人写的,而是由整个项目开发队伍共同完成的,错误会减少很多,重用性会尽可能地得到提高,代码质量是非常好。

          为了防止修改其他人的代码而引起系统崩溃,每个人在修改后都应该运行测试程序。(从这点,我们可以再次看到,XP的各个惯例和规则是怎样有机地结合在一起的。)

    编程规范

         XP开发小组中的所有人都遵循一个统一的编程标准,因此,所有的代码看起来好像是一个人写的。因为有了统一的编程规范,每个程序员更加容易读懂其他人写的代码,这是是实现CollectiveCodeOwnership的重要前提之一。

    5Metaphor(系统比喻),不加班

         XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的,因为这说明关于项目进度的估计和安排有问题。

    Metaphor(系统比喻)

        为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能,XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。比如,对于一个搜索引擎,它的Metaphor可能就是“一大群蜘蛛,在网上四处寻找要捕捉的东西,然后把东西带回巢穴。”

    不加班

         大量的加班意味着原来的计划是不准确的,或者是程序远不清楚自己到底什么时候能完成什么工作。而且,开发管理人员和客户也因此无法准确掌握开发速度;开发人员也因此非常疲劳。XP认为,如果出现大量的加班现象,开发管理人员(比如Coach)应该和客户一起确定加班的原因,并及时调整项目计划、进度和资源。


    XP中一些基本概念的简介

    UserStory:开发人员要求客户把所有的需求写成一个个独立的小故事,每个只需要几天时间就可以完成。开发过程中,客户可以随时提出新的UserStory,或者更改以前的UserStory。

    StoryEstimates和开发速度:开发小组对每个UserStory进行估算,并根据每个开发周期(Iteration)中的实际情况反复计算开发速度。这样,开发人员和客户能知道每个星期到底能开发多少UserStory。

    ReleasePlan和ReleaseScope:整个开发过程中,开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory。

    Iteration(开发周期)和IterationPlan:在一个Release过程中,开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。

    TheSeed:第一个开发周期(Iteration)完成后,提交给客户的系统。虽然这不是最终的产品,但它已经实现了几个客户认为是最重要的Story,开发人员将逐步在其基础上增加新的模块。

    ContinuousIntegration(整合):把开发完的UserStory的模块一个个拼装起来,一步步接近乃至最终完成最终产品。

    验收测试(功能测试):对于每个UserStory,客户将定义一些测试案例,开发人员将使运行这些测试案例的过程自动化。

    UnitTest(单元测试):在开始写程序前,程序员针对大部分类的方法,先写出相应的测试程序。

    Refactoring(重整和优化):去掉代码中的冗余部分,增加代码的可重用性和伸缩性。


    小结

          XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终都能自信地面对客户需求的变化。XP强调团队合作,经理、客户和开发人员都是开发团队中的一员。团队通过相互之间的充分交流和合作,使用XP这种简单但有效的方式,努力开发出高质量的软件。XP的设计简单而高效;程序员们通过测试获得客户反馈,并根据变化修改代码和设计,他们总是争取尽可能早地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。

    XP很象一个由很多小块拼起来的智力拼图,单独看每一小块都没有什么意义,但拼装好后,一幅美丽的图画就会呈现在你面前。

    转载于:https://www.cnblogs.com/zhangqs008/archive/2009/11/04/2341230.html

    展开全文
  • 介绍什么是极限编程?

    2019-02-13 12:43:22
    极限编程是几种流行的敏捷过程之一。事实证明,它已在全球各种规模和行业的许多公司中取得了巨大成功。 极限编程是成功的,因为它强调客户满意度。而不是在将来某个日期提供您可能想要的所有内容,而不是在您需要时...

空空如也

1 2 3 4 5 ... 20
收藏数 3,512
精华内容 1,404
关键字:

极限编程