版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
目录
什么是敏捷
Agile（敏捷）来源于敏捷宣言，宣言明确指出，“敏捷”：
- 不是一种方法论
- 也不是开发软件的具体方法
- 更不是一个框架或者过程
“敏捷”是一套价值观（理念）和原则，帮助团队在软件开发过程中更好地做出决策。
什么是敏捷开发
简而言之就是遵循了“敏捷”这一开发原则的开发方法，敏捷并不意味着一味强调速度，而是轻量和高效。
百度百科是这样说的：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发流程如下：
敏捷宣言
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
注：这并不意味摒弃了右边的原则，而是应该更加注重左边的原则。
敏捷宣言12条原则
- 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，交付时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
比如就“简单”和“尽早交付”而言：
当我们在构建某个功能时，发现其可能会需要数据库支持，一般情况下我们会去构建数据库并为其编码，然而敏捷认为：为这个功能构建数据库就意味着要浪费很多时间，软件就不得不延迟交付给客户，如果能找到一种替代的简单方法完成该功能，那就更符合我的敏捷原则。
但是敏捷原则并不是让我们盲目模仿，应当结合实际情况和敏捷的价值理念做出正确决策。比如scrum可能倡导小组会议站着开，但是如果结合实际情况也可以完全选择适合自己的方式开会，坐着更高效就坐着，切记盲目模仿一些成功的敏捷案例。
敏捷开发的优势
相比于瀑布模型：
瀑布模型开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
- 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
- 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
- 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
- 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
- 于是，后厨只给客户加了盐，加了辣
- 客人吃完，不是很满意，下次不来了（没有满足需求）
敏捷开发
- 客人到餐馆来点菜（新项目）
- 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
- 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
- 后厨开始准备（项目启动）
- 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
- 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
- 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
- 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
- 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
- 客人吃完，很满意（基本满足了全部的要求）
总结：在理解了“敏捷”的价值和原则后，将其带入到软件开发过程中做出正确的决策，就是所谓的敏捷开发了。
参考：