2019-04-04 22:42:29 weixin_44850444 阅读数 46
  • 体验极限编程XP

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

    10801 人正在学习 去看看 张传波

1.极限编程(Extreme programming,缩写为XP),是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。极限编程鼓励管理人员和开发人员接受并使用某些特别的有价值的方法。
2.极限编程的创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯。
3.极限编程的目标:降低因需求变更而带来的成本。极限编程通过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
4.极限编程的12个核心实践
(1)短交付周期:和Scrum一样xp采用迭代的交付方式,每个迭代1-3周时间。在每个迭代结束的时候,能够交付可运行的,经过测试的功能。
(2)计划游戏:主要包括软件发布计划和周期开发计划。
(3)结对编程:编程时两个人一起,一个考虑系统架构,一个设计编程细节。
(4)可持续节奏:在项目开发过程中持续保持节奏。
(5)代码集体所有:所有人都可以更改代码任意一部分,可以提升开发速度,提高错误发现的速率。
(6)编码规范:团队使用统一的编码规范。
(7)简单设计:用最简单的办法实现每个小需求。
(8)测试驱动开发(TDD):从功能需求的测试用例开始,先添加一个测试用例,然后运行所有的测试用例看看有没有问题,再实现测试用例所要测试的功能,然后再运行测试用例,查看是否有case失败,然后重构代码,再重复以上步骤;确保照顾到所有需求并实现所有功能。
(9)重构:开发人员对每个USER STORY都进行简单设计,但同时也在不断地对设计进行改进。
(10)系统隐喻:用比喻来描述系统或功能模块是怎样工作的,帮助团队更好理解需求。
(11)持续集成:团队经常基集成,每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。
(12)现场客户:客户应该时刻在现场解决问题
5.极限编程的4个价值:沟通、简单、反馈、勇气
6.极限编程的5个原则:快速反馈、假设简单、增量变化、拥抱变化、高质量工作。

参考资料:
scrum中文网http://www.scrumcn.com/agile/

2015-12-23 10:19:19 Absolut_Seven 阅读数 663
  • 体验极限编程XP

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

    10801 人正在学习 去看看 张传波

文章转载自:http://blog.csdn.net/ostrichmyself/article/details/5375223


敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别,

 

发现一篇外文, 见解非常深刻, 特将其翻译一把.

 

原文(DIFFERENCES BETWEEN SCRUM AND EXTREME PROGRAMMING )在此:

 

http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming

 

作者总结的大致区别如下:

 

区别之一:  迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

 

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰

 

区别之三: 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

 

别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”

 

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

 

作者建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

 

非常不错, 文武之道,有张有弛。

 

 

该博客之后有很多人提出了异议, 稍后将其推出,  看看其它敏捷高手是如何看待这个问题的, 也防止误导读者:

 

待续。。。。


2018-12-09 19:33:39 wb175208 阅读数 278
  • 体验极限编程XP

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

    10801 人正在学习 去看看 张传波

极限编程是敏捷开发的一种方法,极限编程针对小型的开发团队来说是一个不错的方法.

极限编程本质是务实主义的体现,快速稳定的实现每一个用户要求,是极限编程的基本要求。

1.客户尽量和开发人员在一起,一是可以知道开发的进度;二是可以和开发人员进行沟通,实时调整功能点的优先级。

2.对用户提出的功能点进行分拆,比如用户提出一个比较大的功能点,作为开发人员可以根据这个用户需求分拆成几个小的开发功能,并且给这几个功能点分别优先级;

3.每实现一个用户功能及时的给用户展示并且记录下用户的反馈;

4.在开发过程中遇到的问题,提出来让用户知道你的问题,并且根据问题的大小和功能的优先级调整开发的顺序;

5.小的功能版本以每两周作为一个开发周期,每三个月作为一个大的发布周期,发布计划并不是一成不变的,客户可以随时改变计划内容。客户可以取消或者添加功能点;

