敏捷开发与极限编程_极限编程与敏捷开发 - CSDN
  • 极限编程与敏捷开发

    千次阅读 2006-08-16 09:46:00
    在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。 -- Jack Reeves 简介 2001年,为了...敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特

    在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。

    -- Jack Reeves

    简介

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

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

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

     

    敏捷开发

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

    -- Tom DeMacro和Timothy Lister

     

    敏捷软件开发宣言:

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


    敏捷宣言遵循的原则:

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

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

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


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

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

    单一职责原则(SRP)

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

    开放-封闭原则(OCP)

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

    Liskov替换原则(LSP)

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

    依赖倒置原则(DIP)

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

    接口隔离原则(ISP)

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

    重用发布等价原则(REP)

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

    共同封闭原则(CCP)

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

    共同重用原则(CRP)

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

    无环依赖原则(ADP)

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

    稳定依赖原则(SDP)

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

    稳定抽象原则(SAP)

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

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

    展开全文
  • 敏捷开发与极限编程的简介 什么是敏捷开发?一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一...
    什么是敏捷开发?

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

    什么是敏捷开发?

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

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

    敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于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

    展开全文
  • 敏捷开发与极限编程

    千次阅读 2010-03-16 22:57:00
    敏捷开发与极限编程简介 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发...

    敏捷开发与极限编程

    简介

          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)

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

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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 【引自Jack zhai 的博客】软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。...软件开发不仅是代码编程,而是人员的有效组织,如何既发挥人的主观能动性,避免情绪变化对工作的影响,又可以让大家有

    【引自Jack zhai 的博客】软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的 工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的观点就是让最聪明的人应该选出来做官,做官就是管理人的。软件开发不仅是代码编程,而是人员的有效组织,如何既发挥人的主观能动性,避免情绪变化对工作的影响,又可以让大家有效的交流,让多个大脑的思路统一,快速完成目标呢?多年来软件企业的管理者一直在不断地探索。

    另外,有一个问题一直是软件开发管理人员的心病:软件是工具,开发的是客户业务的应用,但客户不了解软件,开发者不了解业务,如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法,让软件企业付出的代价也是昂贵的。

    瀑布模型、极限编程、敏捷开发是有代表性的开发模式,在对开发者、客户、最终的产品的关注上的变化,体现了软件开发管理者在管理模式上的变化。

    一、瀑布开发

    瀑布模型(Waterfall Model)是Royce在1970年提出的,他把大型软件开发分为:分析与编程,象工厂流水线一样把软件开发过程分成各种工序,并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路,所以成为软件开发企业使用最多的开发模型。

     

    瀑布模型的特点:

    1、强调文档,前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。
    2、没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。
    3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。

    瀑布模型的用户很多,也有一些反对的意见:

    第一、瀑布模型不适合客户需求不断变化的软件开发,尤其是客户的业务管理的软件,业务随着市场变化,而软件初期的设计可能已经大大变化,而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里,一方面市场带动需求变化,另一方面初期客户对需求描述不清楚,都为瀑布模型的使用团队带来困难。

    第二、瀑布模型是一种软件文档的开发,把开发者变成流水线上的机器,大量重复性的工作让编程人员提不起兴趣,工作很枯燥,没有激情,编程成了一种没有创意的机械劳动,这让一向以高科技为标志的高级程序人员大为恼火。

    在这种背景下,极限编程(extreme Programming, XP)带来了新鲜的空气。

    二、极限编程

    极限编程诞生于一种加强开发者与用户的沟通需求,让客户全面参与软件的开发设计,保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通,一定要用客户理解的语言,先 测试再编码就是先给客户软件的外部轮廓,客户使用的功能展现,让客户感觉到未来软件的样子,先测试再编码与瀑布模型显然是背道而驰的。同时,极限编程注重用户反馈与让客户加入开发是一致的,让客户参与就是随时反馈软件是否符合客户的要求。有了反馈,开发子过程变短,迭代也就很自然出现了,快速迭代,小版本发布都让开发过程变成更多的自反馈过程,有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”,如结队编程、40小时工作等。

    极限编程是一种开发管理模式,它强调的重点是:

    1、角色定位
    极限编程把客户非常明确地加入到开发的团队中,并参与日常开发与沟通会议。客户是软件的最终使用者,使用是否合意一定以客户的意见为准。不仅让客户参与设计讨论,而且让客户负责编写拥护故事(User Story),也就是功能需求,包括软件要实现的功能以及完成功能的业务操作过程。用户在软件开发过程中的责任被提到与开发者同样的重要程度。

    2、敏捷开发
    敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期,缩短到周、日,完成一个小的功能模块,可以快速测试、并及时展现给客户,以便及时反馈。小版本加快了客户沟通反馈的频率,功能简单,在设计、文挡环节大大简化。极限编程中文挡不再重要的原因就是因为每个版本功能简单,不需要复杂的设计过程。极限编程追求设计简单,实现客户要求即可,无需为扩展考虑太多,因为客户的新需求随时可以添加。

    3、追求价值
    极限编程把软件开发变成自我与管理的挑战,追求沟通、简单、反馈、勇气,体现开发团队的人员价值,激发参与者的情绪,最大限度地调动开发者的积极性,情绪高涨,认真投入,开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。

    极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程,确立了测试->编码->重构(设计)的软件开发管理思路。

    极限编程的12个实践是极限编程者总结的实践经典,是体现极限编程管理的原则,对极限编程具有指导性的意义,但并非一定要完全遵守12个实践,主要看它给软件过程管理带来的价值。

    1、小版本
    为了高度迭代,与客户展现开发的进展,小版本发布是一个可交流的好办法,客户可以针对性提出反馈。但小版本把模块缩得很小,会影响软件的整体思路连贯,所以小版本也需要总体合理的规划。

    2、规划游戏
    就是客户需求,以客户故事的形式,由客户负责编写。极限编程不讲求统一的客户需求收集,也不是由开发人员整理,而是采取让客户编写,开发人员进行分析,设定优先级别,并进行技术实现。当然游戏规则可进行多次,每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点,也是版本设计的依据,所以其管理一定是有效的、沟通顺畅的。

    3、现场客户
    极限编程要求客户参与开发工作,客户需求就是客户负责编写的,所以要求客户在开发现场一起工作,并为每次迭代提供反馈。

    4、隐喻
    隐喻是让项目参与人员都必须对一些抽象的概念理解一致,也就是我们常说的行业术语,因为业务本身的术语开发人员不熟悉,软件开发的术语客户不理解,因此开始要先明确双方使用的隐喻,避免歧异。

    5、简单设计
    极限编程体现跟踪客户的需求变化,既然需求是变化的,所以对于目前的需求就不必过多地考虑扩展性的开发,讲求简单设计,实现目前需求即可。简单设计的本身也为短期迭代提供了方便,若开发者考虑“通用”因素较多,增加了软件的复杂度,开发的迭代周期就会加长。简单设计包括四方面含义:(1)通过测试。(2)避免重复代码。(3)明确表达每步编码的目的,代码可读性强。(4)尽可能少的对象类和方法。由于采用简单设计,所以极限编程没有复杂的设计文档要求。

    6、重构
    重构是极限编程先测试后编码的必然需求,为了整体软件可以先进行测试,对于一些软件要开发的模块先简单模拟,让编译通过,到达测试的目的。然后再对模块具体 “优化”,所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念,是在不影响物体外部特性的前提下,重新优化其内部的机构。这里的外部特性就是保证测试的通过。

    7、测试驱动开发
    极限编程是以测试开始的,为了可以展示客户需求的实现,测试程序优先设计,测试是从客户实用的角度出发,客户实际使用的软件界面着想,测试是客户需求的直接表现,是客户对软件过程的理解。测试驱动开发,也就是客户的需求驱动软件的开发。

    8、持续集成
    集成的理解就是提交软件的展现,由于采用测试驱动开发、小版本的方式,所以不断集成(整体测试)是与客户沟通的依据,也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

    9、结对编程
    这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程,一个编码,一个检查,增加专人审计是为了提供软件编码的质量。两个人的角色经常变换,保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

    10、代码共有
    在极限编程里没有严格文档管理,代码为开发团队共有,这样有利于开发人员的流动管理,因为所有的人都熟悉所有的编码。

    11、编码标准
    编码是开发团队里每个人的工作,又没有详细的文档,代码的可读性是很重要的,所以规定统一的标准和习惯是必要的,有些象编码人员的隐喻。

    12、每周40小时工作
    极限编程认为编程是愉快的工作,不轻易加班,今天的工作今天做,小版本的设计也为了单位时间可以完成的工作安排。

    三、敏捷开发

    极限编程的思想体现了适应客户需求的快速变化,激发开发者的热情,也是目前敏捷开发思维的重要支持者。
    2001 年,17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派,发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式,用来替代以文件驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。敏捷软件开发宣言内容:

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

    敏捷开发集成了新型开发模式的共同特点,它重点强调:

    1、以人为本,注重编程中人的自我特长发挥。
    2、强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主体。
    3、客户与开发者的关系是协作,不是合约。开发者不是客户业务的“专家”,要适应客户的需求,是要客户合作来阐述实际的需求细节,而不是为了开发软件,把开发人员变成客户业务的专家,这是传统开发模式或行业软件开发企业的最大面临问题。
    4、设计周密是为了最终软件的质量,但不表明设计比实现更重要,要适应客户需求的不断变化,设计也要不断跟进,所以设计不能是“闭门造车”、“自我良好”,能不断根据环境的变化,修改自己的设计,指导开发的方向是敏捷开发的目标。

    敏捷开发避免了传统瀑布方式的弊端,主要是吸收了各种新型开发模式的“动态”特性,关注点从文档到开发者,管理方式也从工厂的流水线到团队的自我放松式的组织。总结敏捷开发与瀑布模式的不同,主要是下面几个“敏捷”的关注点:

    迭代
    软件的功能是客户的需求,界面的操作是客户的“感觉”,对迭代的强调是缩短了软件版本的周期
    客户参与
    以人为本,客户是软件的使用者,是业务理解的专家,没有客户的参与,开发者很难理解客户的真实需求
    小版本
    快速功能的展现,看似简单,但对于复杂的客户需求,合理地分割与总体上的统一,要很好地二者兼顾是不容易的。

    敏捷就是“快”,快才可以适应目前社会的快节奏;要快就要发挥个人的个性思维多一些,个性思维的增多,虽然通过结队编程、代码共有、团队替补等方式减少个人对软件的影响力,但也会造成软件开发继承性的下降,因此敏捷开发是一个新的思路,但不是软件开发的终极选择。对于长时间、人数众多的大型软件应用的开发,文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合,是软件开发组织者面临的新课题。

     

    展开全文
  • 敏捷过程与极限编程

    2020-07-21 09:57:24
    敏捷过程与极限编程
  • 接着上一篇文章--"敏捷开发与极限编程(一)", 我继续研究XP编程给我参与的项目能提供什么样的意见, 在此过程中我无意中找了Amr Elssamadisy写的----"大型项目的XP(极限编程)"这篇文章,收获不少. Amr Elssamadisy结合...
  • 极限编程敏捷开发的一种方法,极限编程针对小型的开发团队来说是一个不错的方法,极限编程本质是务实主义的体现,快速稳定的实现每一个用户要求,是极限编程的基本要求。 1.客户尽量和开发人员在一起,一是可以...
  • 敏捷开发极限编程

    2019-06-28 09:39:18
    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。在以前的开发过程中,很多规则已经难于遵循,很多流程复杂而难于理解,很多项目中文档的制作过程正在失去控制。人们试图提出更...
  • 敏捷开发极限编程

    2019-06-27 03:38:17
    敏捷软件开发(Agile software development): 它是一种用来应对软件需求的不断变更的新的软件开发技术。 强调整个开发过程中业务人员和开发人员紧密协作在一起,面对面交流,频繁性的交付...极限编程敏捷开发中...
  • 敏捷开发极限编程过程

    千次阅读 2016-12-25 20:12:24
    极限编程敏捷开发软件开发使用最为广泛的一个方法,作为面向对象方法的推荐开发范型,它包含了策略,设计,编码,测试4个框架活动的规则和实际。 策划:  》倾听一系列的用户故事,描述即将建立的软件的需要的...
  • 极限编程(XP)和SCRUM大概是2种最著名的敏捷开发方法。二者有啥区别呢? 一、XP的特点 1、迭代周期更短,并强调持续反馈 2、测试驱动,自动化测试 3、项目初期迅速生成总体计划,之后迭代发展和完善 4、持续演化 5...
  • 转自:... 只有良好的沟通才能知道客户需要什么,也只有良好的沟通,才能团队成员合作无间 本次讨论希望带领大家进入一个以沟通为基本原则的软件开发领域,它就是——敏捷开发 一、敏
  • 敏捷过程与极限编程(XP)

    千次阅读 2017-09-18 12:35:32
    为了使软件开发团队具有高效工作和快速响应变化的能力,17位著名的软件专家于2001年2月联合起草了敏捷软件开发宣言。敏捷软件开发宣言由下述4个简单的价值观声明组成。 (1) 个体和交互胜过过程和工具 优秀的团队...
  • 1.敏捷过程 目的:为了使软件开发团队具有高效工作和快速...2.极限编程(eXtreme Programming ,XP) Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所
1 2 3 4 5 ... 20
收藏数 9,951
精华内容 3,980
关键字:

敏捷开发与极限编程