一、敏捷开发的含义
百度百科上这样解释到：
敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
从上面一段简介上来看，需求变化频繁提到的次数最多，所有的产品开发都是基于用户或者市场需求，但需求不可能一成不变，现如今互联网的快速发展，各类产品层出不穷，要怎么才能抓住用户呢，敏捷开发时运而生。
二、敏捷开发——入口
敏捷，意思指反应（多指动作或言行）迅速快捷。
敏捷开发最大的特点是迭代式开发，各个阶段都具备独立运行和独立交付的特性。主要是以客户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
初期的产品需求整理完成后，将用户的核心需求点筛选出来，再将核心需求点划分为多个小的功能点，交由开发同事进行开发，在有产品形成初期的阶段，可以随时的应对客户的需求，根据需求核心一点点的完善其他功能点，已达到最后的一个产品交付。如果我们一开始就按照客户提出的需求，做完全部的功能点之后，几个月之后客户才见到成品，然后客户觉得不满意，需要更改，既加大了工作量，也降低了客户满意度。
三、敏捷开发——迭代
敏捷开发就是在持续的迭代中交付出最终的产品，那什么时候才需要迭代呢？迭代的标准是什么呢？
敏捷开发属于增量式开发，所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。
四、敏捷开发——12个原则
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2．即使到了开发的后期，也欢迎改变需求。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5．围绕被激励起来的个人来构建项目。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单使未完成的工作最大化。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
五、敏捷开发的优缺点
优点：
1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上适应需求的频繁变化。
2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。
3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。
缺点：
1、项目迭代快，更多的依赖人与人之间的交流，缺少文档的支撑
2、项目拆分为多个小的功能模块，需要较强的项目管理者进行统筹，团队稳定，人员流动不能太大
五、敏捷开发——有趣的例子
① 敏捷开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
- 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
- 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
- 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
- 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
- 客人吃完，很满意（基本满足了全部的要求）
②瀑布模型开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
- 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
- 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
- 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
- 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
- 于是，后厨只给客户加了盐，加了辣
- 客人吃完，不是很满意，下次不来了（没有满足需求）
六、总结
在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。
