软件工程|敏捷软件开发

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

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

现在，让我们来了解一下敏捷奠定基础的因素： 原则：

1. 最高优先级是通过早期和持续交付有价值的软件来满足客户。
2. 它欢迎不断变化的需求，即使是在开发后期。
3. 频繁交付工作软件，从几周到几个月不等，优先选择最短的时间段。
4. 围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能完成工作。
5. 工作软件是衡量进步的主要标准。
6. 简单——最大化未完成工作量的艺术至关重要。
7. 在开发团队中传递信息最有效的方法是面对面交谈。

敏捷开发： 让我们来看一下敏捷哲学中开发是如何发生的。

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

例子： 让我们通过一个例子来清楚地了解敏捷实际上是如何工作的。 名为软件公司 基础知识 希望为其最新版本的操作系统制作一款新的网络浏览器。这项任务的最后期限是10个月。该公司负责人指派了两个小组 A队 和 B队 完成这项任务。为了激励团队，该公司负责人表示，第一个开发浏览器的团队将获得加薪和一周的全额赞助旅行计划。两个团队怀着疯狂旅行的梦想，踏上了网络浏览器之旅。团队A决定照本宣科，并决定选择瀑布模型进行开发。经过一番激烈的讨论后，B团队决定改变信念，选择敏捷作为他们的开发模式。

A队的发展计划如下：

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

B队的发展计划如下：

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

两个团队都尽了最大努力将产品推向一个完整的阶段。但突然，由于环境的快速变化，该公司的负责人想出了一套全新的功能，并希望尽快实施，并希望在两天内推出一个工作模式。团队A现在处于修复阶段，他们仍处于设计阶段，还没有开始编码，也没有可显示的工作模型。此外，他们几乎不可能实现新功能，因为一旦进入下一个阶段，瀑布模型就不会回到旧阶段，这意味着他们必须重新开始。这将导致他们付出高昂的成本和大量的加班费。由于敏捷开发，团队B在很多方面领先于团队A。自第一次增量以来，他们还拥有满足大多数核心需求的工作产品。对他们来说，增加新的需求是小菜一碟。他们所要做的就是为下一个增量计划这些需求，然后实施它们。

优势：

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

缺点：

• 在大型软件项目中，很难评估软件开发生命周期初始阶段所需的工作。
• 敏捷开发更注重代码，生成的文档更少。
• 敏捷开发在很大程度上依赖于客户的投入。如果客户对最终结果的愿景模棱两可，那么项目很可能偏离正轨。
• 在大型组织中，面对面的沟通更难。
• 只有高级程序员才能在开发过程中做出所需的决定。因此，新程序员很难适应环境。

敏捷是一个定义软件开发需要如何进行的框架。敏捷不是一种单一的方法，它代表了遵循宣言中提供的价值陈述的各种方法和实践的集合。敏捷方法和实践并不能保证解决软件行业中存在的所有问题（任何软件模型都无法做到）。但它们确实有助于建立一种文化和环境，让解决方案浮出水面。