2014-03-28 08:45:51 happylee6688 阅读数 12296
上篇文章中,我们探讨了什么是XP极限编程,以及极限编程的管理思想、核心价值观等等。在敏捷开发之旅的第三站,我想要和大家一起分享FDD特征驱动开发方法。

特征驱动开发——Feature Driven Development

还是老规矩,讨论之前,我们先了解一下什么是Feature?什么是FDD?

Feature


在FDD中,Feature(特征)是一个基本的开发单位,是(FDD)项目中的一个增量,是指用户眼中最小的有用的功能,可以在很短时间内实现(一般在两周之内)。
  • 特征是小的
特征之所以是小的,是因为他可以在两周之内实现,任何一个过于复杂而无法在两周之内完成的功能,可进一步呗分解小到足以被称为一个特征。使特征小一些也意味着客户能经常看到可测量的进度。
  • 特征是具有客户价值的
在业务系统中,一个特征映射到业务过程中某些活动的一个步骤。在其他系统中,特征等同于由用户完成的一项任务中的一个步骤。

FDD


特征驱动开发(FDD),是敏捷开发方法中的一种,他来源与新加坡的一个大型软件开发项目,由著名软件专家Jeff de Luca 、Eric Lefebvre、Peter Coad共同提出的。它强调特征驱动,快速迭代,即能保证快速开发,又能保证适当文档和质量。

他提出的每个功能开发时间不超过两周,为每个用例user case限定了粒度,具有良好可执行性,也可以对项目的开发进程进行精确及时地监控。他抓住了软件开发的核心问题领域,即正确和及时地构造软件。

FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来,直接参与到开发人员和用户所从事的系统构造工作中。

开发过程


FDD方法包括5个过程,其中的按照功能设计和构建是反复的迭代过程。



  • 开发整体模型
这是FDD开始一个项目的初始工作,在主设计师的指导下,带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求,然后使用四色原型进行域建模。我个人认为,在此阶段中,能够得出系统的架构设计图。
  • 构建功能列表
这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分,将整个领域分成一定数量的区域(主要功能集),每个区域再细化为一定数量的活动。活动中的每一步被划分称为一个功能。形成了具有层次结构的分类功能列表。个人认为,在此阶段中,能够形成系统的概要设计。
  • 计划功能开发
项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的复杂性,计划实现功能的顺序,完成一个功能开发计划。它提供了对项目的高层视图,让业务代表了解功能开发、测试和发布日期,以便业务代表和部署小组能够计划交付哪些功能的日期。本阶段的主要成果是,能够形成项目开发计划。
  • 按照功能设计
项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计,得出分析模型、设计模型。由于一次设计并不全面,因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了:详细设计、项目里程碑计划等。
  • 按照功能构建
按照设计进行编码实现,由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评审。在测试和检查通过后检入到配置管理库中进行构建。第5和第4 阶段是一个迭代的过程,迭代周期一般为2个星期。这样经过不断的迭代,不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑 的继续,直到最后项目的完成。

最佳实践

  • 领域对象建模
是对象分解的一种形式,主要包括构造类图,用于描述问题领域中重要对象的类型及其相互关系,为系统设计提供了一种整体框架,使得系统可以按照特征迭代增量地进行开发。
  • 按照特征开发
按照一组小功能、对客户有价值的功能列表进行开发并跟踪过程。FDD将需求问题分解成可以解决的小问题,对每个问题分解为分层列表的功能需求,即特征。然后,开始设计并实现每一个特征。一旦系统的功能特征被标识以后,它们通常在FDD方法中用于驱动和跟踪开发过程。
  • 类(代码)拥有权
FDD规定每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。FDD方法采用的开发技术是面向对象,类定义一个单一的概念和实体,最合适作为最小的代码分配要素,代码的所有权即为类的所有权。
  • 特征小组
FDD把类即特征分配给一个确定的开发者。由于一个特征的实现会涉及到多个类及其所有者,因此,特征的所有者(特征组长)需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别:特征小组的组长更像是教练而不是超级程序员。
  • 审查
指的是检查软件错误的复审方法,这是FDD确保软件设计和代码质量的一个关键技术。审查将开发小组和FDD以主程序元为主的结构完美地结合起来,这种混合是一种新型的开发方式。
  • 定期构建
