敏捷软件开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷开发的价值观是1.人与人的交互 优先于过程和工具2.可以工作的软件优于求全责备的文档3.客户协作优于合同谈判4.随时应对变化优于循规蹈矩。下面浅谈一下敏捷开发的方法：
（1）极限编程xp
Extreme Programming（极限编程，简称XP）是由KentBeck在1996年提出的。XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。其价值体现在以下几个方面：第一，沟通（Communication）：即追求有效的沟通。XP强调项目开发人员、设计人员、客户之间等有效地、及时地沟通，确保各种信息的畅通。第二，简单（Simplicity）：即实现最简单的可行方案。XP认为应该尽量保持代码的简单，只要能够满足工作需要就行，这样有利于代码的重构和优化。第三，反馈（Feedback）：即快速有效的反馈。要求不断对当前系统状态进行反馈，通过反馈，达到迅速沟通、编码、测试、发布的目的。第四，勇气（Courage）：即勇于放弃和重构。对于用户的反馈，XP程序员要勇于对自己的代码进行修改，即使有些修改可能会使得原来已经通过的测试又出现错误，但是经过团队的共同攻关，最终必然会取得满意的效果。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
与传统的软件工程方法相比较，极限编程具有以下优点：（1）重视客户的参与；（2）重视团队合作和沟通；（3）制定计划前做出合理预测；（4）让编程人员参与软件功能的管理；（5）重视质量；（6）简单设计；（7）高频率的重新设计和重构；（8）高频率及全面的测试；（9）递增开发；（10）连续的过程评估；（11）对过去的工作持续不断的检查。但是也有它的缺点：（1）以代码为中心，忽略了设计；（2）缺乏设计文档，局限于小规模项目；（3）对已完成工作的检查步骤缺乏清晰的结构；（4）质量保证依赖于测试；（5）缺乏质量规划；（6）没有提供数据的收集和使用的指导；（7）开发过程不详细；（8）全新的管理手法带来的认同度问题；（9）缺乏过渡时的必要支持。
（2） Scrum
Scrum是一种迭代式增量软件开发过程。Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个 Sprint，每个 Sprint 的建议长度2到4周。在 Scrum 中，使用产品 Backlog 来管理产品或项目的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每个 Sprint 中，Scrum 开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint 中挑选的需求经过 Sprint 计划会议上的分析、讨论和估算得到一个 Sprint 的任务列表，我们称它为 Sprint backlog。在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。
Scrum是一个包括了一系列实践和预定义角色的过程骨架。
Scrum 框架
三个角色：产品负责人，Scrum Master，团队
四个仪式：Sprint 计划会议，每日站会，Sprint 评审会议，Sprint 回顾会议
三个物件：产品 Backlog，Sprint Backlog，燃尽图（在冲刺长度上显示每天进展的图。）
敏捷方法之极限编程(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, 自动测试， 结对编程，简单设计，重构等约束团队的行为。
角色：
“猪"角色是全身投入项目和Scrum过程的人
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。
”鸡”角色并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，但只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。
（3）精益软件开发
精益思想：
1.尊重一线人员（工作在一线的人最了解实际情况，他们知道现在发生了什么，知道当前情况下的最佳应对方法）
2.消除浪费（要求团队识别出软件开发过程中的“浪费”，采取改进措施消除产生这些浪费的行为和流程。）
3.增强学习（在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试）
4.尽量延迟决定（尽可能的延迟决定，直到能够基于事实而不是不确定的假定和预测来做出决定。）
5.嵌入质量（质量是在过程中产生的；如果在开发流程的每一个阶段，都能保证产出物的质量，最终产品的质量就能以最低的代价实现；过程中保证质量能大量减少浪费，质量是过程的一部分；）
6.快速交付 （快速交付的好处数不胜数，譬如能够使客户更早地得到产品价值，能使产品更快地投入市场）
7.整体优化（局部的优化，若不能带来整体的改善，将是没有价值的；构造一个完整的产品）
在人的方面，精益思想强调如何将每个员工的能力发挥到极限，认为不应该只是简单的管理人，而应该去培训人。如果不能将管理的重点放在员工的培养上，就不能理解精益生产的真理。同时，精益生产的另一个精髓是管理过程，精益思想不是着眼于结果，而是强调过程。“只对结果管理”的管理思路的结果是员工对找借口、为结果辩护很在行，对数据、报告很在行，但软件项目成果的质量只有在全过程都有效控制下才能得到根本的保证。
（4）动态系统开发
动态系统开发方法（Dynamic System Development Method，DSDM）是一种敏捷软件开发方法，该方法提供一种框架，使其“通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护”。
DSDM使用迭代软件过程，每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。
DSDM的基本原则 DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。
原则1：用户必须持续参与
原则2：必须授予DSDM团队制定决策的权利
原则3：注重产品的经常交付
原则4：满足业务用户用途是接受交付品的主要依据
开发人员不必沉溺于完美的解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。
原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的
采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。
原则6：开发过程的所有变化可逆
采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。
原则7：在高层次上制定需求的基线
在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。
原则8：测试自始至终贯穿于开发周期之中
开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。
原则9：所有项目涉众间的通力合作是不可获缺的
（5） 特性驱动开发
特征驱动开发（FDD-Feature Driven Development）方法是敏捷软件开发过程中的一种，它强调特性驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量，非常适合中小型团队开发管理。它提出的每个功能开发时间不超过两周，为每个用例user case限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。它抓住了软件开发的核心问题领域，即正确和及时地构造软件。FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。
FDD过程：
FDD是一个模型驱动( model-driven)、短期迭代(short-iteration)的过程。 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后是周期低于两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容。一个FDD开发过程如附件1图所示。
其由5个活动组成：
1. 开发一个全局的模型 （Develop an Overall Model）
2. 建立特征列表
在此采用下述格式进行描述：
- 针对功能： <action>the<result><by | for | of | to>a(n)<object>
- 针对功能集：<action><-ing>a(n)<object>
- 针对主功能集：<object>management
3. 依据特征规划(Plan by Feature)
4. 依据特征设计(Design By Feature)
5. 依据特征构建(Build By Feature)
（6） 水晶开发
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
水晶项目开发核心特征:
--经常交付;
--项目主办者根据团队的工作进展获得重要反馈;
--用户有机会发现他们原来的需求是否是他们真正想要的, 有机会将观察结果反馈到开发当中
--团队得以调整开发和配置的过程, 并且可以鼓舞士气
--规定Timing Box确定最终的迭代交付时间点
这六种方法的共同点是：
迭代式开发 增量交付 开发团队和用户反馈推动产品开发 持续集成 开发团队自我管理
内容甚是肤浅，请大家谅解！