SDLC - 敏捷模型

敏捷 SDLC 模型结合了迭代和增量过程模型，重点关注过程适应性和客户满意度，通过快速交付可工作的软件产品。敏捷方法将产品分解成小的增量构建。这些构建以迭代方式提供。每次迭代通常持续约 1 到 3 周。每次迭代都涉及跨职能团队同时处理各个领域，例如：

• 计划
• 需求分析
• 设计
• 编码
• 单元测试和
• 验收测试。

在迭代结束时，会向客户和重要利益相关者展示可工作的产品。

什么是敏捷？

敏捷模型认为每个项目都需要以不同的方式处理，并且需要根据项目的具体需求调整现有方法。在敏捷中，任务被划分为时间盒（短时间段）以交付特定版本的特性。

采用迭代方法，并在每次迭代后交付可工作的软件构建。每个构建在功能方面都是增量的；最终构建包含客户所需的所有功能。

以下是敏捷模型的图形说明：

敏捷的思想过程在软件开发的早期就开始了，并且随着时间的推移由于其灵活性和适应性而变得越来越流行。

最流行的敏捷方法包括 Rational 统一过程 (1994)、Scrum (1995)、Crystal Clear、极限编程 (1996)、自适应软件开发、特性驱动开发和动态系统开发方法 (DSDM) (1995)。在 2001 年发布敏捷宣言后，这些方法现在统称为敏捷方法。

以下是敏捷宣言的原则：

• 个人和互动 - 在敏捷开发中，自我组织和积极性很重要，协同办公和结对编程等互动也很重要。

• 可工作的软件 - 演示可工作的软件被认为是与客户沟通以了解其需求的最佳方式，而不是仅仅依赖文档。

• 客户协作 - 由于各种因素，在项目开始时无法完全收集需求，因此持续的客户互动对于获得正确的产品需求非常重要。

• 响应变化 - 敏捷开发专注于快速响应变化和持续开发。

敏捷与传统 SDLC 模型

敏捷基于自适应软件开发方法，而传统的 SDLC 模型（如瀑布模型）则基于预测方法。传统 SDLC 模型中的预测团队通常会进行详细的计划，并对未来几个月或产品生命周期中要交付的确切任务和功能进行完整的预测。

预测方法完全依赖于周期开始时进行的需求分析和计划。任何要合并的更改都需要经过严格的变更控制管理和优先级排序。

敏捷使用自适应方法，其中没有详细的计划，并且仅在需要开发哪些功能方面对未来任务有清晰的了解。存在特性驱动开发，团队会动态地适应不断变化的产品需求。产品会非常频繁地进行测试，通过发布迭代，最大程度地降低未来发生重大故障的风险。

客户互动是这种敏捷方法的支柱，开放式沟通和最少的文档是敏捷开发环境的典型特征。敏捷团队之间紧密协作，并且通常位于同一地理位置。

敏捷模型 - 优缺点

敏捷方法最近在软件领域得到广泛接受。但是，这种方法并不总是适合所有产品。以下是敏捷模型的一些优缺点。

敏捷模型的优势如下：

• 是一种非常现实的软件开发方法。

• 促进团队合作和交叉培训。

• 可以快速开发和演示功能。

• 资源需求最少。

• 适用于固定或不断变化的需求

• 交付早期部分可工作的解决方案。

• 适用于环境稳定变化的良好模型。

• 规则最少，易于使用文档。

• 能够在整体计划的上下文中并发开发和交付。

• 无需或几乎无需计划。

• 易于管理。

• 给开发人员带来灵活性。

敏捷模型的缺点如下：

• 不适合处理复杂依赖关系。

• 可持续性、可维护性和可扩展性风险更大。

• 必须有一个总体计划、一个敏捷领导者和敏捷项目管理实践，否则它将无法正常工作。

• 严格的交付管理决定了要交付的范围和功能，以及为满足截止日期而进行的调整。

• 严重依赖客户互动，因此如果客户不清楚，团队可能会被引导到错误的方向。

• 由于生成的文档最少，因此存在非常高的个人依赖性。

• 由于缺乏文档，将技术转移给新团队成员可能极具挑战性。