极限编程_极限编程xp - CSDN
精华内容
参与话题
  • 什么是极限编程

    千次阅读 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):概念、特点和应用

    千次阅读 2013-05-23 09:00:06
    [摘要] 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以...
     
     
     
     

    [摘要] 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求。

    [关键词] 极限编程;概念;特点;应用

    在传统的软件系统开发中,系统需求是在项目开发的开始阶段就确定下来,并在之后的开发过程中保持不变的,这就意味着从进入项目开发到之后的所有阶段所出现的所有需求变更(这样的需求变更在国内目前的商业软件系统开发中是不可避免的),将导致开发成本急速增加。极限编程是一种轻量级的、灵巧的、简单的软件工程方法,适合于12人以下的小型开发团队,它的主要目标在于面对商业软件系统环境做出了务实的选择,力求降低需求变更而带来的成本增加,进而提高软件的开发效率。

    一、极限编程简介

    极限编程(Extreme Programming,简称XP)是敏捷软件开发方法的代表。2000年,美国软件工程专家Kent Beck对极限编程这一创新软件过程方法论进行了解释:“XP是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方法。”Kent Beck建议XP应用于规模小、进度紧、需求变化大、质量要求严格的项目[1]。极限编程是价值而非实践驱动的高度迭代的开发过程。其价值体现在以下几个方面:第一,沟通(Communication):即追求有效的沟通。XP强调项目开发人员、设计人员、客户之间等有效地、及时地沟通,确保各种信息的畅通。第二,简单(Simplicity):即实现最简单的可行方案。XP认为应该尽量保持代码的简单,只要能够满足工作需要就行,这样有利于代码的重构和优化。第三,反馈(Feedback):即快速有效的反馈。要求不断对当前系统状态进行反馈,通过反馈,达到迅速沟通、编码、测试、发布的目的。第四,勇气(Courage):即勇于放弃和重构。对于用户的反馈,XP程序员要勇于对自己的代码进行修改,即使有些修改可能会使得原来已经通过的测试又出现错误,但是经过团队的共同攻关,最终必然会取得满意的效果。

    二、极限编程的开发过程及特点

    与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中,因此对工作环境、需求分析、设计、编程、测试、发布等提出了新的思路和要求。

    1、工作环境:XP要求每个参加项目开发的人都担任一个角色(项目经理、项目监督人等),并履行相应的权利和义务。所有的人都在一个开放式的开发环境中工作,最好是在同一个大房间中工作,随时讨论问题,强调每周40小时工作制,不加班。

    2、需求分析:客户被纳入开发队伍。由于客户不具备计算机专业知识,无法用专业语言明确描述需求,所以开发人员和客户一起,用讲故事的方式把需求表达出来,这种故事被称为user story,即用user story表示需求。开发人员根据经验将许多user story 组合起来,或将其进行分解,最终记录在story card的小卡片上,这些user story将陆续被程序员在各个小的周期内,按照商业价值、开发风险的优先顺序逐个开发。

    3、设计:XP强调简单设计(simple design),即用最简单的办法实现每个小需求。在XP中,没有那种传统开发模式中一次性的、针对所有需求的总体设计,这些设计只要能够满足系统客户在当前的需求就可以了,不需要考虑将来可能的变化,整个设计过程包括在整个螺旋式发展的项目中。

    4、编程:成对编程(pair programming)是极限编程的一大特色,即两个人一起使用同一个屏幕,同一个键盘,共同完成一段程序的编码。成对编程的好处是,可以提高纪律性,更容易写出优质的代码,同时保证编程的流畅进行,更重要的是,能够使得整个团队更方便地分享编程经验,有利于新手的快速成长。

    5、测试:在极限编程中,测试是非常重要的一个环节,它首先要求在开始写程序之前先写好测试,其目的是为了提高软件的可测试性。XP要求开发人员经常把开发好的模块整合到一起,每次整合后都要运行单元测试;做任何的代码复核和修改,都要运行单元测试;发现了漏洞,就要增加相应的测试。除了单元测试之外,还要进行整合测试、功能测试、负荷测试和系统测试等。所有这些测试是极限编程开发过程中最重要的文档之一,也是最终交付给用户的内容之一。

    6、发布:XP要求按照开发计划,每经过一个开发周期,软件就发布一次,而不是像传统的开发方法那样,整个软件开发完成后才发布。在一个开发周期内,开发人员要求客户选择最有价值的user story作为未来一两个星期的开发内容,一个开发周期完成后,提交给客户的系统虽然不是最终的产品,但它已经实现了几个客户认为是最重要的story,开发人员将逐步在其基础上增加新的模块,而且在发布前软件都经过单元测试和集成测试,因此,虽然软件并不完备,但是,发布的软件客户还是可以真正使用的。

    三、极限编程的优缺点

    1、极限编程的优点

    与传统的软件工程方法相比较,极限编程具有以下优点:(1)重视客户的参与;(2)重视团队合作和沟通;(3)制定计划前做出合理预测;(4)让编程人员参与软件功能的管理;(5)重视质量;(6)简单设计;(7)高频率的重新设计和重构;(8)高频率及全面的测试;(9)递增开发;(10)连续的过程评估;(11)对过去的工作持续不断的检查。

    2、极限编程的缺点

    其缺点主要表现为:(1)以代码为中心,忽略了设计;(2)缺乏设计文档,局限于小规模项目;(3)对已完成工作的检查步骤缺乏清晰的结构;(4)质量保证依赖于测试;(5)缺乏质量规划;(6)没有提供数据的收集和使用的指导;(7)开发过程不详细;(8)全新的管理手法带来的认同度问题;(9)缺乏过渡时的必要支持。

    四、极限编程的应用

    XP适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求,XP在平衡短期和长期之间做了巧妙的安排[2]。

    我国的软件开发过程经常存在一些问题,如:客户需求变化频繁、系统支付时间一推再推、交付系统错误层出不穷、因程序员半途跳槽而导致工作不能顺利完成、需求估计不足、因程序员之间交流少而导致代码重复开发、文档不能真实地反映实际情况等等。为了有效地克服上述问题,软件机构在项目开发时,有意识地采用XP方法,并且取得了一定效果。通过对这些应用的总结,可以概括出,XP应用确实具有一定的适用范围,而应用成功的关键在于,充分认识XP应用过程中的优缺点,在保持组织既有的开发过程和生命周期模型的前提下,结合应用类型、项目特点和组织文化,借鉴、汲取个别对项目有效的XP方法,在领会其精神实质的基础上灵活运用,而不是全部照搬硬套。另外以下几个问题也是在应用中需要注意的:

    1、不同方法的目标对象和适用环境各不相同,学习和运用流行的过程方法论是实施过程改进的好办法,但在具体应用过程中,应整合其最佳元素,设计出适合具体实际项目的过程体系。

    2、在软件工程实践中要充分把握好开发技能、软件过程和组织管理各个要素的平衡,不能偏重某一方面,轻视另一方面;

    3、在应用XP时,应该首先从基本实践入手,逐渐深入到扩展性实践,因为基本实践彼此独立,互不影响,而扩展性实践则是建立在某些基本实践的基础上的,而且要采取循序渐进、迂回反复(迭代)的策略,而不是一步到位,这样容易取得成功。

    我国目前许多开发机构中已经使用了XP方法,但是,由于XP理论本身仍然处于不断完善和改进阶段,另外具体的开发项目也有各自的特点,因此,如何更好地将其应用到实际的项目开发过程中还需要进一步深入研究。

    [参考文献]

    [1]谷秀岩,“关于极限编程的理论研究”,《计算机与网络》[J],2004年第12期,P93-95

    [2]王卫民,何晓韬,“极限编程理论浅析”,《安阳工学院学报》[J],2006年第6期,P45-47

    [3]方志刚,《软件工程原理与应用》(第二版)[M],北京,科学出版社,2003.8

    [4]张惠彦,廉保旺,逯野,“极限编程的研究和应用”,《科学技术与工程》[J],第7卷第12期,P2997-3000

    [5]杜荣华,龚德俊,刘好德,谌海军,“极限编程在大型项目开发中的应用”,《交通与计算机》[J],2004年第6期,P110-112


    转载自:http://www.uml.org.cn/UMLForum/200906103.asp

    展开全文
  • 体验极限编程(XP)

    万人学习 2018-10-22 21:38:02
    极限编程,英文:Extreme Programming,简称:XP编程,这是一种轻量、、强调适应变化、适合中小型项目的项目管理方法。本课程为你分享极限编程的10多种佳实践。
  • 极限编程

    2014-04-24 19:52:12
    极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。 设计和编程都是人的活动。忘记这一点,将会失去一切。 -- Bjarne Stroustrup  极限编程(XP...


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

    千次阅读 多人点赞 2019-12-02 10:07:26
    极限编程(XP)的起源始于1990年代,当时肯特·布莱克(Kent Black)在戴姆勒克莱斯勒(DaimlerChrysler)处理项目时试图寻找一种更好的软件开发方法。他的新方法后来被称为极限编程方法论,并被证明是一种成功的...

    极限编程(XP)的起源始于1990年代,当时肯特·布莱克(Kent Black)在戴姆勒克莱斯勒(DaimlerChrysler)处理项目时试图寻找一种更好的软件开发方法。他的新方法后来被称为极限编程方法论,并被证明是一种成功的方法。

    作为对旧方法的一种反应而创建的方法,XP使用了与瀑布模型不同的不同方法。它的方法的一个重要区别是它关注于适应性而不是可预测性。这种方法背后的原因是,软件开发是一个非常不稳定的过程,其中从一开始就无法完全预测需求,但是随着项目的进行,需求将始终发生变化。因此,软件开发需要一种方法,该方法应能够在项目生命周期中的任何时候适应不断变化的需求。

    在戴姆勒克莱斯勒项目的实验中 肯特 发现了四个维度,这些维度后来成为XP的哲学。这些尺寸,如果正确实施,将改善任何软件开发项目。尺寸为:

    1.      您需要改善沟通。

    2.      您需要寻求简单性。

    3.      您需要获得有关您的表现的反馈。

    4.      您需要始终勇往直前。

     

    “每种做法仍然具有与以前相同的弱点,但是如果现在这些弱点被其他做法的强项所弥补,该怎么办呢?我们也许可以简单地做事。” –肯特·贝克(Kent Beck)

     

    极限编程的白板视图

    它可能看起来像这样……

     

    「extreme programming visual paradigm」的圖片搜尋結果"

    我将这种观点组合在一起,以帮助一些人了解“系统”的外观。它并不一定是完美的,但他们至少需要一个基本的构想或框架,以便他们可以更好地理解各种实践如何结合在一起。

     

    使白板视图帮助人更快地入手极限编程

    一张图片-价值1,000个字!

    这样做的好处是,一旦您在白板上放置了一张简单的图片,便可以与团队进行真正的讨论,以讨论可以改进的地方。这里的主要思想是使您脑海中得到简单的视觉效果,以便您可以轻松地在白板上绘画,并知道各种活动和工件的名称。 

    如果您对此有所保留,则可以帮助您建立简单的词汇表。 

    该词汇表将帮助您更快地加入其他人,并且将帮助您快速扩展自己的工具箱,并且很快您将发现自己正在撰写新方法并在流程中进行有趣的创新,这将帮助您做得更好,更快,更便宜…在云时间上。

     

    什么是极限编程

    极限编程(XP)是一种基于简单,沟通,反馈和勇气原则的轻量级软件开发方法。  

    我希望能够扫描方法以比较方法。 

    为此,我创建了活动,工件,原理和实践的框架。   

    这是我在XP上的注意事项:

    活动项目 (Activities)

    • 编码
    • 测试中
    • 倾听
    • 设计中

    制品 (Artifacts)

    • 验收测试
    • 迭代计划
    • 发布和迭代计划
    • 故事
    • 故事卡
    • 有关测试数量,每次迭代的故事等的统计信息
    • 单元测试
    • 每次迭代都工作代码

    12种做法 (Best Practices)

    这是12种XP做法:

     在XP中,这四项基本活动是通过使用实践来实现的,这些实践是传统的软件工程实践,但被提升为体现和鼓励XP价值观。尽管完全有28条极限编程的规则和实践[9],但它们可以压缩为十二个简单规则:

    1. 用户案例(planning ):用户案例可以视为用例的较小版本。这样,客户可以尽可能简短地定义新应用程序的规范(功能,价值,优先级)。这些故事将成为项目团队进行项目成本估算和管理的基础。
    2. 小型发行版(Buidling Block): XP强调对应用程序进行小型,简单但频繁的版本更新。每个新添加的要求将立即合并,并重新发布系统。
    3. 隐喻(System Metaphor):开发人员和程序员必须遵守名称,类名和方法的标准。
    4. 集体所有权 (collective Ownership):在XP方法论中,所有代码均被视为由整个团队拥有,而不是单个财产。因此,所有代码都将由所有人审查和更新。
    5. 编码标准 (Coding standard):编码的样式和格式必须相同,以确保团队成员之间的兼容性。这种方法可以加快协作速度。
    6. 简单的设计 (Simple Design):始终寻找尽可能简单的系统实现但又满足所有必需功能的系统实现。
    7. 重构 (Refactoring)所有团队成员应不断调整和改进应用程序。这要求成员之间进行非常良好的沟通,以避免重复工作。
    8. 测试 (Testing):每个小的发行版(称为构建块)都必须通过测试,然后才能发行。XP在这方面的独特之处在于测试首先创建,然后应用程序代码的开发,以满足并通过cahllenges那些预笔试。
    9. 对编程 (Pair Programming): XP程序员可以成对工作。所有代码都是由在同一台计算机上一起工作的两个程序员开发的。期望结对编程以相同或更少的成本生成更高质量的代码。
    10. 持续集成 (Continuous Integration):软件构建一天完成几次。这样,所有开发人员都可以避免工作分散,因为他们不断地将代码发布和集成在一起。
    11. 每周工作40个小时 (40-hour workweek)通过不超过身体可以承受的工作量,保持身心健康。
    12. 现场客户 (On-site customer)必须将客户视为项目的组成部分。必须安排客户随时可用,以确保项目步入正轨。

    XP过程可以通过下图表示:

     

     

    要了解XP的实践,请参阅XP的实践和主要周期的图片。

    「12 xp practices」的圖片搜尋結果"

     

    极端编程: 5个价值

    • 通讯
    • 勇气
    • 反馈
    • 尊重
    • 简单

    相数

    以下是XP项目生命周期的各个阶段。

    • 探索阶段
    • 规划阶段
    • 迭代到发布阶段
    • 生产阶段
    • 维护阶段

    有关可视化概述,请参阅《 XP生命周期中的敏捷建模》

     

    12条原则(敏捷宣言)

    根据敏捷宣言,以下是12条敏捷原则  

    「agile 12 principle visual paradigm」的圖片搜尋結果"

     

    • 我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。
    • 即使在开发后期,也欢迎不断变化的需求。敏捷流程利用变更来获得客户的竞争优势。
    • 频繁交付工作软件,从几周到几个月不等,而更倾向于缩短时间范围。
    • 在整个项目中,业务人员和开发人员必须每天一起工作。
    • 围绕有积极性的人建立项目。给他们提供所需的环境和支持,并信任他们来完成工作。
    • 向开发团队内部和内部传达信息的最有效方法是面对面的对话。
    • 工作软件是进度的主要衡量标准。
    • 敏捷过程促进可持续发展。赞助者,开发者和用户应该能够无限期地保持恒定的步伐。
    • 持续关注技术卓越和良好的设计可提高敏捷性。
    • 简洁性(最大化未完成工作量的艺术)至关重要。
    • 最好的体系结构,需求和设计来自自组织团队。
    • 团队定期检查如何提高效率,然后相应地调整和调整其行为

    4个价值观(敏捷宣言)

    根据敏捷宣言,这些是四个敏捷值:

    • 个人与流程和工具之间的互动
    • 通过全面的文档工作软件
    • 客户合作而非合同谈判
    • 响应计划变更

    「agile 12 principle visual paradigm」的圖片搜尋結果"

    其他资源

    你可能还喜欢

    展开全文
  • 其中应用比较广泛的就是极限编程与scrum。本文主要介绍极限编程。 极限编程(extreme programming),简称xp,这是敏捷过程中极具盛名的一个。其中“极限”代表把好的开发实践运用到极致。目前来看,极限编程广泛...
  • 浅谈极限编程

    千次阅读 2019-06-08 23:08:15
    为什么出现极限编程 ? 敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”...
  • 极限编程(XP)12个最佳实践

    千次阅读 2017-03-29 11:43:50
    极限编程、敏捷开发的十二个原则
  • 敏捷方法之极限编程(XP)和 Scrum区别

    万次阅读 2010-03-14 12:12:00
    敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别, 发现一篇外文, 见解非常深刻, 特将其翻译一把. 原文(DIFFERENCES BETWEEN SCRUM AND ...
  • 敏捷方法中极限编程(XP)和Scrum区别

    千次阅读 2016-11-16 15:04:53
    敏捷开发的实践有XP 和 Scrum,似乎很少有文章介绍这两者的区别 \ XP Scrum 迭代周期 1-2周 2-4周 是否允许修改需求 在一个需要没有实现的时候可以使用其他的需求将其替换,但是实现的时间是要相等的 ...
  • [技术讨论]国内学术界中的极限编程

    千次阅读 2007-05-14 13:13:00
    今天按照他的要求我检索了四种国内期刊,检索结果如下:软件学报中XP,极限,极限编程等关键字都没有检索到相关信息计算机学报中XP和极限编程都没有检索到任何论文。计算机研究与发展中也没有XP和极限编程的任何论文...
  • 极限编程(XP编程)读书笔记(一)

    千次阅读 2010-07-29 15:06:00
    极限编程,通常成为XP,是一种针对业务和软件开发的规则,它的作用在于将两者的力量集中在共同的、可以达到的目标上。XP团队以可持续的步调生产优质软件。XP属于轻量开发方法中较有影响的一种方法。XP方法强调客户...
  • 现在又不少在线测试平台,这些平台提供了很多很好的编程题,当然著名的acm中会有很多难题,如果你想挑战自己的智力极限,如果你对编程很有兴趣,那么就可以去这些平台注册,然后编程提交,跟其他编程高手一较高下。...
  • 最近两周的时间里,我看了73篇极限编程的论文,其中68篇是主要写结对编程的论文。在这些论文中,我看到了各个国家的文章,欧洲,北美,澳洲,少量亚洲的论文,其中看到了大概四五篇来自国内大学与国外大学或者研究...
  • 参考:http://zhidao.baidu.com/link?url=O9OtPIuteNEcN0hXNDm0k9H3SIZeBsbONCRdp1dUmNAZLWOEdLvLV9ggDHxCd3iq8-wgLreQSbw00-mdxwLUUq 1、敏捷开发 ... 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进...
  • 敏捷开发之极限编程过程

    千次阅读 2016-12-25 20:12:24
    极限编程过程 极限编程是敏捷开发软件开发使用最为广泛的一个方法,作为面向对象方法的推荐开发范型,它包含了策略,设计,编码,测试4个框架活动的规则和实际。 策划:  》倾听一系列的用户故事,描述即将...
  • 极限编程四个核心的理解(一)

    千次阅读 2005-04-18 16:34:00
    极限编程的核心有四个,交流、简单、反馈和勇气,这四个原则大家在平时做项目的过程中一定也注意到了。但是两位大师Kent Beck 和 Martin Fowler能够把这四点归结在一起,使他们能够共同组成极限编程这架四轮马车,却...
  • XP 极限编程

    千次阅读 2010-10-08 13:28:00
    xp 极限编程
  • 极限编程基本概念

    千次阅读 2006-10-16 08:55:00
    极限编程极限编程是价值而非实践驱动的高度迭代的开发过程。极限编程的价值:1、沟通(Communication):追求有效的沟通。2、简单(Simplicity):实现最简单的可行方案。3、反馈(Feedback):快速有效的反馈4、勇气...
1 2 3 4 5 ... 20
收藏数 45,571
精华内容 18,228
关键字:

极限编程