敏捷是一种有时间限制的迭代式软件交付方法，可以从项目一开始就逐步构建软件，而不是试图一次性交付。

敏捷为什么？

当前时代的技术发展速度比以往任何时候都快，迫使全球软件公司在快节奏的变化环境中工作。由于这些企业在不断变化的环境中运营，因此无法收集完整而详尽的软件需求。没有这些要求，任何传统的软件模型都很难工作。

传统的软件模型，如瀑布模型，依赖于完全指定要求，设计和测试系统，不适合快速的软件开发。结果，传统的软件开发模型无法提供所需的产品。

这就是敏捷软件开发拯救的地方。它专门设计用于通过增量开发和开发实际最终产品的理念来策划快速变化的环境的需求。

现在让我们读一下敏捷奠定基础的

原则：

最高优先级是通过早期和持续交付有价值的软件来满足客户。

它欢迎不断变化的要求，甚至在开发的后期。

经常提供工作软件，从几周到几个月，优先选择最短的时间。

围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。

工作软件是进步的主要衡量标准。

简单性最大化未完成工作量的艺术至关重要。

向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。

敏捷开发：让我们看一下敏捷哲学中如何发展的简要概述。

在敏捷开发中，设计和实现被认为是软件过程中的核心活动。

设计和实施阶段还包括其他活动，例如需求获取和测试。

在敏捷方法中，跨活动进行迭代。因此，要求和设计是一起开发的，而不是单独开发的。

以一系列增量执行的需求分配和设计规划与开发。与传统模型相比，需要完成需求收集才能进入设计和开发阶段，这为敏捷开发提供了额外的灵活性。

敏捷过程更侧重于代码开发而不是文档。

示例：让我们通过一个示例来清楚地了解敏捷实际上是如何工作的。

一家名为ABC的软件公司希望为其最新版本的操作系统制作一个新的Web浏览器。该任务的截止日期为10个月。该公司的负责人分配了两个团队，分别为A 队和B队为了这个任务。为了激励团队，公司负责人表示，开发浏览器的第一个团队将获得加薪和一周的全额赞助旅行计划。凭借他们疯狂旅行幻想的梦想，两支队伍开始了网络浏览器之旅。A团队决定按照这本书来玩，并决定选择瀑布模型进行开发。经过大量讨论后，B队决定采取信念，并选择敏捷作为他们的发展模式。

A队的发展计划如下：

需求分析和收集 - 1.5个月

系统设计 - 2个月

编码阶段 - 4个月

系统集成和测试 - 2个月

用户验收测试 - 5周

B队的发展计划如下：

由于这是一个敏捷，该项目被分解为几个迭代。

迭代都是相同的持续时间。

在每次迭代结束时，必须提供具有新功能的工作产品。

他们将决定产品所需的核心功能，并决定在第一次迭代中可以开发哪些功能，而不是花费1.5个月的时间来收集需求。

在第一次迭代中无法传递的任何剩余特征将在下一次迭代中基于优先级传递

在第一次迭代结束时，团队将提供具有核心基本功能的工作软件。

团队都尽最大努力将产品推向完整的阶段。但由于环境的快速变化，该公司的负责人提出了一套全新的功能，并希望尽快实施，并希望在2天内推出一个工作模型。A队现在处于修复状态，他们仍然处于设计阶段，尚未开始编码，他们没有工作模式可供展示。而且，他们实际上不可能实现新功能，因为瀑布模型一旦你进入下一阶段就不会恢复到旧阶段，这意味着他们必须再次从正方形开始。这将导致他们沉重的成本和大量的加班费。感谢敏捷开发，B队在很多方面领先于A队。自第一次增加以来，他们还拥有大部分核心要求的工作产品。添加新要求对他们来说是件小事。他们所要做的就是为下一个增量安排这些要求，然后实施它们。

好处：

软件部署更快，因此有助于增加客户的信任。

可以更好地适应快速变化的要求并更快地响应。

帮助获得即时反馈，可用于在下一个增量中改进软件。

人 - 不是过程。人和交互被赋予更高的优先级而不是流程和工具。

不断关注技术卓越和良好的设计。

缺点：

对于大型软件项目，很难评估软件开发生命周期初始阶段所需的工作量。

敏捷开发更注重代码，产生的文档更少。

敏捷开发在很大程度上取决于客户的意见。如果客户对最终结果的看法含糊不清，那么该项目极有可能偏离轨道。

面对面交流在大型组织中更难。

只有高级程序员才能在开发过程中采取所需的决策。因此，新程序员适应环境是一个困难的局面。

敏捷是一个框架，它定义了如何进行软件开发。敏捷不是一种单一的方法，它代表了遵循宣言中提供的价值陈述的各种方法和实践。敏捷方法和实践不承诺解决软件行业中存在的每个问题（没有软件模型可以）。但他们肯定有助于建立一个解决方案出现的文化和环境。