如题。为什么敏捷开发现在如此流行？而瀑布模型、迭代模型、增量模型等现在基本不见。

轻管理可以应对变化~ 让大家都是项目的一份子充分沟通太多了~

在当今竞争激烈的商业环境中，软件开发越来越受到客户和企业重点需求的驱动，客户和企业都需要快速响应他们的问题和关注。反馈必须立即纳入产品，工程团队必须能及时交付竞争对手所在的客户正在寻找的确切产品。首先，敏捷开发是一种过程控制论，通俗的说，就是一种做事情的方法。它适用于软件，因为软件是软的，可以改。要是硬件，改起来就没那么方便了；它适用于客户不知道自己要啥的情况，其实，这样的客户占绝大多数。因为客户不知道要啥，所以你需要不断帮客户弄明白他到底想要啥。换句话说，你需要和客户沟通，合作，倾听反馈，持续改进；它适用于竞争激烈的市场，这样的情况下，赶在竞争对手前交付一个不完美但至少能用的产品非常重要；它适用于快速变化的市场，你在埋头造一辆汽车的时候，客户已经想开飞机满天飞了，这就需要你能一步步的把汽车改成飞机，还能按时交付；它适用于在一个地方办公的小团队，一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的；其次，敏捷开发是一套工具集，里面有形形色色的工具，你可以用来提高工作效率。再其次，敏捷开发是一种企业管理方式。比如：一线员工可以同时是架构师，Scrum Master，开发工程师，测试工程师，发挥了他的主观能动性，有利于创新和效率；敏捷不专注于敏捷团队中个人的绩效考核，而更多的侧重于整个团队的绩效，更好的避免了KPI驱动模式；把大项目拆分成小项目去做（每个Sprint都是一个迭代，需要输出一个高质量的版本，相当于完成一个小项目），把bug的生存期控制在一个迭代以内，降低了风险，也减少了后期改bug的工作量；把数十人的大team 分成几个敏捷团队，这几个敏捷团队的Scrum Master/PO再组成一个更高一级的敏捷团队，利用站会，反思，看板等等敏捷元素，可以避免数十份邮件也不能解决一个小问题，大家互相踢皮球，沟通不畅的大企业病；老板可以是最大的PO，他给下面的高管讲idea(User Story)，定期检查Demo，把控产品用户体验，负责和外界的沟通合作。多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。敏捷方法很好的拥抱变化和进度可视，通过短周期迭代，尽可能早的交付可用的迭代版本来拥抱和适应变化。敏捷开发实践稳步上升，成为各地软件团队信任和首选的开发方式。使用敏捷，组织可以更快地响应市场变化，提供更高质量的软件，并获得显着的竞争优势。敏捷思想不仅仅适用于软件行业，它的很多方法和理念都可以被其他行业所借鉴。敏捷项目管理是未来的大方向。瀑布软件开发方法瀑布是以顺序开发模式为基础的，因此设计步骤必须以瀑布式的风格完成。这是一个公司需要遵循的八个不同阶段的计划：想法介绍分析设计发展测试执行维护开发人员逐一访问每一步，不能直接转到任意一个阶段。一旦完成第一步，开发人员只能移动到第二个步骤，如果在上一步中出现错误，那么开发人员不能移回去修复它。如果他这样做，那么整个项目都要被划伤，开发人员将不得不从第一步开始。在这个模型的任何阶段都没有任何错误的余地，给开发者带来很大的压力。由于无法向后移动或在此过程中跳过，每个步骤都必须明确规划。要进行任何类型的更改，这意味着在开始任何类型的编码之前，收集所有必需的信息，并完成设计过程。敏捷软件开发方法由于瀑布的缺点，敏捷模型被开发成为管理软件开发的更有效的方式。其结果基本上是解决瀑布方法中所有问题的线性设计模型。开发人员只需从项目的基础设计开始。设计完成后，他们移动到小模块开始开发。分为每月或甚至每周的Sprint，小模块的工作部分完成。这些冲刺用于在编码时查找错误和错误，开发人员在转到下一个Sprint之前使用客户端反馈。在这种方法中需要大量的合作，因为规划师，开发人员，设计人员和测试人员在产品的不同迭代中一起工作。该方法更灵活，因为允许开发人员在该过程的任何步骤进行更改，并且可以在此模型的帮助下轻松满足客户端的请求。产品的质量在每次更改时保留，从而产生更好的终端产品。

