在软件工程和应用程序开发领域，关于敏捷的讨论很多。 敏捷不是一个概念，而是一种心态。 顾名思义，它专注于灵活和动态。 这种方法还消除了软件开发阶段之间的隔离，并鼓励开发团队与质量分析师协作。 它还强调客户参与开发、构建和交付高质量的产品。 在这里，我们将了解敏捷、它的工作原理以及这种流行的软件开发方法的一些最佳实践。
软件开发生命周期简介
软件开发生命周期 (SDLC) 是创建软件解决方案或修改现有结构以满足特定问题的过程。 它包含各种步骤，这些步骤按逻辑顺序进行。 在传统的 SDLC 模型中，这些是一个接一个地执行的步骤，通常是孤立执行的：
从客户那里收集需求
系统及可行性分析
设计和建模
编码或实现
测试
部署和交付
维护和变更请求
在典型的软件开发周期中，实际用户或客户参与需求收集过程，然后参与 Beta 测试。 然而，这种传统模式的问题在于周期的维护部分变得困难且相当昂贵。 很多时候，系统内没有增强或更改的余地。 在最坏的情况下，已经设计或开发的软件不符合客户的实际规格和期望，这意味着开发团队可能需要重新开始整个过程。
为什么敏捷开发与众不同
最常见的 SDLC 传统模型——瀑布模型、快速应用模型、迭代模型、螺旋模型等——各有优缺点。 人们花了很长时间才真正分析出这些模型的真实性。 它们非常适合理想场景，但在实际应用中并不总是实用。 因此，软件开发团队面临着许多挑战。 传统 SDLC 模型的一些局限性包括：
他们不允许在后期更改需求，因为这些需求已冻结在软件需求规范文档中。 在某些情况下，用户的期望会被隐瞒或被误解。
在系统完成之前，最终用户看不到系统。 这为提出建议和更改提供了非常小的空间。
传统的 SDLC 会在开发人员和测试人员之间造成巨大的沟通鸿沟，因为它们是独立的阶段，并且双方之间没有协作。
无法有效地进行白盒测试。
敏捷的使用解决了其中的许多问题，因为它不是一个循序渐进的过程，而是一种哲学和框架，旨在帮助团队协作、响应变化并构建包含更多来自所有人的输入的成品 各方，包括用户。
敏捷实践
敏捷方法论的出现不亚于对软件开发方法论的革命性改革，因为它为项目团队提供了足够的空间来发挥创造力和多才多艺，同时仍然对产品的每个阶段拥有集体所有权。 通过遵循敏捷路径，软件开发团队中的个体参与者能够调节他们的思想以接受不确定性、应对变化并构建更好的产品作为一个过程，而不是离散的、独立的步骤。
虽然没有完整的敏捷原则列表，但敏捷传播了某些实践。 这些包括：
测试驱动开发 (TDD)
理想情况下，开发人员应该首先为他们要为其编写代码的功能块编写测试用例。 这将确保高质量的代码，在异常情况下不太可能被破坏。 此过程还有助于确保满足用户规范。
结对编程
在敏捷开发中，程序员通常会成对地处理同一个问题，一个人编写代码（驱动程序），另一个人审查代码并提供想法和建议（导航员）。 这提高了工作效率并减少了审查代码所需的时间。
代码重构
代码重构涉及将代码分解成更小、更简单的模块，这些模块可以（并且应该）独立存在于理想场景中。 这在很大程度上提高了代码的可读性、可测试性和可维护性。
实际利益相关者的积极参与
在一定时间段的固定时间间隔（称为“冲刺”）之后，客户应该收到一个重要的软件工作原型。 这使开发人员可以在进行过程中获得有关他们正在构建的内容的反馈。
将需求视为优先堆栈
在敏捷中，必须根据需求的重要性对需求进行分类。 这可能包括客户对正在开发的软件产品的隐含和明确的期望。 软件开发团队应该共同估计他们将投入到实现该功能的时间和资源，并根据用户需求和他们处理项目每个部分的相对顺序来映射。
回归测试
回归测试涉及在添加新功能或修改代码中的现有功能后测试整个应用程序的功能。 这有助于确保更改没有破坏现有代码。
为什么要敏捷？
敏捷规定了某些实践，但它并没有将它们强加给软件开发团队。 毕竟，如果没有调整和偏差的余地，敏捷的目的就基本落空了。 将敏捷开发的几个方面结合到一个项目中，可以帮助软件开发团队应对意想不到的挑战，并最终以更有效的方式构建更好的产品。
