文档介绍：敏捷开发一、什么是敏捷开发,简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:,个体和交互胜过过程和工具,可以工作的软件胜过面面俱到的文档,客户合作胜过合同谈判,响应变化胜过遵循计划并提出了以下遵循的原则:,我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。,即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。,经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。,在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。,围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。,在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。,工作的软件是首要的进度度量标准。,敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。,不断地关注优秀的技能和好的设计会增强敏捷能力。,简单是最根本的。,最好的构架、需求和设计出于自组织团队。,每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。二、从无到繁重再到敏捷多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改”(codeandfix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正规方法”(methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法,或JimHighSmith所称的“巨型”(monumental)方法。作为对这些方法的反叛,在过去几年中出现了一类新方法。尽管它们还没有正式的名称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来看,它们更象是“面向源码”(code-oriented)。事实上,它们认为最根本的文档应该是源码。但是,文档方面的特点并不是是敏捷型方法的根本之点。文档减少仅仅是个表象,它其实反映的是更深层的特点:敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。敏捷型方法是“面向人”的(people-oriented)而非“面向过程”的(process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心三、方法背后的思想AlistairCockburn在AgileSoftwareDevelopment中讲述了敏捷开发方法背后的思想人们掌握过程(process)可以分为3个阶段:1、following遵循一个定义好的process2、detaching知道不同process的适用范围,在不同的场合使用不同的process3