2017-07-12 11:58:27 a958832776 阅读数 267
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

之前一直接触极限开发和敏捷开发,但是具体说说他们的含义与联系时就有点尴尬了,不知道如何描述了。于是就静下心来好好整理整理。

介绍

2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值 观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

极限编程

    设计和编程都是人的活动。忘记这一点,将会失去一切。      

                                                             -- Bjarne Stroustrup   

极限编程(XP)是敏捷方法中最著名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

敏捷开发

   人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。

                                                            -- Tom DeMacro和Timothy Lister

    敏捷软件开发宣言:

    个体和交互     胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作       胜过 合同谈判
    响应变化       胜过 遵循计划

保持设计尽可能的干净、简单,并使用许多单元测试和验 收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的 设计。

这里只是了解大概的关系,具体的需要自己去实现。

2017-03-30 22:10:51 HQ354974212 阅读数 1894
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

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

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


2010-03-16 22:56:00 liyangbing315 阅读数 8177
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师

敏捷开发与极限编程

简介

      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)

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2015-05-13 21:16:02 josonchen 阅读数 213
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10408 人正在学习 去看看 CSDN讲师
什么是敏捷开发?

一种以人为核心、迭代、循序渐进的开发方法。

什么是敏捷开发?

一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。

通过这项工作,他们认为:


·个体和交互 胜过 过程和工具

·可以工作的软件 胜过 面面俱到的文档

·客户合作 胜过 合同谈判

·响应变化 胜过 遵循计划

 


并提出了以下遵循的原则:


我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。

在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。

责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

最好的构架、需求和设计出于自组织团队。

每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。


参看《敏捷开发横空出世




极限编程(XP)是一种轻量级的软件开发方法论,XP从实践中来,是对实践的总结,也是经过实践检验的,其主要特征是要适应环境变化和需求变化,充分发挥开发人员的主动精神。XP承诺降低软件项目风险,改善业务变化的反应能力,提高开发期间的生产力,为软件开发过程增加乐趣,相信这些足以吸引每个人的眼球。

在XP的项目开发中,首先引入了四个变量:成本、时间、质量和范围,通过研究变量之间的相互作用,将项目开发分析的更加透彻,成功讲述一个项目成功的原则。

为了能成功地实施XP,XP制定四个准则:沟通、简单、反馈和勇气

和十二条原则:计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40小时、现场客户、编码标准

以及对开发人员的工作要求:编码、测试、倾听和设计。

XP是一个非常庞大的知识库,每一项都是一门值得深究的学问。提出这些要求和原则后,XP有提出了一系列的解决方案,也就是策略,其中包含:管理策略、设施策略、计划策略、开发策略、设计策略和测试策略。在真正去实现XP时,XP又提供了将策略成功应用的实践。可以说XP为你的软件开发的指导老师。

XP是从实践中来的,应此有好多人围绕XP发表了一些自己的实践经验,其中主要包括:测试驱动开发、结队编程、重构和极限编程工具。

参看《敏捷开发的七种武器

对敏捷设计的认识: http://jigee.cnblogs.com/archive/2006/06/25/435113.html

极限编程与敏捷开发: http://tech.acnow.net/Html/Program/soft_project/SoftProcess/2005-8/7/23175325.shtml

敏捷软件开发(上篇) http://sd.csdn.net/n/20060809/93506.html
敏捷软件开发(中篇) http://sd.csdn.net/n/20060809/93507.html
敏捷软件开发(下篇) http://sd.csdn.net/n/20060809/93508.html


来源:http://www.cnbruce.com/blog/showlog.asp?log_id=1015

2014-01-19 00:13:00 zs15932616453 阅读数 3697
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

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

1、介绍

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

2、实践

       1)、客户作为团队成员

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

       2)、用户素材

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

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

       3)、短交付周期

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

       4)、验收测试

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


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


未完待续……

敏捷开发

阅读数 749

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