敏捷开发在软件工程中流行起来的原因

在当今竞争激烈的商业环境中，软件开发越来越受到客户和企业重点需求的驱动，客户和企业都需要快速响应他们的问题和关注。反馈必须立即纳入产品，工程团队必须能及时交付竞争对手所在的客户正在寻找的确切产品。

首先，敏捷开发是一种过程控制论，通俗的说，就是一种做事情的方法。

它适用于软件，因为软件是软的，可以改。要是硬件，改起来就没那么方便了；
它适用于客户不知道自己要啥的情况，其实，这样的客户占绝大多数。因为客户不知道要啥，所以你需要不断帮客户弄明白他到底想要啥。换句话说，你需要和客户沟通，合作，倾听反馈，持续改进；
它适用于竞争激烈的市场，这样的情况下，赶在竞争对手前交付一个不完美但至少能用的产品非常重要；
它适用于快速变化的市场，你在埋头造一辆汽车的时候，客户已经想开飞机满天飞了，这就需要你能一步步的把汽车改成飞机，还能按时交付；
它适用于在一个地方办公的小团队，一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的；

其次，敏捷开发是一套工具集，里面有形形色色的工具，你可以用来提高工作效率。
再其次，敏捷开发是一种企业管理方式。比如：

一线员工可以同时是架构师，Scrum Master，开发工程师，测试工程师，发挥了他的主观能动性，有利于创新和效率；

敏捷不专注于敏捷团队中个人的绩效考核，而更多的侧重于整个团队的绩效，更好的避免了KPI驱动模式；
把大项目拆分成小项目去做（每个Sprint都是一个迭代，需要输出一个高质量的版本，相当于完成一个小项目），把bug的生存期控制在一个迭代以内，降低了风险，也减少了后期改bug的工作量；
把数十人的大team 分成几个敏捷团队，这几个敏捷团队的Scrum Master/PO再组成一个更高一级的敏捷团队，利用站会，反思，看板等等敏捷元素，可以避免数十份邮件也不能解决一个小问题，大家互相踢皮球，沟通不畅的大企业病；
老板可以是最大的PO，他给下面的高管讲idea(User Story)，定期检查Demo，把控产品用户体验，负责和外界的沟通合作。

多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。敏捷方法很好的拥抱变化和进度可视，通过短周期迭代，尽可能早的交付可用的迭代版本来拥抱和适应变化。

敏捷开发实践稳步上升，成为各地软件团队信任和首选的开发方式。使用敏捷，组织可以更快地响应市场变化，提供更高质量的软件，并获得显着的竞争优势。

敏捷思想不仅仅适用于软件行业，它的很多方法和理念都可以被其他行业所借鉴。敏捷项目管理是未来的大方向。

瀑布软件开发方法
瀑布是以顺序开发模式为基础的，因此设计步骤必须以瀑布式的风格完成。这是一个公司需要遵循的八个不同阶段的计划：

想法
介绍
分析
设计
发展
测试
执行
维护

开发人员逐一访问每一步，不能直接转到任意一个阶段。一旦完成第一步，开发人员只能移动到第二个步骤，如果在上一步中出现错误，那么开发人员不能移回去修复它。如果他这样做，那么整个项目都要被划伤，开发人员将不得不从第一步开始。在这个模型的任何阶段都没有任何错误的余地，给开发者带来很大的压力。

由于无法向后移动或在此过程中跳过，每个步骤都必须明确规划。要进行任何类型的更改，这意味着在开始任何类型的编码之前，收集所有必需的信息，并完成设计过程。

敏捷软件开发方法
由于瀑布的缺点，敏捷模型被开发成为管理软件开发的更有效的方式。其结果基本上是解决瀑布方法中所有问题的线性设计模型。

开发人员只需从项目的基础设计开始。设计完成后，他们移动到小模块开始开发。分为每月或甚至每周的Sprint，小模块的工作部分完成。这些冲刺用于在编码时查找错误和错误，开发人员在转到下一个Sprint之前使用客户端反馈。

在这种方法中需要大量的合作，因为规划师，开发人员，设计人员和测试人员在产品的不同迭代中一起工作。该方法更灵活，因为允许开发人员在该过程的任何步骤进行更改，并且可以在此模型的帮助下轻松满足客户端的请求。产品的质量在每次更改时保留，从而产生更好的终端产品。