一.关于敏捷开发的概念

敏捷开发的思想自进入国内以来，已经经过多年的发展，概念也不断完善，通常认为这是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。也就是说把一个整体的大项目分成多个相互联系的但又可以独立运行的小项目，并根据计划分别完成，并保证软件在此过程中一直处于可用状态，这就是其迭代式开发的特色。

  二.敏捷开发的优势

敏捷开发确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。

2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。

3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能，能最大化单位成本收益。

三、误区

关于敏捷开发应当认为是一种轻量级、高效的平台，而不是纯粹的越快越好。

四、特点

1. 个体和交互胜过过程和工具

2.可以工作的软件胜过面面俱到的文档（但并非不需要文档）

3. 客户合作胜过合同谈判

4.响应变化胜过遵循计划

五、核心原则

1.主张简单

2.拥抱变化

3.第二个目标是可持续性

4.递增的变化

5.令投资最大化

6.有目的的建模

7.多种模型

8.高质量的工作

9.快速反馈

10.软件是你的主要目标

11.轻装前进

六、敏捷开发与瀑布模型开发

瀑布模型开发

敏捷开发

曾经有大牛分享了一个很有趣的“敏捷和瀑布”的例子，这里拿来一起分享。

1、敏捷开发

客人到餐馆来点菜（新项目）不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）根据图文菜单，客人点了10个菜（根据原型和设计稿，基本确定了需求）后厨开始准备（项目启动）配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）客人吃完，很满意（基本满足了全部的要求）。

2、瀑布模型开发

客人到餐馆来点菜（新项目）不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）后厨开始准备（项目启动）根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）再过了二十分钟，十个菜都一起上来了（项目最终一次交付）客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）于是，后厨只给客户加了盐，加了辣客人吃完，不是很满意，下次不来了（没有满足需求）。

七、总结

就目前来看，在实际管理项目的过程中，大多数并没有严格的按照敏捷或瀑布模式，都是各自掺杂了其他的方法，因为在实际项目的过程中，过于强调模式意义不大，重要的是能不能预防问题的发生或者在问题出现之后能不能以最小的成本解决，而模式更多的是起到一个参考作用，“实际大于主义”。

Learun（力软）近十年来一直专注于敏捷开发框架的研发，目前v7.0经典框架已经在各行各业得到应用，适用于OA、ERP、CRM、BI、BPM、HRM、SAAS、移动app、电商系统后台等多种企业信息系统，欢迎体验指正：.