定期地取出已完成功能的全部源代码和它所依赖的库、组件,组成完整的可以运行的系统。构建增加功能的基线,确保总是有一个可以运行、向客户演示的软件系统,可以使客户观察到系统开发的进度和实现的功能是否是需要的。
  • 配置管理
一个FDD项目只需要保证对完成的代码文件最新版本的确认和历史追踪。根据开发软件的复杂性,分析制品、设计制品以及测试用例、测试脚本等也应该受控于版本控制。
  • 可视性进度报告
项目成员应该根据完成的工作向各级管理报告工作进度,FDD提供了一个简单、低开销地收集准确和可靠项目信息的方法,提供了大量直观、直接的报告样式,向项目所有相关人员报告项目进度。

与XP的比较

  • 隐寓和模型
XP过程以在卡片上记录故事开始业务分析。每个故事就是系统要做的事情。整个项目在“每个人——客户、程序员和经历——能够讲出系统如何工作的整体故事”隐寓的指导下进行的。

FDD使用特征,执行领域走查,同时要建立一个全面的领域对象模型,以便特征小组对每一组特征产生更好的设计。
  • 开发团队
在开发队伍规模上,XP通常不超过10人;FDD的理想团队成员数在16~20人,也有更大团队的实际经验。
  • 代码拥有权
XP鼓励集体拥有代码,任何人都可以在需要时添加或修改代码。与之相反,在FDD中,整个开发团队拥有代码的集体所有权。当需要集体验证譬如说软件架构的设计或用户界面构造的时候,FDD就将类所有者与特征小组和审查结合起来满足需要。
  • 测试
XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。FDD则提倡采用结构化的形式化审查技术。

XP中的正确性是由运行单元和功能测试来定义的。在FDD中,单元测试是“按照功能构建”过程的一个部分。FDD没有定义参与测试的形式化等级,由主程序员决定做什么更适合。
  • 项目追踪
XP让项目经理决定项目追踪方法,鼓励减少数据搜集的工作量,鼓励使用大型图表。在FDD中的按特征追踪项目的方法,描述了工作量小、准确度量项目进度的手段,提供了用数据构造多种使用的进度图表。

结束语


作为敏捷开发的方法之一,特征驱动开发很好的实现了敏捷的思想,它强调的是整体模型,是从全局观的角度考虑问题的。同时,我们也要认识到一点,特征驱动开发相对于其他的方法,还是比较复杂的。其方法的精致和结构的规整,很容易让使用者在本身固有的重型思维方式的引导下,走入于agile背道而驰的泥坑。这本身也是其复杂性的一个表现。

因此,要想使用FDD并不容易,但不可否认的一点,FDD的确是一种非常好的敏捷开发方法论。而它具体的实施效果最终还是要看领导者以及实施者、使用者的具体实践。


2010-09-24 16:33:00 bihailan123 阅读数 660

 今天浏览51testing,有个讨论是“敏捷开发中,测试人员的工作成绩如何体现”,想想我们公司的项目不就是敏捷开发吗?需求不确定,经常改,做的差不多了,产品就交付,用户再提意见,再修改。看到有个人的回答比较好,引入过来,怕以后找不到了。

敏捷方法在软件开发中受到青睐,特别是在互联网应用服务系统的开发中,越来越多的公司采用敏捷方法,包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别,但基本思想是一致的,如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中,流程相对灵活,强调沟通,通过充分的沟通来及时解决问题,由于沟通充分,文档不是很重要,而且有可能不采用Word等独立的文件格式,而是采用Wiki、空间等web内容方式。在敏捷方法中,需求变化比较快、产品开发周期很短(一、两周),给软件测试带来很大的挑战!例如,功能测试的自动化实现就比较困难,没有足够时间开发自动化测试脚本,要花大量时间讨论产品特性,及时进行产品的验收测试。自动化测试,更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践,开发人员能发挥更大的作用,而测试人员难以很好地发挥作用。在敏捷方法中,开发人员的主导作用更明显,讨论需求、实现需求,再修改需求、再实现、再重构,不断完善产品,测试人员容易边缘化。甚至在Crystal方法中,可以不需要测试人员,开发人员能承担所有技术性的工作。
在敏捷方法中,测试人员的价值又如何体现?

1、首先在需求讨论上,测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2、在开发过程中,测试人员不仅扮演“用户代表”角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),          将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。

3、测试人员还是可以参与单元测试。即使单元测试由开发人员做,测试人员可以推进开发人员进行单元测,检查单元测试状态,如确保单元测试达到80%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。

