软件工程 |敏捷软件开发

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

为什么要敏捷？
当前时代的技术进步比以往任何时候都快，迫使全球软件公司在快节奏变化的环境中工作。由于这些企业在不断变化的环境中运营，因此不可能收集到一套完整而详尽的软件需求。如果没有这些要求，任何传统的软件模型实际上都很难工作。
传统的软件模型，如瀑布模型，依赖于完全指定需求、设计和测试系统，并不适合快速软件开发。结果，传统的软件开发模型无法交付所需的产品。
这就是敏捷软件开发的用武之地。它专门设计用于通过采用增量开发的理念和开发实际的最终产品来满足快速变化的环境的需求。

现在让我们了解一下敏捷奠定了基础的内容：
原则：

最高优先级是通过早期和持续交付有价值的软件来满足客户。
它欢迎不断变化的需求，即使是在开发的后期。
频繁地交付工作软件，从几周到几个月不等，优先考虑最短的时间尺度。
围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
工作软件是进度的主要衡量标准。
简单最大化未完成工作量的艺术是必不可少的。
向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面交谈。

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

在敏捷开发中，设计和实现被认为是软件过程中的核心活动。
设计和实施阶段还包括其他活动，例如需求获取和测试。
在敏捷方法中，迭代发生在活动之间。因此，需求和设计是一起开发的，而不是分开开发的。
在一系列增量中执行的需求分配以及设计规划和开发。与需要完成需求收集才能进入设计和开发阶段的传统模型相比，它为敏捷开发提供了额外的灵活性。
敏捷过程更多地关注代码开发而不是文档。

示例：让我们通过一个示例来清楚地了解敏捷实际上是如何工作的。
一家名为ABC的软件公司想要为其操作系统的最新版本制作一个新的 Web 浏览器。该任务的截止日期为 10 个月。公司负责人为这项任务分配了两个团队，名为A团队和 B 团队。为了激励团队，公司负责人表示，第一个开发浏览器的团队将获得加薪和为期一周的全额赞助旅行计划。两个团队怀揣着狂野的旅行幻想，踏上了网络浏览器的旅程。 A 队决定按部就班，决定选择瀑布模型进行开发。 B 组经过一番激烈的讨论，决定大步向前，选择敏捷作为他们的开发模式。

A组的发展计划如下：

需求分析和收集 - 1.5 个月
系统设计 – 2 个月
编码阶段 – 4 个月
系统集成和测试 - 2 个月
用户验收测试 – 5 周

B组的发展计划如下：

由于这是一个敏捷项目，因此该项目被分解为几个迭代。
迭代都是相同的持续时间。
在每次迭代结束时，必须交付具有新功能的工作产品。
他们不会花费 1.5 个月的时间收集需求，而是决定产品所需的核心功能，并决定哪些功能可以在第一次迭代中开发。
在第一次迭代中无法交付的任何剩余功能将在下一次后续迭代中交付，基于优先级
在第一次迭代结束时，团队将交付具有核心基本功能的工作软件。

两个团队都尽最大努力使产品达到一个完整的阶段。但后来由于环境瞬息万变，公司的负责人想出了一套全新的功能，并希望尽快实施，并希望在 2 天内推出一个工作模型。 A 团队现在处于修复状态，他们仍处于设计阶段，尚未开始编码，也没有可显示的工作模型。而且，他们几乎不可能实现新功能，因为一旦进入下一阶段，瀑布模型就不会恢复到旧阶段，这意味着他们必须再次从正方形开始。这将导致他们付出沉重的代价和大量的加班。 B 团队在很多方面都领先于 A 团队，这都归功于敏捷开发。自第一次增量以来，他们还拥有具有大多数核心需求的工作产品。对他们来说，添加新要求是小菜一碟。他们所要做的就是为下一次增量安排这些要求，然后实施它们。

优点：

软件的部署速度更快，因此有助于增加客户的信任。
能够更好地适应快速变化的需求并更快地响应。
有助于获得即时反馈，这些反馈可用于在下一个增量中改进软件。
人——不是过程。人员和交互被赋予更高的优先级，而不是流程和工具。
持续关注卓越的技术和良好的设计。

缺点：

对于大型软件项目，很难评估软件开发生命周期初始阶段所需的工作量。
敏捷开发更注重代码并产生更少的文档。
敏捷开发在很大程度上取决于客户的投入。如果客户对最终结果的看法模棱两可，那么项目很可能会偏离轨道。
在大型组织中，面对面的交流更难。
只有高级程序员才能在开发过程中做出所需的决定。因此，对于新程序员来说，适应环境是一个困难的局面。

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