精华内容
下载资源
问答
  • 极限编程xp及敏捷

    2018-05-29 09:45:56
    极限编程XP教程为一部非常实用的敏捷化编程指南,可指导大家有话编码风格和效率
  • 极限编程XP(Extreme Programming)

    千次阅读 2018-10-18 22:00:03
    在敏捷方法论领域中,比较知名的、有影响力的,是拥有与Microsoft的操作系统相同缩写语——XP极限编程(eXtreme Programming)。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜,也是被研究、尝试、应用、赞扬...

    敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量,不但不能够有效体现灵活性,反而显得是不解决问题的方法论似的。因此,就有了一次划时代的会议,创建了敏捷联盟。

    在敏捷方法论领域中,比较知名的、有影响力的,是拥有与Microsoft的操作系统相同缩写语——XP的极限编程(eXtreme Programming)。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜,也是被研究、尝试、应用、赞扬、批判最多的一种方法论,也是相对来说最成熟的一种。

    这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间,Kent Beck、Ward Cunninggham、Ron Jeffrey在开发C3项目(Chrysler Comprehensive Compensation)的实践中总结出了XP的基本元素。在此之后,Kent Beck和他的一些好朋友们一起在实践中完善提高,终于形成了极限编程方法论。

    解析极限编程

    那么什么是XP呢?XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于:

    • 在更短的周期内,更早地提供具体、持续的反馈信息。
    • 在迭代的进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它。
    • 依赖于自动测试程序来监控开发进度,并及早地捕获缺陷。
    • 依赖于口头交流、测试和源程序进行沟通。
    • 倡导持续的演化式设计。
    • 依赖于开发团队内部的紧密协作。
    • 尽可能达到程序员短期利益和项目长期利益的平衡。

    Kent Beck曾经说过“开车”就是一个XP的范例,即使看上去进行得很顺利,也不要把视线从公路上移开,因为路况的变化,将使得你必须随时做出一些这样那样的调整。而在软件项目中,客户就是司机,他们也没有办法确切地知道软件应该做什么,因此程序员就需要向客户提供方向盘,并且告知我们现在的位置。

    XP包括写什么呢?如图,XP由价值观、原则、实践和行为四个部分组成,它们彼此相互依赖、关联, 并通过行为贯穿于整个生命期

     

    四大价值观

     

    XP的核心是其总结的沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage)四大价值观,它们是XP的基础,也是XP的灵魂。
    此外还扩展了第五个价值观:谦逊(Modesty)。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键,是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP;轻松愉快地来感受XP的实践思想;自己认真实践后,通过对真实反馈的分析,来决定XP对自己的价值;有勇气接受它,或改进它。

    1. 沟通

    通畅程序员给人留下的印象就是“内向、不善言谈”,然后项目中的许多问题就出在这些缺乏沟通的开发人员身上。经常由于某个程序员做出了一个设计决定,但是却不能及时地通知大家,结果使得大家在协作与配合上出现了很多的麻烦,而在传统的方法论中,并不在意这种口头沟通不畅的问题,而是希望借助于完善的流程和面面俱到的文档、报表、计划来替代,但是这同时又引入了效率不高的新问题。

    XP方法论认为,如果小组成员之间无法做到持续的、无间断的交流,那么协作就无从谈起,从这个角度能够发现,通过文档、报表等人工制品进行交流面临巨大的局限性。因此,XP组合了诸如对编程这样的最佳实践,鼓励大家进行口头交流,通过交流解决问题,提高效率。

    2. 简单

    XP方法论提倡在工作中秉承“够用就好”的思路,也就是尽量地简单化,只要今天够用就行,不考虑明天会发现的新问题。这一点看上去十分容易,但是要真正做到保持简单的工作其实很难的。因为在传统的开发方法中,都要求大家对未来做一些预先规划,以便对今后可能发生的变化预留一些扩展的空间。

    正如对传统开发方法的认识一样,许多开发人员也会质疑XP,保持系统的扩展性很重要,如果都保持简单,那么如何使得系统能够有良好的扩展性呢?其实不然,保持简单的理由有两个:

    • 开发小组在开发时所做的规划,并无法保证其符合客户需要的,因此做的大部分工作都将落空,使得开发过程中重复的、没有必要的工作增加,导致整体效率降低。
    • 另外,在XP中提倡时刻对代码进行重构,一直保持其良好的结构与可扩展性。也就是说,可扩展性和为明天设计并不是同一个概念,XP是反对为明天考虑而工作,并不是说代码要失去扩展性

    而且简单和沟通之间还有一种相对微妙的相互支持关系。当一个团队之间,沟通的越多,那么就越容易明白哪些工作需要做,哪些工作不需要做。另一方面,系统越简单,需要沟通的内容也就越少,沟通也将更加全面。

    3. 反馈

    是什么原因使得我们的客户、管理层这么不理解开发团队?为什么客户、管理层总是喜欢给我们一个死亡之旅?究其症结,就是开发的过程中缺乏必要的反馈。在许许多多项目中,当开发团队经历过了需求分析阶段之后,在相当长的一段时间内,是没有任何反馈信息的。整个开发过程对于客户和管理层而言就像一个黑盒子,进度完全是可见的。

    而且在项目的过程中,这样的现象不仅出现在开发团队与客户、管理层之间,还包括在开发团队内部。这一切问题都需要我们更加注重反馈。,反馈对于任何软件项目的成功都是至关重要的,而在XP方法论中则更进一步,通过持续、明确的反馈来暴露软件状态的问题。具体而言就是:

    • 在开发团队内部,通过提前编写单元测试代码,时时反馈代码的问题与进展。
    • 在开发过程中,还应该加强集成工作,做到持续集成,使得每一次增量都是一个可执行的工作版本,也就是逐渐是软件长大,整个过程中,应该通过向客户和管理层演示这些可运行的版本,以便及早地反馈,及早地发现问题。

    同时,我们也会发现反馈与沟通也有着良好的配合,及时和良好的反馈有助于沟通。而简单的系统更有利于测试盒反馈。

    4. 勇气

    在应用XP方法论时,我们每时每刻都在应对变化:由于沟通良好,因此会有更多需求变更的机会;由于时刻保持系统的简单,因此新的变化会带来一些重新开发的需要;由于反馈及时,因此会有更多中间打断你的思路的新需求。

    总之这一切,使得你立刻处于变化之中,因此这时就需要你有勇气来面对快速开发,面对可能的重新开发。也许你会觉得,为什么要让我们的开发变得如此零乱,但是其实这些变化若你不让它早暴露,那么它就会迟一些出现,并不会因此消亡,因此,XP方法论让它们早出现、早解决,是实现“小步快走”开发节奏的好办法。

    也就是XP方法论要求开发人员穿上强大、自动测试的盔甲,勇往直前,在重构、编码规范的支持下,有目的地快速开发。

    勇气可以来源于沟通,因为它使得高风险、高回报的试验成为可能;勇气可以来源于简单,因为面对简单的系统,更容易鼓起勇气;勇气可以来源于反馈,因为你可以及时获得每一步前进的状态(自动测试),会使得你更勇于重构代码。

    5. 四大价值观之外

    在这四大价值观之下,隐藏着一个更深刻的东西,那就是尊重。因为这一切都建立在团队成员之间的相互关心、相互理解的基础之上。

    5个原则

    1. 快速反馈

    及时地、快速地获取反馈,并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。这也是对反馈这一价值观的进一步补充。

    2. 简单性假设

    类似地,简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决,也就是说只为本次迭代考虑,不去想未来可能需要什么,相信具有将来必要时增加系统复杂性的能力,也就是号召大家出色地完成今天的任务。

    3. 逐步修改

    就像开车打方向盘一样,不要一次做出很大的改变,那样将会使得可控性变差,更适合的方法是进行微调。而在软件开发中,这样的道理同样适用,任何问题都应该通过一系列能够带来差异的微小改动来解决。

    4. 提倡更改

    在软件开发过程中,最好的办法是在解决最重要问题时,保留最多选项的那个。也就是说,尽量为下一次修改做好准备。

    5. 优质工作

    在实践中,经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如,界面的按钮有一些不平整,由于不影响使用就先不管;某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象,这样的坏习惯一旦养成,必然使得代码质量大打折扣。

    而在XP方法论中,贯彻的是“小步快走”的开发原则,因此工作质量决不可打折扣,通常采用测试先行的编码方式来提供支持。

    13个最佳实践

    在XP中,集成了13个最佳实践,有趣的是,它们没有一个是创新的概念,大多数概念和编程一样老。其主要创新点在于提供一种良好的思路,将这些最佳实践结合在一起,并且确保尽可能彻底地执行它们,使得它们能够在最大程度上相互支持,紧接下来,我们就对每一种最佳实践进行一番了解。

    1. 计划游戏

    计划游戏的主要思想就是先快速地制定一份概要的计划,然后随着项目细节的不断清晰,再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。

    “客户负责业务决策,开发团队负责技术决策”是计划游戏获得成功的前提条件。也就是说,系统的范围、下一次迭代的发布时间、用户故事的优先级应该由客户决定;而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险,以及具体的开发顺序应该有开发团队决定。

    好了,明白这些就可以进行计划游戏了。首先客户和开发人员坐在同一间屋子里,每个人都准备一支笔、一些用于记录用户故事的纸片,最好再准备一个白板,就可以开始了。

    • 客户编写故事:由客户谈论系统应该完成什么功能,然后用通俗的自然语言,使用自己的语汇,将其写在卡片上,这也就是用户故事。
    • 开发人员进行估算:首先客户按优先级将用户故事分成必须要有、希望有、如果有更好三类,然后开发人员对每个用户故事进行估算,先从高优先级开始估算。如果在估算的时候,感到有一些故事太大,不容易进行估算,或者是估算的结果超过2人/周,那么就应该对其进行分解,拆成2个或者多个小故事。
    • 确定迭代的周期:接下来就是确定本次迭代的时间周期,这可以根据实际的情况进行确定,不过最佳的迭代周期是2~3周。有了迭代的时间之后,再结合参与的开发人数,算出可以完成的工作量总数。然后根据估算的结果,与客户协商,挑出时间上够、优先级合适的用户故事组合,形成计划。

    2. 小型发布

    XP方法论秉承的是“持续集成,小步快走”的哲学,也就是说每一次发布的版本应该尽可能的小,当然前提条件是每个版本有足够的商业价值,值得发布。

    由于小型发布可以使得集成更频繁,客户获得的中间结果也越频繁,反馈也就越频繁,客户就能够实时地了解项目的进展情况,从而提出更多的意见,以便在下一次迭代中计划进去。以实现更高的客户满意度。

    3. 隐喻

    相对而言,隐喻这一个最佳实践是最令人费解的。什么是隐喻呢?根据词典中的解释是:“一种语言的表达手段,它用来暗示字面意义不相似的事物之间的相似之处”。那么这在软件开发中又有什么用呢?总结而言,常常用于四个方面。

    • 寻求共识:也就是鼓励开发人员在寻求问题共识时,可以借用一些沟通双方都比较熟悉的事物来做类比,从而帮助大家更好地理解解决方案的关键结构,也就是更好地理解系统是什么、能做什么。
    • 发明共享词汇:通过隐喻,有助于提出一个用来表示对象、对象间的关系通用名称。例如,策略模式(用来表示可以实现多种不同策略的设计模式)、工厂模式(用来表示可以按需“生产”出所需类得设计模式)等。
    • 创新的武器:有的时候,可以借助其他东西来找到解决问题的新途径。例如:“我们可以将工作流看做一个生产线”。
    • 描述体系结构:体系结构是比较抽象的,引入隐喻能够大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间通过一条传递消息的“管道”进行通信。

    当然,如果能够找到合适的隐喻是十分快乐的,但并不是每种情况都可以找到恰当的隐喻,你也没有必要强求

    4. 简单设计

    强调简单设计的价值观,引出了简单性假设原则,落到实处就是“简单设计”实践。这个实践看上去似乎很容易理解,但却又经常被误解,许多批评者就指责XP忽略设计是不正确的。其实,XP的简单设计实践并不是要忽略设计,而且认为设计不应该在编码之前一次性完成,因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上的。

    Kent Beck概念中简单设计是这样的:

    • 能够通过所有的测试程序。
    • 没有包括任何重复的代码。
    • 清楚地表现了程序员赋予的所有意图。
    • 包括尽可能少的类和方法
    • 他认为要想保持设计简单的系统,需要具备简单思考的能力,拥有理解代码和修改的勇气,以及为了消除代码的“坏味道”而定期重构的习惯。
    • 那么如何开始进行简单的设计呢?XP实践者们也总结也一些具体的、可操作的思考方法。
    • 首先写测试代码:具体将在后面详细描述。
    • 保持每个类只负责一件事:SRP(单一职责原则)是面向对象设计的基础原则之一。
    • 使用Demeter(迪米特)法则:迪米特法则,也称为LoD法则、最少知识原则。也就是指一个对象应当对其他对象尽可能少地了解。用隐喻的方法来解释的话就是“只与你直接的朋友通信”、“不要和陌生人说话”。
    • 使用CRC卡片进行探索。

    5. 测试先行/测试驱动开发

    当我第一次看到“测试先行”这个概念的时候,我的第一感觉就是不解,陷入了“程序都还没有写出来,测试什么呀?”的迷思。我开始天马行空地寻求相关的隐喻,终于找到了能够启发我的工匠,首先,我们来看看两个不同的工匠是如何工作的吧。

    • 工匠一:先拉上一根水平线,砌每一块砖时,都与这跟水平线进行比较,使得每一块砖都保持水平。
    • 工匠二:先将一排砖都砌完,然后再拉上一根水平线,看看哪些砖有问题,对有问题的砖进行适当的调整。

    你会选择哪种工作方法呢?你一定会骂工匠二笨吧!这样多浪费时间呀!然而你自己想想,你平时在编写程序的时候又是怎么做的呢?我们就是按工匠二的方法在工作呀!甚至有时候比工匠二还笨,是整面墙都砌完了,直接进行“集成测试”,经常让整面的墙倒塌。看到这里,你还会觉得自己的方法高明吗?这个连工匠都明白的道理,自己却画地为牢呀。

    不仅我们没有采用工匠一的工作方法,甚至有的时候程序员会以“开发工作太紧张”为理由,而忽略测试工作。但这样却导致了一个恶性循环,越是没有空编写测试程序,代码的效率与质量越差,花在找Bug、解决Bug的时间也越来越多,实际产能大打降低。由于产能降低了,因此时间更紧张,压力更大。你想想,为什么不拉上一根水平线呢?难道,我们不能够将后面浪费的时间花在单元测试上,使得我们的程序一开始就更健壮,更加易于修改吗?不过,编写测试程序当然要比拉一条水平线难道多,所以我们需要引入“自动化测试工具”,免费的xUnit测试框架就是你最佳的选择。

    为了鼓励程序员原意甚至喜欢在编写程序之前编写测试代码,XP方法论还提供了许多有说服力的理由。

    • 如果你已经保持了简单的设计,那么编写测试代码根本不难。
    • 如果你在结对编程,那么如果你想出一个好的测试代码,那么你的伙伴一定行。
    • 当所有的测试都通过的时候,你再也不会担心所写的代码今后会“暗箭伤人”,那种感觉是相当棒的。
    • 当你的客户看到所有的测试都通过的时候,会对程序充满前所未有的信心。
    • 当你需要进行重构时,测试代码会给你带来更大的勇气,因为你要测试是否重构成功只需要一个按钮。

    测试先行是XP方法论中一个十分重要的最佳实践,并且其中所蕴含的知识与方法也十分丰富。

    6. 重构

    重构时一种对代码进行改进而不影响功能实现的技术,XP需要开发人员在闻到代码的坏味道时,有重构代码的勇气。重构的目的是降低变化引发的风险,使得代码优化更加容易。通常重构发生在两种情况之下。

    • 实现某个特性之前:尝试改变现有的代码结构,以使得实现新的特性更加容易。
    • 实现某个特性之后:检查刚刚写完的代码后,认真检查一下,看是否能够进行简化。

    在《重构》一书中,作者Martin Fowler提示我们:在考虑重构时,应该要养成编写并经常运行测试代码的习惯;要先编写代码,再进行重构;把每一次增加功能都当做一次重构的好时机;将每一个纠正错误当做一次重构的重要时机。同时,该书中也列出大量需要重构的情况和重构方法。

    最后类似地,给还没有足够勇气进行重构的程序员打几剂强心针:

    • XP提倡集体代码所有制,因此你可以大胆地在任何需要修改的地方做改动。
    • 由于在XP项目组中有完整的编码标准,因此在重构前无须重新定义格式。
    • 在重构中遇到困难,和你结对编程的伙伴能够为你提供有效的帮助。
    • 简单的设计,会给重构带来很大的帮助。
    • 测试先行让你拥有了一个有效的检验器,随时运行一下就知道你重构的工作是否带来了影响。
    • 由于XP在持续集成,因此你重构所带来的破坏很快就能够暴露,并且得以解决。

    重构技术是对简单性设计的一个良好的补充,也是XP中重视“优质工作”的体现,这也是优秀的程序员必备的一项技能。

    7. 结对编程

    “什么!两个人坐在一起写程序?那岂不是对人力的巨大浪费吗?而且我在工作时可不喜欢有一个人坐在边上当检察官。”是的,正如这里列举出来的问题一样,结对编程技术还是被很多人质疑的。

    不过,自从20世纪60年代,就有类似的实践在进行,长期以来的研究结果却给出了另外一番景象,那就是结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度,但慢慢的,开发速度会逐渐加快,究其原因,主要是结对编程大打降低了沟通的成本,提供了工作的质量,具体表现在:

    • 所有的设计决策确保不是由一个人做出的。
    • 系统的任何一个部分都肯定至少有2个人以上熟悉。
    • 几乎不可能有2个人都忽略的测试项或者其他任务
    • 结对组合的动态性,是一个企业知识管理的好途径。
    • 代码总是能够保证被评审过。
    • 而且XP方法论集成的其他最佳实践也能够使得结对编程更加容易进行:
    • 编码标准可以消除一些无谓的分歧。
    • 隐喻可以帮助结对伙伴更好地沟通。
    • 简单设计可以使得结对伙伴更了解他们所从事的工作。

    结对编程技术被誉为XP保持工作质量、强调人文主义的一个典型的实践,应用得当还能够使得开发团队之前的协作更加流畅、知识交流与共享更加频繁,团队的稳定性也会更加稳固。

    8. 集体代码所有制

    由于XP方法论鼓励团队进行结对编程,而且认为结对编程的组合应该动态地搭配,根据任务的不同、专业技能的不同进行最优组合。由于每个人都肯定会遇到不同的代码,所以代码的所有制就不再适合于私有,因为那样会给修改工作带来巨大的不便。

    也就是说,团队中的每个成员都拥有对代码进行改进的权利,每个人都拥有全部代码,也都需要对全部代码负责。同时,XP强调代码是谁破坏的(也就是修改后发生问题),就应该由谁来修复。

    由于在XP中,有一些与之匹配的最佳实践,因此你并无须担心采用集体代码所有制会让你的代码变得越来越乱:

    • 由于在XP项目中,集成工作是一件经常性得工作,因此当有人修改代码而带来了集成的问题,会在很快的时间内被发现。
    • 由于每一个类都会有一个测试代码,因此不论谁修改了代码,都需要运行这个测试代码,这样偶然性的破坏发生的概率将很小。
    • 由于每一个代码的修改就是通过了结对的两个程序员共同思考,因此通常做出的修改都是对系统有益的。
    • 由于大家都坚持了相同的编码标准,因此代码的可读性、可修改性都会比较好,而且还能够避免由于命名法、缩进等小问题引发经常性得代码修改。

    集成代码所有制是XP与其他敏捷方法的一个较大不同,也是从另一个侧面体现了XP中蕴含的很深厚的编码情节。

    9. 持续集成

    在前面谈到小型发布、重构、结对编程、集体代码所有制等最佳实践的时候,我们多次看到“持续集成”的身影,可以说持续集成是对这些最佳实践的基本支撑条件。

    可能大家会对持续集成与小型发布代表的意思混淆不清,其实小型发布是指在开发周期经常发布中间版本,而持续集成的含义则是要求XP团队每天尽可能多次地做代码集成,每次都在确保系统运行的单元测试通过之后进行。

    这样,就可以及早地暴露、消除由于重构、集体代码所有制所引入的错误,从而减少解决问题的痛苦

    要在开发过程中做到持续集成并不容易,首先需要养成这个习惯。而且集成工作往往是十分枯燥、烦琐的,因此适当地引入每日集成工具是十分必要的。XP建议大家首先使用配置管理服务器将代码管理起来,然后使用Ant或Nant等XP工具,编写集成脚本,调用xUint等测试框架,这样就可以实现每当程序员将代码Check in到配置服务器上时,Ant就会自动完成编译和集成,并调用测试代码完成相应的测试工作。

    10. 每周工作40小时/可持续的速度

    这是最让开发人员开心的、管理者反对的一个最佳实践了,加班、再加班早已成为开发人员的家常便饭,也是管理者最常使用的一种策略,而XP方法论认为,加班最终会扼杀团队的积极性,最终导致项目失败,这也充分体现了XP方法关注人的因素比关注过程的因素更多一些。

    Kent Beck认为开发人员即使能够工作更长的时间,他们也不该这样做,因为这样做会使他们更容易厌倦编程工作,从而产生一些影响他们效能的其他问题。因此,每周工作40小时是一种顺势行为,是一种规律。其实对于开发人员和管理者来说,违反这种规律是不值得的。

    • 开发人员:如果不懂得休息,那么就无法将自己的节奏调整到最佳状态,那么就会带来很大的负面影响。而且在精神不集中的状态下,开发质量也得不到保证。
    • 管理者:也许这可以称得上“第二种人月神话”,那就是你不得不通过延长每天的工作时间来获得更多的人月。这是因为,每个开发人员的工作精力是有限的,不可能无限增长,在精力不足的时候,不仅写出来的代码质量没有保障,而且还可能为项目带来退步的效果。因此采用加班的方式并不是一个理性的方式,是得不偿失的。

    不过有一点是需要解释的,“每周工作40小时”中的40不是一个绝对数,它所代表的意思是团队应该保证按照“正常的时间”进行工作。那么如何做到这一点呢?

    首先,定义符合你团队情况的“正常工作时间”。

    其次,逐步将工作时间调整到“正常工作时间”。

    再次,除非你的时间计划一团糟,否则不应该在时间妥协。

    最后,鼓起勇气,制定一个合情合理的时间表。

    正如米卢说过的“享受足球”一样,同样地,每一个开发人员应该做到“享受编程”,那么“每周工作40小时”就是你的起点。

    团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。

    11. 现场客户

    为了保证开发出来的结果与客户的预想接近,XP方法论认为最重要的需要将客户请到开发现场。就像计划游戏中提到过的,在XP项目中,应该时刻保证客户负责业务决策,开发团队负责技术决策。因此,在项目中有客户在现场明确用户故事,并做出相应的业务决策,对于XP项目而言有着十分重要的意义。

    也许有人会问,客户提交了用户故事之后不就完成工作了吗?其实很多尝试过用户故事的团队都会发现其太过简单,包含的信息量极少,XP方法论不会不了解,因此,不会把用户故事当做开发人员交付代码的唯一指示。用户故事只是一个起点,后面的细节还需要开发人员与客户之间建立起来的良好沟通来补充。

    作为一名有经验的开发人员,绝对不会对现场客户的价值产生任何怀疑,但是都会觉得想要实现现场客户十分困难。要实现这一点,需要对客户进行沟通,让其明白,想对于开发团队,项目成功对于客户而言更为重要。而现场客户则是保障项目成功的一个重要措施,想想在你装修房子的时候,你是不是常常在充当现场客户的角色呢?其实这隐喻就是让客户理解现场客户重要性最好的突破口。

    其实现场客户在具体实施时,也不是一定需要客户一直和开发团队在一起,而是在开发团队应该和客户能够随时沟通,可以是面谈,可以是在线聊天,可以是电话,当然面谈是必不可少的。其中的关键是当开发人员需要客户做出业务决策是,需要进一步了解业务细节时能够随时找到相应的客户。

    不过,也有一些项目是可以不要现场客户参与的:

    • 当开发组织中已经有相关的领域专家时。
    • 当做一些探索性工作,而且客户也不知道他想要什么时(例如新产品、新解决方案的研究与开发)。

    去尝试吧,现场客户不仅可以争取得到,而且还能使得团队焕然一新,与客户建立起良好的合作与信任。

    12. 编码标准

    编码标准是一个“雅俗共享”的最佳实践,不管是代表重型方法论的RUP,PSP,还是代表敏捷方法论的XP,都认为开发团队应该拥有一个编码标准。XP方法论认为拥有编码标准可以避免团队在一些与开发进度无关的细节问题上发生争论,而且会给重构、结对编程带来很大麻烦。试想如果有人将你上次写的代码的变量命名法做了修改,下次你需要再改这部分代码时,会是一种什么感觉呢?

    不过,XP方法论的编码标准的目的不是创建一个事无巨细的规则表,而是只要能够提供一个确保代码清晰,便于交流的指导方针。

    如果你的团队已经拥有编码标准,就可以直接使用它,并在过程中进行完善。如果还没有,那么大家可以先进行编码,然后在过程中逐步总结出编码规则,边做边形成。当然除了这种文字规范以外,还可以采用一些如自动格式化代码工具之类的方法进行代码规范。,事实上,你只需要很好地贯彻执行其他的实践并且进行沟通,编码标准会很容易地浮现出来。

    13. 配合是关键

    有句经典名言“1+1>2”最适合表达XP的观点,Kent Beck认为XP方法论的最大价值在于在项目中融会贯通地运用12个最佳实践,而非单独地使用。你当然可以使用其中的一些实践,但这并不意味着你就运用了XP方法论。XP方法论真正能够发挥其效能,就必须完整地运用12个实践。

    转载文章,原文链接 http://www.cnblogs.com/luoht/archive/2011/05/20/2051714.html

     

    展开全文
  • 极限编程XP

    2021-09-19 19:33:46
    极限编程XP)是一种新型的软件开发方法论。他的构想是结合了许多种“程序员真想这么做”的方法而成的。XP的概念于20世纪90年代出现,并已经被从两人工作室到福特汽车等级的大企业所采用。XP的推进力来自于客户会...

    看到书里有这段话,应该是敏捷开发中的,之前没有了解过,先做个记录,之后再深入了解一下。

    极限编程(XP)是一种新型的软件开发方法论。他的构想是结合了许多种“程序员真想这么做”的方法而成的。XP的概念于20世纪90年代出现,并已经被从两人工作室到福特汽车等级的大企业所采用。XP的推进力来自于客户会得到他想要的、想要的时候就能够取得甚至在开发过程变更规格时也是如此。
    XP是由一组被证明有效的实行方法所组成的,这些方法都是被设计来共同运作,但许多人只选择性地实行部分的XP规则。这些方法包括了:
    (1)多次经常性的小规模发布。
    (2)避免加入规格没有的功能(不管“未来”会用到的功能性有多诱人)。
    (3)先写测试用的程序。
    (4)正常工作上下班。
    (5)随时随地重构(refactor),也就是改善程序代码。(注:前提是完善的测试程序)
    (6)保持简单。
    (7)双双结伴进行工作,并经常交换伴侣(不是说那个)以便让大家都清楚全局。

    除此之外还有jini surrogate架构 听起来并不熟悉,现在应该已经不适用了吧,有时间也去了解一下。

    展开全文
  • 近期对敏捷开发进行了相对系统的学习和研究,对于XP、Scrum理解仍旧有些疑惑,通过研究对比将差异总结如下: 1、侧重点不同 Scrum方法(框架)注重管理,建立一个自组织的团队 XP注重实践和实现 2、用户故事 ...

         近期对敏捷开发进行了相对系统的学习和研究,对于XP、Scrum理解仍旧有些疑惑,通过研究对比将差异总结如下:

    1、侧重点不同

           Scrum方法(框架)注重管理,建立一个自组织的团队

           XP注重实践和实现

    2、用户故事

          都通过用户故事的形式来管理需求和交付;

          XP对优先级的要求相对严格,从优先级高的任务开始,完成后再开始下一个用户故事

          Scrum也按照优先级来实现,但根据当前迭代进展,可以适当进行调整

    3、需求变更

           XP更加拥抱变化,对未开始的任务可以进行调整

           Scrum在迭代周期内,不允许需求变更,可以根据迭代的进度,适当增加用户故事

    4、迭代周期

          都注重快速迭代和发布,未严格规定迭代的时间长度

          XP倾向于更短的迭代周期,1-2周

          Scrum倾向于2-4周

    其它:

           敏捷实施过程,两种方法的选择可能不是非此即彼,敏捷实践的方法可能比较模糊,适合项目及团队即可。

    展开全文
  • 极限编程 xp相关资料

    2009-10-29 08:50:19
    极限编程资料 极限编程资料极限编程资料极限编程资料
  • 极限编程XP的关键实践(一)提到 XP 的关键实践,就不得不拿出下面这张图。看着眼熟不?是不是很多内容我们在上篇文章中其实都已经讲过了。没错,可能有些概念你很清楚,但有些概念你就完全没听说...

    极限编程XP的关键实践(一)

    提到 XP 的关键实践,就不得不拿出下面这张图。

    9b67404faeaa1dea8a4a0021e377796b.png

    看着眼熟不?是不是很多内容我们在上篇文章中其实都已经讲过了。没错,可能有些概念你很清楚,但有些概念你就完全没听说过了。今天,我们就来一次性地好好学习一下。

    看到图中的每一环了吗?最里面的是编程方法相关的,中间的是小组实践相关的,最外面的是交付和管理相关的,我们就从内到外逐一学习。

    编程方法(一):结对编程

    一提到结对编程,估计写代码的人都会很感兴趣。但是转念一想:俩人一台电脑,一个写一个看,这个画风是不是有点儿暧昧...咳,这个如果是写代码还好,要是看一些别的什么不好的东西就真的很容易出事了,毕竟我们码农的口味是不好拿捏的。好吧,说正事,两个人一起写一份代码,感觉是很大的浪费呀!确实,也有很多人质疑,而且你在国内不管大小公司,很少能见到真正地实现结对编程的公司。为什么呢?主要就是因为这种做法不太适合我们现在越来越卷的国内的互联网行业,毕竟我们是需要通过不停地加班 996 来实现一个人当两个人用的,怎么可能让两个人去干一件事,这明显违背老板的价值观呀。

    不过,敏捷实践者们既然提出了这个做法,那么也一定是有它的可取之处的。比如:

    • 所有的决定都不是一个人做出的

    • 至少有两个人熟悉系统的每一部分

    • 几乎不可能有 2 个人都忽视的测试或其它任务

    • 改变组合对象(也就是换不同的人结对)可以让知识在组织内更好地传播

    • 代码总在被审查

    • 结对编程的效率比单独编程更高

    其它还有一些优点就不一一列举了。咋眼一看,貌似还不错呀,不过就像前面所说的,在国内,或许有一些极限编程爱好者开的公司会用到,但大部分公司,或者说 99% 的公司中你都见不到。

    编程方法(二):测试驱动开发(TDD)

    想必这个对各位码农来说也不陌生吧,从我们写代码的角度来说,就是先写测试再写代码,然后让我们的代码通过测试之后才算是完成开发。典型的框架就是各种单元测试框架,什么 JUnit、PHPUnit 之类的。这个吧,说实话,我这些年的开发之路上,也没用到过。为什么呢?还是一点,效率略低。不过,这种开发方式最后做出来的产品的质量的确是没话说的。

    当然,要使用 TDD 也是有前提的,第一当然是领导和团队的支持,第二就是团队的编码规范完善,第三就是整体水平还不能太次。因为如果你一开始就把测试写错了,那么写出来的代码也不可能对。另外,如果滥用这些单元测试的话,还会让人走向极端,追求完美的 100% 的测试覆盖率,这也是不可取的。大部分情况下,从 60 分到 80 分,我们可能付出 100 分的努力就可以达到,而从 80 分到 95 分,可能需要付出 500 分的努力。但是从 95 分到 99 分,可能就需要 100000 分的努力,而 99 到 100 ,则有可能是 10 的 N 次方的努力了。当我们陷入到这种情况的时候,往往就会得不偿失。

    TDD 最核心的是去测什么东西呢?在 单元测试 阶段,最需要测的是核心的算法,比如电商项目中的折扣金额之类的计算,返点优惠的计算等。在代码架构中,这些往往是服务层要解决的问题,所以,我们主要测试的目标应该是服务层的代码。

    再从分层架构上来说,控制层分发请求,接收参数,做好效验方面的测试即可。模型层处理数据持久化,一定要注意入库数据的安全性和完整性,做好这方面的测试即可。而服务层,也就是我们公共的计算部分,承担着整个系统的核心,这些才是单元测试真正需要关心的地方。因此,和上方的结论一致,我们最重要的测试内容就是服务层的核心算法或核心逻辑。

    当然,你也可以在控制层写服务,也可以在模型层写服务,总之,找出关键核心的处理业务逻辑和算法的地方,加强这个地方的测试覆盖率,不要盲目的以整体的测试覆盖率为标准,这才是 TDD 能够更好运用的重要方面。

    理论归理论,这方面其实我并没有太多的实战经验,不过我也觉得测试覆盖率不能说明一切,在这里更希望有经验的同学能够分享相关的经验,可以评论里留链接或者加好友转载文章哦!

    编程方法(三):重构

    这个词对于写代码的人来说就更不陌生了,甚至很多人在换到新的公司时,第一个建议就是咱们重构一下老项目的代码吧,因为前人写得太X了。当然,想法总是好的,但现实其实是很残酷的,真正的重构不是说我们要让所有的代码都变成你喜欢的代码。真正的重构是源于敏捷的不断迭代的重构。在收下两种情况下,我们通常会开始重构一段代码。

    1. 实现某个特性之前:尝试改变现有的代码结构,以使得实现新的特性更加容易

    2. 实现特性之后:检查刚刚写完的代码后,看是否能够进一步的优化

    在重构中,有一个重要的概念就是 Don't Repect Your Self 也就是非常出名的 DRY 原则。从开发的角度来说,就是不要让一段相同的代码出现两次。另外,重构还和 XP 中的其它元素紧密相关,比如说代码集体所有制,让代码共享所有人都能看到代码,并且通过结对编程,你的重构也会被别人发现并指出优劣。需要完善的测试驱动开发机制,这样才能确保你的重构不会带来问题。简单的设计,会让你在重构的过程中关注最核心的部分,写出能够实现功能的最简单的代码。

    通过上述内容,其实我们也就保证了 XP 中 勇气 的含义,让你能够勇敢的去重构。

    编程方法(四):简单设计

    还记得 XP 核心思想中的 简单 原则吗?没错,设计是很重要,但是,我们应该从最简单的设计开始,通过迭代和增量不断地完善它,而不是一开始就做出一个复杂的设计来。对于简单来说,并不是说所有的设计都很小,只是说我们需要的是尽可能简单的设计它,让它尽快跑起来,通过持续发布来不断验证和完善。

    之前听说过一个故事,也是程序员间的笑话。一个公司上来就是各种高精尖的技术,各种高并发的处理,引入了一大堆阿里、腾讯的功能架构实践。结果呢?每日最高只有可怜的几百日活。而这个项目做了多久呢?几百人的开发团队,一年的开发时间,最后不了了之。

    还好,目前大部分公司都不会再干这种事。甚至很多公司都会以 MVP(最小可行版本) 的形式来进行新项目的开发。这是好事,也是值得提倡的。那么,在 XP 中,对于简单设计有什么建议吗?

    1. 编写测试代码

    2. 保持每个类只负责一件事(单一职责原则)

    3. 迪米特法则(最少知识原则)

    4. DRY 原则

    5. 简单的设计需要简单的思考,要有勇于重构的勇气和定期重构的习惯

    小组实践(一):持续集成

    持续集成也是我们码农们经常听到的一个名词,甚至不少人也使用并实践过 Jenkins 、Travis CI 这类的持续集成工具。但是你知道吗?这些工具的诞生也正是因为受到 XP 的影响。

    持续集成的关键点是什么?不断的编译整合代码,在你将代码提交到 Git 的时候,测试环境就开始进行单元测试,如果没有通过,那么会报出异常,如果通过了,就会直接打包代码。这样就可以使代码随时保持在可以发布的状态。因此,随时整合,越频繁越好,集成及测试过程的自动化程度越高越好,这就是持续集成的根本概念。

    一般在自营业务的公司,都会有一个固定的代码上线时间,快一点的可能是每周一次。而持续集成期望达到的最低标准是每日集成,也就是每日都能让代码进行上线。当然,依托现代化的这些持续集成工具,其实我们真的可以做到随时提交随时集成并上线。

    小组实践(二):隐喻

    初看 隐喻 这个词感觉很神秘呀,这个玩意是什么意思呢?比较官方的解释是 “隐喻是一种语言表达手段,它用来暗示字面意义不相似的事物之间的相似之处”,用俗语来说,就是将设计模型、开发模式这些关键概念抽象化为一些比喻。就像一个经典的说法,你能给一个完全不懂软件开发的人讲明白数据库是干什么的一样,在这其中,相信你也会使用很多的比喻。比如说,数据库就是一个书店,我们要从这个书店中一个个的书架上找到想要书的,等等等。

    在 XP 中,隐喻的作用主要是加强客户和程序员之间的相互理解,消化积累知识,指导设计的开发方向。具体来说,它可以帮助我们:

    1. 寻求共识

    2. 发明共享词汇(属于我们团队与客户交流的词典)

    3. 创新的重要手段(有时候恰当的比喻能够激发更多的灵感)

    4. 描述体系结构(让抽象的概念更加好理解)

    总结

    今天的内容多吗?还好吧,因为我们的 XP 关键实践有 13 个呢,后面还有一篇文章要继续学习的。不知道大家发现没有,XP 的实践完全是和软件开发密切相关的,这也没办法,毕竟 Kent Back 本身就是一名软件大师。你知道吗?设计模式实践的先行者、《重构》作者 Martin Fowler 的好友同时也为这本书提供了不少内容、XP 和 TDD(JUnit) 的创始人,这一堆名头说的都是他。大家别急,下篇文章我们将继续膜拜大师的作品,继续我们的 XP 之路。

    参考文档:

    《某培训机构教材》

    《用户故事与敏捷方法》

    《高效通过PMI-ACP考试(第2版)》

    《敏捷项目管理与PMI-ACP应试指南》

    5a17ea559989acc2f32c5b24f8526699.png

    展开全文
  • 对比十几种软件开发模型 瀑布模型 演化模型 螺旋模型 喷泉模型 快速原型模型 智能模型 混合模型 敏捷开发 极限编程XP
  • XP的核心实践:整个团队、规划游戏、小规模发布、客户测试、收集代码所有权、编码标准、一致的节奏、隐喻、持续集成、测试驱动开发、重构、简单设计、结对编程。 转载于:...
  • 极限编程 XP PPT

    2008-04-21 13:18:23
    Extreme Programing
  • 极限编程(Extreme Programming,XP)是一个敏捷软件开发框架,旨在开发更高质量的软件,专注编程技术、清晰沟通还有团队协作的实践。XP是关于软件开发工程实践的最具体的敏捷框架。XP中极限的含义是尽力而为,然后...
  • 文章目录敏捷方法1 极限编程1.四大价值观2.十二个最佳实践2 特征驱动开发1.FDD 角色定义2.核心过程3.最佳实践3 Scrum1.Scrum 的五个活动2.Scrum 的 5 大价值观4 水晶方法5 其他敏捷方法开放式源码ASD 方法 ...
  • 极限编程 XP xp简介

    2008-09-16 09:08:50
    一个略微描述了极限编程xp的PPT,和xp的一些发展。
  • 1.极限编程(Extreme programming,缩写为XP),是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。极限编程鼓励管理人员和开发人员接受并使用某些特别的有价值的方法。 2.极限编程的创始者是肯特·贝克、...
  • 重构极限编程XP的实践与反思 书籍语言:简体中文 书籍类别:JAVA教程 整理时间:如题描述 资料格式:CHM格式
  • 极限编程XP一提到 XP ,很多人的第一反应是微软的那个操作系统。没错,XP 似乎已经是它的代名词了。但是,在敏捷领域,也有一个 XP ,而且也是一样的如雷贯耳。那就是传说中的 Extre...
  • XP概述 XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、...XP就是在这样的情况下诞生的,它是灵巧的轻量级软件开发方法,它跳出复杂的流程和文档,而是以轻量的框架和极限的思想为核心进行开发。 这里讲的极限
  • 极限编程XP)的优缺点是什么?

    千次阅读 2020-04-13 19:28:05
    极限编程XP)是一种敏捷方法 ,被认为是软件开发中最有效的方法之一。 它以测试优先的开发方案运行。 它具有短期计划,同时高度适应需求的变化,并且由高生产率的团队组成,这些团队可以快速而有效地生产高质量的...
  • 敏捷项目管理(SCRUM+看板+极限编程XP) 多年项目管理实战经验,多项项...
  • 极限编程XP的关键实践(二)首先,我们依然是从这张图开始。上篇文章中,我们已经学习过的内容是最里面的那一圈的,也就是编程方法相关的四个内容,另外还加上中间那一圈的两个内容。本来我是计划一篇...
  • Matt Stephens 对风靡一时的极限编程--XP进行的实践与反思,抽取XP中可重构的部分,以更加健壮的方式实现同样敏捷的目标,值得一看!
  • 极限编程XP 笔记

    2012-12-23 14:10:01
    极限编程是轻量级的软件开发方法,它的价值观是交流、简约、反馈和勇气,即一个开发过程可以从四个方面改进:加强交流,从简单做起,寻求反馈,用于实事求是。基本特征如下:  1. 极限的工作环境  2. 极限的需求...
  • Scrum和XP极限编程

    2019-08-01 15:06:35
    近年来,软件开发领域内,敏捷方法大行其道,在各个公司内弄得风生水起,逐渐...不过,在接触Scrum之初,不免有些疑惑:同时敏捷方法,它和XP极限编程)是什么关系呢? 一段时间接触下来,发现这两者之间关系也比...
  • 极限编程(XP)12个最佳实践 现场客户 ( On-site Customer ) 代码规范 ( Code Standards ) 每周40小时工作制 ( 40-hour Week ) 计划博弈 ( Planning Game ):要求结合项目进展和技术情况,确定下一阶段要开发与发布的...
  • 极限编程是敏捷开发的一种方法,极限编程针对小型的开发团队来说是一个不错的方法,极限编程本质是务实主义的体现,快速稳定的实现每一个用户要求,是极限编程的基本要求。 1.客户尽量和开发人员在一起,一是可以...
  • 极限编程(XP)12个最佳实践

    千次阅读 2017-03-29 11:43:50
    极限编程、敏捷开发的十二个原则
  • 2、极限编程(Extreme Programming,XP)是一门针对业务和软件开发的规则,它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论,XP使开发者能够更有效的...
  • 1. 坐在一起(Sitting Together)   尽可能让团队成员坐在一起,Kent Block在一次芝加哥的某个濒临困境的项目中...3. 结对编程(Pair Programming)     转载于:https://www.cnblogs.com/davidgu/p/3464031.html
  • 极限编程XP)是一种软件开发方法。其关键概念在于将你的整个团队聚集在一起。XP的核心思想是敏捷编程,即快速,灵活和迭代式的开发。小组在遇到特定的情况时通过收集足够的反馈而决定解决方针。XP十分适合规模较小...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,462
精华内容 3,784
关键字:

极限编程xp