6.整个项目的代码归开发团队所有,每个人都有权力修改其中的每一句代码(前提是要知道如何修改);

7.软件项目不是全速的算跑,而是马拉松长跑。项目已启动就全速尽力狂奔的团队,到最后会筋疲力尽。而是应该保持一个适当的速度匀速前进。

8.管理人员(项目管理人员或者客户管理人员)不必采用威胁或者恳求开发人员达到他们想要的结果。

2014-01-19 00:13:00 zs15932616453 阅读数 3697
  • 体验极限编程XP

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

    10801 人正在学习 去看看 张传波
       上次的博文敏捷开发之道(一)敏捷开发宣言中,我们介绍了一下敏捷开发宣言,在其中,我们了解到了关于敏捷开发的几个重要的价值观。今天我们来了解一个敏捷开发的方法——极限编程XP

1、介绍

       极限编程(eXtreme Programming,简称XP)是敏捷方法中最被推崇的一个,它是一种优良的、通用的软件开发方法,它是由一组简单、具体、相互依赖的实践组成,这些实践结合在一起形成了敏捷开发过程。项目团队可以直接拿来使用,也可以对其中的实践进行修饰。

2、实践

       1)、客户作为团队成员

       我们上篇的博客中提到,敏捷开发中希望客户能够很好参与到项目中,与开发人员一起紧密工作。在XP中,谁是客户呢?
       XP中认为的客户是能够提供产品的特性并排列这些特性优先级的人或者团队。所以客户的定义非常广泛,也非常灵活,它可以不是真正的客户,因为客户很忙,所以如果我们的团队中没有真正的客户,那么我们也要设法去寻找和创造客户的替代品并将客户纳入到我们的项目团队中,而不是空缺。

       2)、用户素材

       在XP中,我们希望尽可能的将需求了解的更多和理解的更准确,但随着时间的推移和项目的进行,客户很可能变更一些需求和细节,所以在XP中,开发人员和客户探讨需求的过程汇总,更加希望客户能够在索引卡片上写下一些我们认可的词语,这些词语主要的目的就是使我们能够回忆起这次的交谈,开发人员可以在这些卡片上进行需求的估算。

       在这些卡片上写下的帮助我们进行优先级和价值估算的注记符就是用户素材,它的作用在于帮助我们进行计划的制定和实现的安排。

       3)、短交付周期

       XP项目一般每两周交付一次,两周成为一次迭代,每次迭代之后,会给客户进行一次演示,以便带到更加积极的反馈。
       在每一次迭代之初,首先要做的就是制定迭代计划。制定计划就是开发人员根据客户给的用户素材进行预算,客户为本次迭代选取任意数量的用户素材,一旦迭代开始,客户就不可以修订用户素材的优先级和定义,在迭代期间,开发人员就可以任意的将用户素材分解成任务,并按照一定的顺序进行开发
       迭代计划是一个比较小的交付,在一个XP团队中,通常会创建一个包含大约6次迭代内容的计划,也就是指定3个月的工作,它表示一个较大的交付,而这个较大的交付一般会被加入到产品中,所以成为发布计划。发布计划与迭代计划的实现过程类似,所不同的是,发布计划不是一成不变的,客户可以随时改变计划内容、改变用户素材的优先级以及编写新的用户素材等。

       4)、验收测试

       验收测试是由某种脚本语言编写的,可以用来验证系统能否按照客户指定的行为运转。所以,开发人员可以通过使用客户指定的验收测试进行有关用户素材细节的获取。也就是说,开发人员可以多次运行验收测试进行项目验收,一旦验收通过,那么系统创建就宣告结束,同时可以将该验收测试加入到项目中,并绝不允许该验收测试再次修改。


       今天的博客就先给大家介绍XP的这四个实践,更多内容,我们下一篇继续,请继续关注!


未完待续……
2010-03-16 22:56:00 liyangbing315 阅读数 8177
  • 体验极限编程XP

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

    10801 人正在学习 去看看 张传波

敏捷开发与极限编程

简介

      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)

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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