什么是敏捷开发（Agile Software Development）？敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。
敏捷开发方法的核心思想：适应变化和以人为中心
在敏捷开发中，软件项目被分成好多个子项目，每个子项目做完后都会经过测试，具备可以运行的特点。也就是把一个大的项目分成多个互相联系，但也可以独立运行的小项目分别完成，在这个过程中软件一直处于可使用状态。我觉得呢，敏捷开发主要是小而精的那种，敏捷开发也需要团队，团队中的每一个人都有比较高的专业技能，所谓的专业技能并非单指写代码能力，也包括其它方面的技能，每个成员都能保持尽最大努力把工作做好的态度；在项目开发工程中，并不需要繁琐、准备齐全的文档这些，但是要求尽可能地缩短开发的周期，强调渐进式交付，这个非常接近迭代式开发的流程，就是有个迭代的过程，对于需求的变动，能随时做出相应的调整，我觉得这应该是敏捷开发的精髓所在。
“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”
这是敏捷开发的宣言，从这个宣言的风格中我读出了“简单、实际”的特点，这是我读到这个宣言时的第一印象。我个人觉得敏捷开发一般不同于传统的开发方法，传统的开发方法都要求在开发之前有详细的需求文档，尽可能的希望这个设计文档能够包含所有情况，将这个项目做得完美无缺；经过漫长的时间当设计规划做好后，每个人对号入座，根据项目的需求去定义每个人的角色。这类开发方法的弊端在于，软件开发的项目中，所有因素都可能随时改变，而这就要求开发人员要么考虑周到要么随时准备改变，但是考虑周到得到的结果与付出的代价往往是不成比例的。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。对于人员角色的分配，虽然保证了工作的任务分配，但却限制了开发人员的创造和创新能力，效率低下。而敏捷开发则比较好的解决了这两个问题。
这是敏捷开发的线路图，敏捷开发的首要目标是Test Driven Development,其次是Continuous Integration（持续集成）……所以敏捷开发强调的是根据需求的变动反复的集成、测试，我认为这一点在当下尤为重要，一个好的点子需要马上去实现，并随时准备做出变化，而非等到所有准备工作”尽善尽美“后才动工，抢占先机比初始的完美或许更加重要。在人员调度上，敏捷开发强调人与人之间的合作，分工肯定也是需要的，但是不像传统方法中如此死板，他的理念在于让让所有人发挥出最大的能力，在实际开发中也要求团队人员尽量在一起工作。
敏捷开发模式
简介
是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
词源
敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会
适用性
在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：
组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的阶段。
另外的问题是项目初期的大量设想或快速的需求收集可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常会把不恰当的方案授予客户，而直到最后出问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。
对比其它方法
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.
对比迭代方法
相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
对比瀑布式开发
两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行。
敏捷开发与其他方式的比较
敏捷开发跟迭代开发都强调在较短的开发周期内提交软件，但敏捷开发的时间更短。相较于瀑布开发来讲，敏捷开发并不墨守成规，循规蹈矩，而是在开发的过程中根据工作小组的开发情况作出一定的调整，使得工作小组可以在尽可能短的一个开发周期内提交尽可能好质量的软件。
敏捷开发带来的好处
1.精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。
2.质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
3.速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。
丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。
高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
极限编程简介
在敏捷开发中，极限编程XP是领域中广为人知的一种编程方法，XP的核心是其总结的沟通、简单、反馈、勇气四大价值观，它们是XP的基础，也是XP的灵魂。在这里我们看到，极限编程着重的并不再是软件本身，而是整个工作团队的工作理念和工作过程。整个团队进行交流，从而实现1+1>2的良好效果。
综上说了一些敏捷开发的优点，也并不是说敏捷开发就比其他开发方法好，其实和所有事物都一样，比较好坏主要是看是否较优地解决了你的问题，而每个问题都有特定的背景前提。所以并不是说敏捷开发在所有环境下都是最好的，只是在现在要求创新、效率的条件下相对占优势。
下面是我上网找的关于敏捷开发的12条原则
1.对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2.我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3.经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4.业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5.围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6.在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7.可以工作的软件是进度的主要度量标准。
8.敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9.对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10.简单——尽可能减少工作量的艺术至关重要。
11.最好的架构、需求和设计都源自自我组织的团队。
12.每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为
以上仅是个人近期看了敏捷开发的文章后的一些总结和看法，不足之处，希望大家指出，一起学习讨论。