在软件工程和应用程序开发领域，敏捷已经引起了很多关注。敏捷不是一个概念，而是一种思维方式。顾名思义，它专注于灵活和动态。此方法还消除了软件开发阶段之间的隔离，并鼓励开发团队与质量分析师协作。它还强调客户参与开发，构建和交付高质量的产品。在这里，我们将看看敏捷，它是如何工作的以及这种流行的软件开发方法的一些最佳实践。

软件开发生命周期简介

在软件开发生命周期(SDLC)是创建软件解决方案或修改旨在迎合某一特定问题的现有结构的过程。它包含各种步骤，遵循逻辑顺序。在传统的SDLC模型中，这些是一个接一个地遵循的步骤，通常是孤立地执行的：

从客户收集的要求

系统和可行性分析

设计和建模

编码或实施

测试

部署和交付

维护和变更请求

在典型的软件开发周期中，实际用户或客户参与需求收集过程，然后在beta测试期间。然而，这种传统模型的问题在于循环的维护部分变得困难且相当昂贵。很多时候，系统内没有增强或更改的余地。在最坏的情况下，已经设计或开发的软件不符合实际的客户规格和期望，这意味着开发团队可能需要重新开始整个过程​​。

为什么敏捷开发与众不同

最常见的SDLC传统模型 - 瀑布模型，快速应用模型，迭代模型，螺旋模型等 - 都有各自的优缺点。人们花了很长时间才能真正分析这些模型的真实性。它们非常适合理想的场景，但在实际应用中它们并不总是实用的。因此，软件开发团队面临许多挑战。传统SDLC模型的一些局限性包括：

它们不允许在后期更改要求，因为这些要求在软件需求规范文档中被冻结。在某些情况下，用户的期望没有说明或被误解。

最终用户在完成之前不会看到系统。这提供了很少的建议和更改范围。

传统的SDLC可以在开发人员和测试人员之间创建巨大的沟通差距，因为他们是分开的阶段，并且双方之间没有合作。

白盒测试无法有效完成。

敏捷的使用解决了许多这些问题，因为它不是一步一步的过程，而是更多的理念和框架，旨在帮助团队协作，响应变化并构建包含来自所有人的更多输入的成品。各方，包括用户。

敏捷实践

敏捷方法的出现不亚于软件开发方法的革命性改革，因为它为项目团队提供了足够的空间，使其具有创造性和多样性，同时仍然对产品的每个阶段进行集体所有权。通过遵循敏捷路径，软件开发团队中的每个参与者都能够调整他们的思想，接受不确定性，应对变化，并构建一个更好的产品作为一个过程，而不是分散的，独立的步骤。

虽然没有敏捷原则的完整列表，但敏捷传播的某些实践。这些包括：

测试驱动开发(TDD)

理想情况下，开发人员应首先为他们要编写的功能部分编写测试用例。这将确保高质量的代码，在特殊条件下不太可能破解。此过程还有助于确保已解决用户规范。

结对编程

在敏捷开发中，程序员通常成对地处理相同的问题，其中一个人正在编写代码(驱动程序)，另一个人正在查看代码并提供想法和建议(导航器)。这可以提高工作效率并缩短审核代码所需的时间。

代码重构

代码重构涉及将代码分解为更小更简单的模块，这些模块可以(并且应该)在理想情况下独立存在。这在很大程度上提高了代码的可读性，可测试性和可维护性。

来自实际利益相关者的积极参与

按照一定时间间隔(称为“ 冲刺 ”)，客户应该收到该软件的重要工作原型。这允许开发人员获得有关他们正在构建的内容的反馈。

将需求视为优先堆栈

在敏捷中，必须根据需求对其重要性进行分类。这可能包括对正在开发的软件产品的隐含和明确的客户期望。软件开发团队应共同估计他们将投入实施该功能的时间和资源，并根据用户需求以及他们将处理项目每个部分的相对顺序进行映射。

回归测试

回归测试涉及在添加新功能或修改代码中的现有功能后测试整个应用程序的功能。这有助于确保更改未破坏现有代码。

为什么要敏捷?

敏捷规定了某些实践，但它并没有对软件开发团队强制执行。毕竟，如果没有调整和偏差的余地，敏捷的目的在很大程度上被打败了。将敏捷开发的一些方面纳入项目可以帮助软件开发团队应对意料之外的挑战，并最终以更有效的方式构建更好的产品。