4、即使在敏捷方法中,集成测试、端到端(end-to-end)测试、性能测试等是不可少的。因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。测试人员在功能测试上工作量会降低,但在这些测试上发挥更大的作用。

5、随着迭代的不断深入,回归测试的工作量很大,这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本,这也是一种持续的努力,使回归测试自动化。测试人员对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。

而且:
在敏捷方法中,我们也要采用敏捷测试不要再写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点列出来。
在敏捷测试中,可能不需要测试用例,而是针对use case 或user story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。
所以:
敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试)  + 原有功能的自动化测试 (回归测试)
    理想情况下,测试人员具有很好的编程能力,可以和开发人员进行角色互换。在当前版本开发(/迭代周期)中担任测试人员角色,在下一个版本开发(/迭代周期)中担任开发人员角色,而开发人员则担任测试人员角色,让开发人员深刻地理解用户的需求角度来考虑系统功能的设计,这样会更好地保证产品的质量,沟通的障碍也会消除,开发的效率会有很大的提高。这也是对测试人员的一个挑战。
    敏捷测试也是一个持续测试的过程,而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。项目采用敏捷方法,要获得成功,项目组中每个人都有很强的质量意识,具有质量的主人翁精神,特别是开发人员,每时每刻提醒自己——“质量是构建出来的”,与客户或产品设计人员进行充分沟通,遵守高度一致的质量标准。

http://www.51testing.com/html/21/318121-217281.html

2010-03-16 22:56:00 liyangbing315 阅读数 8188

敏捷开发与极限编程

简介

      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)

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2008-06-24 20:08:00 sfdev 阅读数 1763

敏捷软件开发是自上世纪90年代Kent Beck提出极限编程【XP】时开始兴起的,这种编程方法用一组价值标准、原则和实践来规划、编码、设计和测试软件;随后很多公司或者是牛人都提出了很多自己所实施敏捷的一些方法、方式;归纳起来有以下一些:XP【eXtreme Programming】、Scrum、Crystal、FDD【Feature Driven Development】、ASD【Adaptive Software Development】、DSDM【Dynamic Systems Development Method】、TDD【Test Driven Development】、LSD【Lean Software Development】等;虽然说各种实施方式方法各不相同,但是所体现的思想是完全相通的,他们的目标基本上都是:减少浪费、提高效率、改进质量;于是在2001年成立了敏捷联盟【Agile Alliance】,并且发布了敏捷软件开发宣言以及相关设计原则;

敏捷软件开发宣言

  • 个人和交流     胜过 过程和工具【Individuals and interactions over processes and tools】
  • 可用的软件     胜过 面面俱到的文档【Working software over comprehensive documentation】
  • 与客户沟通和交流  胜过 合同谈判【Customer collaboration over contract negotiation】
  • 响应变化        胜过 遵循计划【Responding to change over following a plan】

虽然右项也有价值,但是我们认为左项具有更大的价值:

  • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
  • 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  • 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  • 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
  • 工作的软件是首要的进度度量标准。
  • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
  • 不断地关注优秀的技能和好的设计会增强敏捷能力。
  • 简单是最根本的。
  • 最好的构架、需求和设计出于自组织团队。
  • 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化:

  • 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
  • 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
  • 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
  • 粘滞性: 做正确的事情比做错误的事情要困难。
  • 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
  • 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
  • 晦涩性: 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些设计原则如下

  • 单一职责原则(SRP/Single Responsibility Principle) :就一个类而言,应该仅有一个引起它变化的原因。
  • 开放-封闭原则(OCP/Open-Close Principle) :软件实体应该是可以扩展的,但是不可修改。
  • Liskov替换原则(LSP/Liskov Substitution Principle) :子类型必须能够替换掉它们的基类型。
  • 依赖倒置原则(DIP/Dependency Invertion Principle) :抽象不应该依赖于细节。细节应该依赖于抽象。
  • 接口隔离原则(ISP/Interface Separate Principle) :不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
  • 重用发布等价原则(REP/Reuse Equivalence Principle) :重用的粒度就是发布的粒度。
  • 共同封闭原则(CCP/Common Close Principle) :包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
  • 共同重用原则(CRP/Common Resue Principle) :一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
  • 无环依赖原则(ADP/Acyclic Dependency Principle) :在包的依赖关系图中不允许存在环。
  • 稳定依赖原则(SDP/Stabilization Dependency Principle): 朝着稳定的方向进行依赖。
  • 稳定抽象原则(SAP/Stabilization Abstract Principle) :包的抽象程度应该和其稳定程度一致。

