SDLC - 敏捷模型

敏捷 SDLC 模型結合了迭代和增量過程模型，重點關注過程適應性和客戶滿意度，透過快速交付可工作的軟體產品。敏捷方法將產品分解成小的增量構建。這些構建以迭代方式提供。每次迭代通常持續約 1 到 3 周。每次迭代都涉及跨職能團隊同時處理各個領域，例如：

• 計劃
• 需求分析
• 設計
• 編碼
• 單元測試和
• 驗收測試。

在迭代結束時，會向客戶和重要利益相關者展示可工作的產品。

什麼是敏捷？

敏捷模型認為每個專案都需要以不同的方式處理，並且需要根據專案的具體需求調整現有方法。在敏捷中，任務被劃分為時間盒（短時間段）以交付特定版本的特性。

採用迭代方法，並在每次迭代後交付可工作的軟體構建。每個構建在功能方面都是增量的；最終構建包含客戶所需的所有功能。

以下是敏捷模型的圖形說明：

敏捷的思想過程在軟體開發的早期就開始了，並且隨著時間的推移由於其靈活性和適應性而變得越來越流行。

最流行的敏捷方法包括 Rational 統一過程 (1994)、Scrum (1995)、Crystal Clear、極限程式設計 (1996)、自適應軟體開發、特性驅動開發和動態系統開發方法 (DSDM) (1995)。在 2001 年釋出敏捷宣言後，這些方法現在統稱為敏捷方法。

以下是敏捷宣言的原則：

• 個人和互動 - 在敏捷開發中，自我組織和積極性很重要，協同辦公和結對程式設計等互動也很重要。

• 可工作的軟體 - 演示可工作的軟體被認為是與客戶溝通以瞭解其需求的最佳方式，而不是僅僅依賴文件。

• 客戶協作 - 由於各種因素，在專案開始時無法完全收集需求，因此持續的客戶互動對於獲得正確的產品需求非常重要。

• 響應變化 - 敏捷開發專注於快速響應變化和持續開發。

敏捷與傳統 SDLC 模型

敏捷基於自適應軟體開發方法，而傳統的 SDLC 模型（如瀑布模型）則基於預測方法。傳統 SDLC 模型中的預測團隊通常會進行詳細的計劃，並對未來幾個月或產品生命週期中要交付的確切任務和功能進行完整的預測。

預測方法完全依賴於週期開始時進行的需求分析和計劃。任何要合併的更改都需要經過嚴格的變更控制管理和優先順序排序。

敏捷使用自適應方法，其中沒有詳細的計劃，並且僅在需要開發哪些功能方面對未來任務有清晰的瞭解。存在特性驅動開發，團隊會動態地適應不斷變化的產品需求。產品會非常頻繁地進行測試，透過釋出迭代，最大程度地降低未來發生重大故障的風險。

客戶互動是這種敏捷方法的支柱，開放式溝通和最少的文件是敏捷開發環境的典型特徵。敏捷團隊之間緊密協作，並且通常位於同一地理位置。

敏捷模型 - 優缺點

敏捷方法最近在軟體領域得到廣泛接受。但是，這種方法並不總是適合所有產品。以下是敏捷模型的一些優缺點。

敏捷模型的優勢如下：

• 是一種非常現實的軟體開發方法。

• 促進團隊合作和交叉培訓。

• 可以快速開發和演示功能。

• 資源需求最少。

• 適用於固定或不斷變化的需求

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

• 適用於環境穩定變化的良好模型。

• 規則最少，易於使用文件。

• 能夠在整體計劃的上下文中併發開發和交付。

• 無需或幾乎無需計劃。

• 易於管理。

• 給開發人員帶來靈活性。

敏捷模型的缺點如下：

• 不適合處理複雜依賴關係。

• 可持續性、可維護性和可擴充套件性風險更大。

• 必須有一個總體計劃、一個敏捷領導者和敏捷專案管理實踐，否則它將無法正常工作。

• 嚴格的交付管理決定了要交付的範圍和功能，以及為滿足截止日期而進行的調整。

• 嚴重依賴客戶互動，因此如果客戶不清楚，團隊可能會被引導到錯誤的方向。

• 由於生成的文件最少，因此存在非常高的個人依賴性。

• 由於缺乏文件，將技術轉移給新團隊成員可能極具挑戰性。