敏捷模型
靈活（敏捷）方法通過將工作流移動到幾個小周期中來幫助降低軟件開發的風險。這些週期稱為迭代，通常持續兩到三週。
迭代就像一個由任務組成的小型軟件項目，每個任務都會改進功能。其中包括：制定計劃、評估需求、就項目達成一致、編寫代碼、測試和創建技術文檔。
對於一個完整的軟件版本來說，一次迭代通常是不夠的。然而，敏捷的好處是項目的一小部分在每次迭代結束時都準備好進行評估。這允許團隊成員更改優先級以進行進一步的工作，而無需等待最終版本。
應用“敏捷”開發方法，您可以在每次迭代後看到具體的結果。即開發者可以了解自己的工作結果是否滿足要求。這是靈活模式的重要優勢之一。
至於缺點，在使用敏捷時，有時很難估計勞動力資源成本和項目預算。如果我們選擇靈活模型的實際應用，那麼其中最著名的就是極限編程（XP）。
XP 基於每天舉行的團隊成員簡短會議和定期會議（每週一次或更少）。在每日集會（每日站會）中，通常會討論：
- 目前的工作成果；
- 每個團隊成員要完成的任務列表；
- 遇到的困難和解決的辦法。
宣言
敏捷是開發的一個整體方向，因此它的工作規則在一個特殊的文件中聲明 - 敏捷宣言。這包括團隊工作應遵循的實踐和原則。
敏捷宣言包含 4 個基本思想和 12 個原則。
關鍵思想：
- 開發人員之間的協作比工具更重要；
- 產品的工作版本優先於文檔；
- 團隊與客戶之間的相互理解比合同條款更重要；
- 如有必要，可以隨時更改原始計劃。
至於敏捷的 12 條原則，它們是：
- 主要優先事項是完成的程序符合客戶的期望；
- 允許在任何階段改變條件，即使是在開發的最後階段（如果這可以提高軟件的質量和競爭力）；
- 定期交付軟件產品的工作版本（每 14 天、每月或每季度一次）；
- 成功的關鍵是客戶和開發人員之間的定期互動（最好是每天）；
- 項目應該建立在對項目感興趣的人中間，應該為這些人提供必要的工作條件和各種支持；
- 在團隊中共享信息的最佳方式是個人會議；
- 軟件的工作版本是進度的最佳指示器；
- 所有利益相關者必須能夠在整個軟件開發過程中保持預期的工作節奏；
- 技術改進和良好的設計提高了靈活性；
- 保持簡單而不是過度創造很重要；
- 最好的結果來自那些能夠自組織的團隊；
- 團隊成員應該定期思考如何通過改變工作流程來提高效率。
根據敏捷宣言，一個好的軟件開發過程直接取決於參與這個過程的人。為此，您需要盡可能有效地組織他們的互動，創建最有條理的團隊。
方法論
敏捷宣言中也有幾個方法論解釋了價值觀和原則：
- 敏捷建模；
- 敏捷統一過程；
- 敏捷數據方法
- 快速應用程序開發（DSDM）；
- 必要的統一過程；
- 極限編程；
- 功能驅動開發；
- 變得真實；
- 打開;
- 敏捷。
敏捷建模是一組原則、術語和實踐，可以加速和簡化軟件模型和文檔的開發。
敏捷建模的目標是改進建模和文檔。請務必注意，這不包括編碼、測試或與項目控制、部署和支持相關的問題。但是，此方法包括代碼審查。
Agile Unified Process 是一種讓用戶很容易去近似（模型）的方法論。通常用於開發商業軟件。
敏捷數據方法——幾種類似的方法，其中客戶條件是通過幾個團隊的合作來實現的。
DSDM - 這種方法與其他方法的不同之處在於，未來產品的用戶與開發人員一起積極參與其中。
特性驅動開發是一種有時間限制的開發方法：“每個特性的實現時間不得超過兩週。”
值得考慮的是，如果用例很小，它可以被認為是一個特性。如果它很重要，那麼它必須分為幾個功能。
Getting Real 是一種迭代方法，首先開發程序界面，然後才開發其功能。
OpenUP是一種將項目週期分為四個階段的開發方法：開始、細化、構建和移交。
根據敏捷原則，無論工作持續時間長短，都需要為所有利益相關者和團隊成員提供一種認識和決策的方式。因此，可以有效地控制情況並及時評估中間結果。項目計劃定義了生命週期，最終結果應該被認為是應用程序的穩定發布。
至於 Scrum，它規定了管理開發過程的規則，並允許您應用現有的編碼實踐，並有可能調整條件或進行更改。使用這種方法，您可以在開發的早期階段看到並消除與預期結果的偏差。
讓我們更詳細地看一下這個......