敏捷开发xp_敏捷开发 xp - CSDN
  • 敏捷开发XP

    2015-09-25 11:15:11
    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于: 在更短的周期内,更早地提供具体、持续的反馈信息。 在迭代的进行计划编制,首先在...

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

    在敏捷方法论领域中,比较知名的、有影响力的,是拥有与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

    2019-06-25 01:35:55
    一、组建XP团队 在XP团队中,由以下组成 二、项目相关环境 1、利益相关者:与PM一样,对项目进行管理 2、执行发起人:最终客户(必须定期演示) 三、XP组成 四、思考 1、结对编程 结对编程中,一...
    一、组建XP团队
    在XP团队中,由以下组成
     
     
    二、项目相关环境
    1、利益相关者:与PM一样,对项目进行管理
    2、执行发起人:最终客户(必须定期演示)
     
    三、XP组成
    四、思考
         1、结对编程
         结对编程中,一个人写,一个人思考。结对编程可以防止被打扰,可以提高精力
         2、精力充沛的工作
         按时下班,不把工作带回家,健康饮食,经常锻炼。
         3、信息化工作场所
         通过各种信息(图表等)贴在工作场所,以随时了解项目进度、当前情况,同时通过图表监控、测评项目。
         4、根源分析
         遇到问题不要想责备,问自己为什么会出现这个问题,寻求问题根源
         5、回顾
         在一次会议中引导一个人说过话,那么他继续说话的可能性就会加大
     
    五、协作
    1、信任
         团队内部需要和谐团结,与客户(关系人)的关系弄好。可以采用:客户与程序员换位思考、程序员与测试员换位思考、共同进餐、团队持续性(以团队为单位做项目)。坦然面对错误,及早与关系人坦白困难、错误,共同面对问题。定期交付,维护与关系人的关系。
    2、坐到一起
         团队的所有成员需要在同一个场所办公。现场客户、程序员、测试员等。这样可以及时交流、高效沟通。但是也提供一个私密的小房间供打电话、聊天等。
    3、真实客户参与
         有了真实用户的参与,就不会让自己陷入各种细节。扩大自己的视角。利用他们在实际中如何使用软件、他们的领域知识,可以让你交付一款真正有用的产品。
    4、统一协作语言
         采用同一种语言,可以较少程序员与客户专家的沟通障碍。比如程序员采用客户领域的术语进行图表的绘制、命名。
    5、站立会议
         在一个固定的时间召开。每次不要超过十分钟。时间不一定在早上,可以上午结束的时候。会议由每个人讲需要让整个团队知道的事情。可以以“我昨天做了什么、今天打算做什么、遇到了什么问题”的格式,也不一定得按照这个格式。
    6、编码规范
         编码的规范可以包含:开发实践、工具和快捷键、文件和目录布局、构建和约定、错误处理和断言、实践和日志记录方式、设计约定等。规范的设计,以“1、指定可以接受的最小标准集合 2、关注一致性和共识,而不是完美”。
         在制定规范后,如果有人没有按照规范,可以和他谈:认为这个规范怎么样,为什么没有按照规范。
    7、迭代演示
         迭代演示可以降低风险,增加活力,促进团队进步。XP的核心就是定期交付。在演示的过程中,可以解释为什么和原计划不同,有什么变化。若客户具体到某一细节,可以说在演示结束后由项目经理解释。在演示结束后问客户:1、到目前为止客户是否满意。2、是否可以继续。如果在演示中,客户提到需要添加新特性,则说:会后由产品经理负责特性的把关与添加。
    8、汇报
         进行良好的汇报,可以增加客户对团队的信任,更相信团队的决策。
         进展汇报:愿景陈述、每周演示、发布和迭代计划、burn-up图。如果需要更详细,可以提供路线图   、状态电子邮件
         管理汇报:生产率、产能、缺陷、时间利用率
         不要汇报:源代码行数、故事数、开发速度、代码质量等
     
    六、发布
    1、全部完成
         全部完成是指可以发布使用。平时以全部完成来要求团队,可以避免大量难以预计的收尾工作。完成包含测试完成、编码完成、设计完成、集成完成、成功构建、安装、移植、评审完成、修复完成、用户接受。TDD可以促使设计、测试、编程同步完成。
    2、没有bug
         a.编写更少的bug:采用TDD,可以减少一定bug。或者通过大量技术和组织方法尽量减少bug的生成。
         b.消除bug的温床:通过重构设计不良的代码可以减少bug
         c.修复bug:尽早修复bug,越到最后代码修复的成本就越大。
         d.测试过程:通过探索性测试,以不寻常的方式进行测试,可以检测预料之外的bug
         e.修正过程:对自己进行总结,查找为什么会出现bug,对自己的编码过程就行改正。
    3、版本控制
         版本控制可以管理项目,可以进行回退等
    4、十分钟构建
         自动化构建,可以避免很多问题。可以利用ant、make等进行构建。当项目在很小的时候进行自动化构建。尽量不要让构建的时间太长。
    5、持续集成
         持续集成能够减少很多隐藏的发布时间。每隔几小时进行集成,保证构建、测试及其他发布的基础组件都能及时更新。这样可以降低发布难度。
    6、代码集体所有制
         这样可以让整个团队为所有代码复制。每个人都可以改进别人的代码。这样可以在一个人离开时,团队还能继续推进。实在无法实施集体所有制,可以通过结对编程折中。
    7、文档
         文档不用很多,但是因为有更好有效的交流方式,不是偷懒的借口。不需要特定去做什么文档,如果一些文档有商业价值,将其安排为一个user story进行操作。
     
    七、计划
    1、愿景
         揭示项目正在朝哪个方向前进,以及为什么朝这个方向前进。制定愿景时,可以从:项目应该完成什么、项目为什么有价值、项目的成功标准是什么。愿景指定后就推广出去,贴在工作场所,要求客户一同参与愿景指定。如果有了一份清晰、有说服力的远景,则很容易为故事安排优先级。同时团队成员了解项目的重要程度,有助于提高士气。
    2、发布计划
         在接受项目时,尽量只做一个项目,不要几个一起做。同时尽早发布,经常发布,将最有价值的特性先发布出去,有助于提升商业价值。在发布的时候,不要全部把所有的发布出去,为自己留一些余地,不要一次性全部发布。计划需要不断调整,让客户清楚你的计划。可以以时间为标准进行计划。
    3、计划博弈
         在计划生成后,对计划的具体安排需要讨论。在对计划进行实施时,良好的计划博弈,是让程序员觉得自己的专业知识对计划进行了贡献,客户觉得自己的领域知识做出了优先级划定。
    4、风险管理
         随时对风险进行把控、预测、应对。及时当开发中断也能成功交付,这样以后公司会更加信任你。
    5、迭代计划
         每次选择最后价值的特性加入其中进行迭代。一次迭代,由:演示演一轮迭代、回顾前一轮迭代、制定迭代计划、承担故事的交付、开发故事、准备发布。一般在一周完成。在发布了迭代任务后,对任务进行跟踪。
    6、松弛
         在迭代中添加松弛制度,增加研究时间,不要太紧。
    7、故事
         以用户为中心,用一个个卡片来整理故事。太大的故事进行拆分。故事由客户进行把关。同时也可以包含文档故事、非功能故事、bug故事、试验故事、估算、会议等。将故事分小,可以频繁交付完整特性。
    8、估算
         做良好的估算,在每次迭代中都是一致和可预测的。估算时,对故事进行充分分析和挖掘。
     
    八、开发
    1、增量式需求
         客户可能开始不能确定全部的需求,不用担心。那就开始在已经确定的上面工作。但是客户的每次反馈都需要记录,客户签字,防止客户否认
    2、客户测试
         对于每个特性,创建客户测试可以通过描述、演示、开发进行。描述是由客户详细、举例描述功能。让用户领导进行客户测试,引导他们参与
    3、测试驱动开发
         在开发前先写测试,这样你在开发时,会自动对你的开发过程进行把控
    4、重构
         在平时对代码进行重构,持续提高代码质量
    5、简单设计
    6、增量设计和架构
    7、试验方案
    8、性能优化
    9、探索性测试
     
    XP的价值:简单、勇气、沟通、反馈、尊重。
    在实践中避免浪费,若项目一定会失败,则尽早失败。

    转载于:https://www.cnblogs.com/ren-jie/p/5256409.html

    展开全文
  • 研一学习了软件工程中的敏捷开发,现在再次回顾一下,以防以后遗忘和查看。 一、关于敏捷 1.敏捷是什么? 过程和方法对于项目的结果只有次要的影响。首要的影响是人。 软件工程师有共同的观点:唯一真正重要的工作...

    研一学习了软件工程中的敏捷开发,现在再次回顾一下,以防以后遗忘和查看。

    一、关于敏捷

    1.敏捷是什么?

    过程和方法对于项目的结果只有次要的影响。首要的影响是人。

    软件工程师有共同的观点:唯一真正重要的工作产品是在合适时间提交给客户的可运行软件增量

    2.敏捷联盟宣言

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

    二、极限编程实践
    极限编程(eXtreme Programming)是敏捷方法中最著名的一个。它由一系列简单
    却互相依赖的实践组成。这些实践结合在一起形成了一个敏捷开发过程。
    1、极限编程实践
    ●完整团队
    XP项目的所有参与者(开发人员、业务分析师、测试人员等等)一起工作在一个开放的场所中,他们是同一个团队的成员。
    这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
    ●计划游戏
    XP习惯把一次迭代发布的内容称之为“ planning‏game”,在迭代之处确认阶段称为“ Iteration‏Planning‏Game”迭代计
    划游戏,而确认可发布内容范围称为“ Release PlanningGame”发布计划游戏;
    计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
    ●客户测试
    作为选择每个所期望的特性的一部分,客户定义出自动验收测试来表明该特性可以工作。首先XP希望对于所开发的
    代码都要有单元测试、通过持续的集成和测试来保证代码的质量。 XP的测试一般特别指功能上的自动测试,和客户的验
    收测试;
    ●简单设计
    团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想
    表达的所有东西,并且包含尽可能少的代码。由于XP方法的特征,无法全面把握用户的最终需求,
    所以不对不存在的功能做猜测,在代码层面简洁、尽量的小粒度的类或方法;
    ●结对编程
    所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。开发两人可以互为观察员
    和开发者,这样写出的代码具有较少的缺陷,相互学习使得代码具有更好的可读性
    ●测试驱使开发
    程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。测试用例循序渐进的对代码的编写进行指导。
    ●改进设计
    随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。
    ●持续集成
    团队总是使系统完整的被集成。单独服务器对所有代码进行不间断的功能构建
    ●集体代码所有权
    任何结对的程序员都可以在任何时候改进任何代码
    ●系统隐喻
    为了便于设计沟通, XP开发设计人员和客户用约定的方式来描述特定的系统功能 。
    ●可持续的速度
    团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力,他们把项
    目看做是马拉松长袍,而不是全速短跑。所有的预定工作都应在工作时间内完成,个人
    时间和工作时间应该有清晰的分界,不能相互影响,提倡“没有加班”;
    ●编码标准
    系统中所有的代码看起来就好像是被单独一个非常值得信任的人编写的。

    2、计划游戏
    2.1 初始探索
    ●在项目开始时,开发人员和客户会尽量确定出所有真正重要的用户素材。然而,他们不会试
    图去确定所有的用户素材。开发人员对素材进行估算
    ●分解、速度和探究。
    2.2 发布计划
    ●客户根据开发速度确定每个素材的成本,再根据每个素材的商业价值和优先级别做出最优选择。

    让客户来选定那些会给他们带来最大利益的素材,属于商务决策范畴。
    ●开发人员和客户对项目的首次发布时间达成一致后客户挑选发布中他们想实现的素材,大致确定素材的顺序。
    2.3 迭代计划
    ●开发人员和客户决定迭代规模。客户决定首次迭代中要实现的素材。
    ●迭代期间用户素材的实现顺序属于技术决策范畴,开发人员采用最具技术意义的顺序来实现这些素材。
    ●迭代开始后客户不能再改变该迭代期内需要实现的素材。
    ●迭代要在指定的日期内结束,合计所有已经完成的素材估算值,计算本次迭代的开发速度,用于计划下一次迭代。
    2.4 任务计划
    ●开发人员在客户帮助下尽可能把素材分解成开发任务
    ●开发人员逐个签订他们想要实现的任务,并以任务点数对那项任务进行估算。
    ●迭代的中点: 在迭代进行到一半时,应该完成本次迭代中所安排的半数素材。
    2.5 迭代
    每两周,本次迭代结束,下次迭代开始。每次迭代结束时会给客户演示当前可以运行
    的程序,要求客户对程序的外观、感觉和性能进行评价。客户会以新的用户素材的方式提供反馈。
    2.6 结论
    ●通过一次次迭代和发布, 项目进入了一种可以预测的、舒适的开发节奏。
    开发人员看到的是他们自己估算、自己度量的开发速度控制的合理计划。选择舒适的任务并保持高的工作质量。
    管理人员从每次迭代中获取数据,使用这些数据来控制和管理项目。
    ●使用敏捷方法并不意味着客户一定可以得到他们想要的。它只不过意味着他们能够控制着团队以最小的代价获得最大的商业价值。

    三、 Scrum
    Scrum 软件开发模型是敏捷开发的一种。 Scrum的基本假设是:开发软件就像开发新产品,无法一开
    始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保
    证专案成功。
    Scrum 开发流程通常以 30 天(或更短时间)为一个阶段,由客户提供新产品的需求规格开始,
    开发团队与客户于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于 30 天后交付成果,
    团队每天用 15 分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除。
    1、 Scrum一些基本概念
    ● backlog: 可以预知的所有任务, 包括功能性的和非功能性的所有任务。
    ●sprint:一次跌代开发的时间周期,一般最多以30天为一个周期.在这段时间内,开发团队需要完成
    一个制定的backlog,并且最终成果是一个增量的,可以交付的产品。
    ●sprint backlog:一个sprint周期内所需要完成的任务。
    ●scrumMaster: 负责监督整个Scrum进程,修订计划的一个团队成员。
    ● time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。
    ●sprint planning meeting: 在启动每个sprint前召开。一般为一天时间( 8小时)。该会议需要制
    定的任务是:产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需
    要完成多少小功能模块,确定好这个ProductBacklog的任务优先级。另外,该会议还需详细地
    讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
    ●Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报
    三个项目:
    今天完成了什么? 是否遇到了障碍?即将要做什么?通过该会议,团队成员可以相互了
    解项目进度。
    ●Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product
    Owner和其他相关的人员。一般该会议为4小时。
    ●Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内
    部人员。一般该会议为3小时。
    2、 Scrum过程
    ●将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前人力物力条件可以完成的。
    ●召开sprint planning meeting,划分,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给
    每个成员。注意这里的任务是以小时计算的,并不是按人天计算。
    ●进入sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。
    ●整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner.
    ●团队成员最后召开Sprint retrospective meeting,总结问题和经验。
    ●这样周而复始,按照同样的步骤进行下一次Sprint






    展开全文
  • 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要...

    敏捷开发之Scrum扫盲篇

    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...

     

    为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

     

     什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

     

    为什么说是以人为核心?

    我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

     

    什么是迭代?

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

     

    关于Scrum和XP

    前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

     

    什么是Scrum?

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

    而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

     

    【Scrum开发流程中的三大角色】

    产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

     

    流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

     

    开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

     

     

    Scrum流程图

     

    //------------------------

    下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

    什么是Sprint?

    Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

     

    如何进行Scrum开发?

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

    3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

     

     

    下面是运用Scrum开发流程中的一些场景图:

    上图是一个 Product Backlog 的示例。

     

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。



    任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


     

    每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

     

     

     上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

    怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...



    敏捷开发中XP与SCRUM的区别


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

    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


    展开全文
  • 极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。 1. 计划游戏 ( Planning Game )  (1)快速制定计划、随着细节的...

    极限编程(eXtreme Programming,简称XP)是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。


    1.  计划游戏 ( Planning Game )

        (1)快速制定计划、随着细节的不断变化而完善;

        (2)详解:要求结合项目进展和技术情况,确定下一阶段要开发与发布的系统范围。当计划赶不上实际变化时就应更新计划。

    2.  小型发布 ( Small Release )

        (1)系统的设计要能够尽可能早地交付;

        (2)详解:强调在非常短的周期内以递增的方式发布新版本,从而可以很容易地估计每个迭代周期的进度,便于控制工作量和风险;同时,也可以及时处理用户的反馈。

    3.  系统隐喻( System Metaphor )

        (1)找到合适的比喻传达信息;

        (2)详解:通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。

    4.  简单设计( Simple Design )

        (1)只处理当前的需求使设计保持简单;

        (2)详解:任何时候都应当将系统设计的尽可能简单。不必要的复杂性一旦被发现就马上去掉。

    5.  测试驱动( Test-driven )

        (1)先写测试代码再编写程序;

        (2)详解:程序员不断地编写单元测试,在这些测试能够准确无误地运行的情况下开发才可以继续。

    6.  重构( Refactoring )

         (1)重新审视需求和设计,重新明确地描述它们,以符合新的和现有的需求;

         (2)详解:代码重构是指在不改变系统行为的前提下,重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。

    7.  结对编程( Pair Programming )

         (1)由两个程序员在同一台电脑上共同编写解决同一问题的代码。

         (2)详解:通常一个人负责写编码,而另一个负责保证代码的正确性与可读性。 

    8.  集体所有权(Collective Ownership)

        (1)任何人在任何时候都可以在系统中的任何位置更改任何代码。

        (2)详解:每个成员都有更改代码的权利,所有的人对于全部代码负责。

    9.  持续集成( Continuous Integration )

        (1)可以按日甚至按小时为客户提供可运行的版本;

        (2)提倡在一天中集成系统多次,而且随着需求的改变,要不断的进行回归测试,避免了一次系统集成的恶梦。

    10.  每周工作40小时 ( 40-hour Week )

        (1)要求项目团队人员每周工作时间不能超过40小时,加班不得连续超过两周,否则反而会影响生产率。

    11.  现场客户( On-site Customer )

         (1)在团队中加入一位真正的、起作用的用户,他将全职负责回答问题。

         (2)详解:要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试。

    12.  编码标准( Code Standards )

          (1)强调通过指定严格的代码规范来进行沟通,尽可能减少不必要的文档。

    展开全文
  • 敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量,不但不...
  • 敏捷开发(XP)的宗旨:“崇尚个人和交流而不是过程和工具;崇尚软件开发而不是文档;崇尚客户合作而不是合同条款;崇尚随需应变而不是简单计划”。如果我们把敏捷开发定式化成某种过程或者工具集合,实际就呆板...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • TDD,Test-driven development,测试驱动开发TDD产生远敏捷开发运动,特别是极限编程(extreme programming , XP),而TDD正是XP的一个核心原则。TDD人认为,不应该完成开发之后再写测试,这通常只是“马后炮”,而...
  • 2001年的时候,17位大牛发布了敏捷宣言,从此敏捷作为一个带有特殊含义的名词慢慢为人们所接受。有趣且少有人提及的是,这17位大牛经过三天的讨论后,发布的仅仅是敏捷宣言和原则,却没有指明落地的方法和工具。  ...
  • 瀑布式开发、迭代开发、敏捷开发XP与SCRUM的区别 瀑布式开发、迭代开发,区别【都属于,生命周期模型】  两者都是一种开发模式,就像设计模式一样,考虑的角度不一样,个人感觉谈不到取代一说。  ...
  • 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别,     Scrum and Extreme Programming (XP) are definitely very aligned. In fact, if you walked in on a team doing one of these ...
  • XP敏捷开发的关系

    2014-08-27 16:41:01
    原来XP编程(极限编程)是敏捷开发的一种,而且敏捷开发的思想对于现在大多数的软件开发,都很适合。下面我就把这篇文章贴出来,与大家 分享 。  在按照我的理解方式审查了软件开发的生命周期后,我得出一个...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 20169205实验三 敏捷开发XP实践 实验内容及步骤 (一)敏捷开发XP基本知识 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 一项实践在XP环境中成功使用的依据通过XP的法则呈现,...
  • 敏捷开发流程总结

    2015-12-14 16:36:10
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...
1 2 3 4 5 ... 20
收藏数 11,579
精华内容 4,631
关键字:

敏捷开发xp