敏捷软件开发实践

那我们如何来开展敏捷呢,一般来说,有很多的实践是所有敏捷开发都具备的,当然如果你们的团队已经具备了这样的特征,那说明你们已经踏上了敏捷之路,可能你们自己并没有意识到;比如:强调任何的功能都需要有测试用例和测试代码、非常多的短迭代、坚持持续集成、不断的考虑重构、尝试结对编程、开始抛弃瀑布模型转而使用项目墙、每次项目后坚持PPR、每日开展standup meeting……

PS:关于敏捷其实有非常多的理论基础,各种敏捷方法也都有自己所专注的地方,更多的信息可参考:

敏捷开发介绍:http://www.itisedu.com/phrase/200603291800375.html

SOA 和敏捷方法基础:http://www.ibm.com/developerworks/cn/webservices/ws-agile1/

敏捷联盟:http://www.agilealliance.org/

TW首页:http://www.thoughtworks.com.cn

敏捷(agile)开发与极限编程(XP):http://blog.csdn.net/mood8125/archive/2006/01/21/585354.aspx

敏捷软件开发模型--SCRUM:http://www.cnblogs.com/Ring1981/archive/2006/09/07/496591.html

2010-01-24 00:35:57 lishushan 阅读数 25

内容摘要:敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

 

  简介

  2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(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、可持续的速度

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

  极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

  敏捷开发

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

  敏捷软件开发宣言:

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

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

 

  ◆客户合作       胜过   合同谈判

  ◆响应变化       胜过   遵循计划

  虽然右项也有价值,但是我们认为左项具有更大的价值。

  敏捷宣言遵循的原则:

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

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

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

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

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

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

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

  ◆ 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

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

  ◆简单是最根本的。

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

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

  当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。

  ◆僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。

  ◆脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

  ◆牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。

 

  ◆粘滞性: 做正确的事情比做错误的事情要困难。

  ◆不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。

  ◆不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。

  ◆晦涩性: 很难阅读、理解。没有很好地表现出意图。

  敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

  为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:

  单一职责原则(SRP)

  ◆就一个类而言,应该仅有一个引起它变化的原因。

  ◆开放-封闭原则(OCP)

  ◆软件实体应该是可以扩展的,但是不可修改。

  ◆Liskov替换原则(LSP)。

  ◆子类型必须能够替换掉它们的基类型。

  ◆依赖倒置原则(DIP)

  ◆抽象不应该依赖于细节。细节应该依赖于抽象。

  ◆ 接口隔离原则(ISP)

  ◆不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。

  ◆重用发布等价原则(REP)

  ◆重用的粒度就是发布的粒度。

  ◆共同封闭原则(CCP)

  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。

  ◆共同重用原则(CRP)

  ◆一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。

 

  ◆无环依赖原则(ADP)

  ◆在包的依赖关系图中不允许存在环。

  ◆稳定依赖原则(SDP)

  ◆朝着稳定的方向进行依赖。

  ◆稳定抽象原则(SAP)

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

  上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。

  下面举一个简单的设计问题方面的模式与原则应用的示例:

  问题:

  选择设计运行在简易台灯中的软件,台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着,也可以让灯打开或关闭。

  决方案一:

  下面图1是一种最简单的解决方案,Switch对象可以轮询真实开关的状态,并且可以发送相应的turnOn和turnOff消息给Light。

极限编程与敏捷开发

  图1

  解决方案二:

  上面这个设计违反了两个设计原则:依赖倒置原则(DIP)和开放封闭原则(OCP),DIP原则告诉我们要优先依赖于抽象类,而Switch依赖了具体类Light,对OCP的违反是在任何需要Switch的地方都要带上Light,这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案,可以采用ABSTRACT SERVER模式,在Switch和Light之间引入一个接口,这样就使得Switch能够控制任何实现了这个接口的东西,这也就满足了DIP和OCP原则。如下面图2所示:

极限编程与敏捷开发

 

  图2

  解决方案三:

  上面图2所示解决方案,违返了单一职责原则(SRP),它把Switch和Light绑定在一起,而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决,适配器从Switchable 派生并委托给Light,问题就被优美的解决了,现在,Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示:

极限编程与敏捷开发

  图1

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

敏捷开发FDD过程

阅读数 1299

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