敏捷开发思惟导图，让java再也不难懂

0、先来一张导图

一、概念

简单的说，敏捷开发是一种以人为核心、迭代、按部就班的开发方法。在敏捷开发中，软件项目的构建被切分红多个子项目，各个子项目的成果都通过测试，具有集成和可运行的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程当中软件一直处于可以使用状态。

敏捷最大的特点是迭代式开发。

二、优点

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

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

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

三、误区

四、特色

五、核心原则

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

某博主po的一个颇有趣的“敏捷和瀑布”对比例子，给你们做为阅读参考：

6.一、敏捷开发

• 客人到餐馆来点菜（新项目）

• 不肯定客户想吃什么的时候，一般选好餐厅后会先看看餐厅的菜单（客户每每提不出具体的需求）

• 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本肯定了需求）

• 后厨开始准备（项目启动）

• 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）

• 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）

• 上菜过程当中，客人忽然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，能够不断测试和需求变动）

• 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提早明确，反复迭代，增长了工做量）

• 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变动）

• 客人吃完，很满意（基本知足了所有的要求）

6.二、瀑布模型开发

• 客人到餐馆来点菜（新项目）

• 不肯定客户想吃什么的时候，一般选好餐厅后会先看看餐厅的菜单（客户每每提不出具体的需求）

• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本肯定了需求）

• 后厨开始准备（项目启动）

• 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）

• 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）

• 再过了二十分钟，十个菜都一块儿上来了（项目最终一次交付）

• 客人说，有几个菜挺好的，可是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）

• 这时候大堂经理来了，说，“味道淡了能够加盐，不辣能够加辣，可是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变动比较麻烦）

• 因而，后厨只给客户加了盐，加了辣

• 客人吃完，不是很满意，下次不来了（没有知足需求）

七、总结

但总的来讲，在如今管理项目过程当中，并无严格的按照彻底的敏捷或者彻底的瀑布模式，都是各自掺杂了其余的方式。在实际项目过程当中，过于强调模式并无意义，重要的是能不能预防问题的发生，在问题发生以后能不能用最小的成本解决，模式更多起一个参考做用

最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题

欢迎关注java思惟导图。