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