敏捷運動誕生於2001年，當時17位富有遠見的開發人員在猶他州的研討會上進行了交流。研討會上所建立的理念和原則構成了敏捷方法論的基礎，並在此基礎上發展了後續的敏捷方法論。
自從最初的《敏捷軟體開發宣言》發布以來，敏捷方法論不僅對軟體開發，而且對幾乎所有領域的組織都產生了深遠的變革性影響。精益產品創建、迭代探索、以變化為中心的開發以及跨企業和社會群體的協作等價值觀，已成為全球新型先進商業和產品模式的基礎。
本敏捷方法論指南將概述敏捷的核心原則。我們將先給出2001年敏捷宣言中提出的敏捷方法論定義，然後再介紹一些敏捷衍生而來的知名分支。最後，我們將討論一些最受歡迎的敏捷方法和工具。
什麼是敏捷？
敏捷是一種工作方法（最初用於軟體開發），可以將其視為對持續變化和改進的承諾。
敏捷價值觀
敏捷方法可以用以下價值觀簡潔地描述，這些價值觀由最初的敏捷宣言團隊於 2001 年撰寫：
- 個體與互動 超越流程和工具
- 工作軟體 過於全面的文檔
- 客戶協作 合約談判
- 因應變化 過度遵循計劃
從這些原則可以看出，敏捷的定義不僅在於它是什麼，還在於它不是什麼。上述四個價值觀的共同之處在於，它們都重視迭代探索和協作，而非僵化的交付成果。透過專注於這些要素，敏捷團隊不僅可以創造更優質的產品，減少浪費，還能為探索留出空間，同時保持功能性版本的流暢發布。wing to 最終用戶。
敏捷開發與瀑布式開發
敏捷開發的創辦人提出了一個與軟體產業傳統工作方式截然不同的方案。當時（大約在2001年），軟體開發多以專案為單位，根據提前數月制定的具體規格來生產數位產品。產品願景由顧問、高階主管和管理人員組成的團隊決定，他們會列出需求清單並提交給管理團隊。管理團隊隨後會將編碼、編譯、測試和建置所需軟體的工作分配給各個團隊，這些工作需要在規定的時間和預算內完成。
開發人員將這種系統稱為「瀑布式」方法，因為軟體需求和交付成果都是由公司高層自上而下地規定給核心開發人員的。
最初的敏捷協作者出於多種原因拒絕了這種軟體開發方式。首先，瀑布式開發過於僵化，無法因應開發過程中可能發生變化的客戶需求。其次，瀑布式產品設計意味著所有創新都必須在專案啟動之前就構思好。這種僵化的框架使得在產品發布完成之前幾乎沒有空間去探索新的功能可能性。此外，軟體可能無法如預期運行，因此在瀑布式專案中，開發過程中發現問題意味著代價高昂的延誤。
敏捷開發的創辦人提出了一種開放的軟體開發方法，鼓勵探索、創新和迭代。他們不再要求在特定日期交付功能齊全的完整軟體，而是允許分階段發布功能版本。這縮短了產品上市時間，並允許分階段進行開發預算，而不是一次性投入全部資金。
最重要的是， 敏捷發展 它承認最初設想的產品可能無法為客戶和公司本身帶來預期的價值。分階段開發允許添加新想法或更改產品策略，使開發能夠以瀑布式開發無法實現的方式進行回應。
敏捷原則
為了克服瀑布式開發模式的不足，敏捷理念鼓勵從公司內部各個層面汲取創意。同樣重要的是，產品開發週期應專注於迭代式變更，頻繁交付，而不是耗時數月甚至數年才能完成功能建構的大型產品版本。
該團隊沒有採用傳統的「瀑布式」管理驅動的開發週期，而是提出了以下在當時非常激進的工作方法：
- 在創建新軟體時，應從簡單的概念和想法入手，而不是詳盡的交付成果。開發一個可運行的概念驗證原型，以體現該概念為客戶和內部利害關係人創造價值的潛力。
- 讓業務人員和開發團隊合作，確定如何推進、改進和發展工作原型，使其成為更強大的版本。
- 每天留出時間和空間，讓個人和團隊成員之間進行直接對話，以便追蹤專案進度並發現改進產品的新機會。這可以採取簡短的站立會議或較長的 Scrum 會議的形式。
- 頻繁發布新的軟體版本，持續將新變更整合並部署到生產環境中。每個變更版本都代表著對前一個版本的改進。
- 反思每個工作階段（「衝刺」）的結果，並利用所學到的經驗教訓來改善後續的開發工作。
- 讓客戶參與產品改進過程中來，可以透過直接調查或間接資料訊號等方式。
敏捷和精益製造
敏捷開發吸收了精實生產的許多經驗。精實生產理念起源於20世紀後半葉先進工業化製造業發展時期。它透過精實生產消除產品製造過程中不必要的步驟，提高生產效率。日本汽車公司豐田曾將這些方法應用於實踐，並由此形成了著名的豐田生產方式（TPS）。
從精實管理中汲取的敏捷開發關鍵經驗包括：
- 創建盡可能高效的流程。
- 透過合併流程並去除那些無法產生更好產品的流程來消除浪費（Muda）。
- 嚴格衡量結果，以確保產品品質穩定，生產週期一致。
- 讓員工參與改善流程，並依賴關鍵人員來實現品質、速度和效率目標。
- 找出流程中導致延誤或品質不佳的步驟，並解決這些「流程」問題，以便順利、有效率的流程能夠可靠地生產一致的產品。
什麼是敏捷方法論？
敏捷方法論是一套工作方法，所有這些方法都體現了2001年首次提出的敏捷理念。因此，實際上可以把多種方法論都歸入「敏捷方法論」的範疇。這些方法論構成了最受歡迎的敏捷方法，下文將逐一詳細介紹。
敏捷方法論有以下特點：
- 團隊由組織內不同領域的專家組成（跨職能團隊）。
- 跨職能團隊負責根據團隊本身、客戶回饋和產品策略團隊提供的創新想法，建構軟體/產品概念的原型版本。
- 然後，軟體產品會在短時間內進行「衝刺」式修改，以添加更多功能、功能、改進和修復。
- 公司內部會不斷收集關於產品改進和變革的想法，並經常就這些問題進行討論。
- 跨職能團隊在每日簡短的「站立會議」中討論工作進度、挑戰、優先事項和新出現的機會。
- 衝刺完成後，衝刺期間產生的變更將合併到產品的當前版本中。
- 品質控制貫穿整個流程，包括定期測試和採納客戶回饋。特定版本的問題會在整合和交付新版本之前被發現並（理想情況下）解決。
- 每個迭代周期結束後，跨職能團隊都會花時間反思結果以及整個流程。根據總結的經驗教訓，他們可能會設定新的目標和里程碑。
- 新的迭代計劃由跨職能團隊負責，旨在添加新功能、改進和修復。
敏捷方法有哪些類型？
敏捷開發有很多流行的版本和衍生方法，還有一些方法早於敏捷宣言，但與敏捷的價值觀相同。它們包括 Scrum、精益、看板、極限編程 (XP)、特性驅動開發 (FDD)、動態系統開發方法 (DSDM) 和 Crystal。
爭球
爭球 Scrum 專注於利用快速迭代的衝刺來完成迭代式敏捷改進。 Scrum 團隊協調合作，在衝刺期間完成主要工作，每個衝刺都經過精心計劃，以便在不影響版本品質和完整性的前提下完成重要工作。
Scrum 的顯著特點是引入了「Scrum Master」和「產品負責人」這兩個角色，他們負責監督所有細小的流程最終能否達成預期結果。同樣重要的是「產品待辦事項清單」的概念，它記錄了可以在下一個迭代周期中引入的新功能、改進和修復。
Scrum 方法論已被證明能夠擴展到擁有 800 多名員工的大型組織中的多個團隊。了解更多 Digital.ai Agility（原名 VersionOne）支持 Scrum 衝刺規劃 透過簡化產品待辦事項的管理。
精益
精實生產（如上文所述）優先考慮透過可預測的工作流程持續創造穩定價值。它強調開發流程的速度和效率，並依賴程式設計師和客戶之間快速可靠的回饋。精實生產採用「拉動式」生產理念，即根據顧客需求「拉動」產品。它將決策權和能力集中在個人和小團隊，因為研究表明，這種方式比層級的控制流程更快、更有效率。
精實方法也注重團隊資源的高效利用，力求確保每個人盡可能長時間地保持高效工作狀態。它強調並行工作，並盡可能減少團隊內部工作流程的依賴關係。精實方法也強烈建議在編寫程式碼的同時編寫自動化單元測試。
看板
看板是一種生產管理方法，與精實生產的歷史緊密相連。看板方法主要使用「看板」來追蹤目前工作項目的數量以及它們所經歷的工作階段。看板使用便利貼（或虛擬憑證）來追蹤流程每個階段的當前工作項目數量。一旦某個工作項目完成，便利貼就會被移到流程的下一個階段。
看板透過視覺化目前工作項目的數量及其在開發週期中的進度來強調流程。當大量工作項目積壓在某個階段時，這表示需要立即處理在製品（WIP）的數量，以便推動迭代或任務小組順利完成。消除在製品還可以作為從待辦事項清單中「拉取」新工作項目的訊號，因為現在有了新的處理能力。
極限編程（XP）
極限編程（Extreme Programming，簡稱XP）是由敏捷宣言的合作者肯特·貝克（Kent Beck）在90年代末期創立的。與敏捷開發類似，它提倡高度的客戶參與和快速的回饋循環。 持續測試透過持續的計劃和緊密的團隊合作，以非常頻繁的間隔（通常每 1-3 週）交付可運行的軟體。
XP 的原始方法是基於四個簡單的價值觀：簡潔、溝通、回饋和勇氣。它也透過十二項關鍵的支持實踐來運作：
- 規劃遊戲
- 小規模發布
- 客戶驗收測試
- 簡單的設計
- 結對編程
- 測試驅動開發
- 重構
- 持續集成
- 集體代碼所有權
- 編碼標準
- 隱喻
- 永續速度
功能驅動開發（FDD）
功能驅動開發（FDD） 是敏捷方法論的一種變體，它描述了具體的、非常短的工作階段，每個功能都需要單獨完成這些階段。這些階段包括領域研究、設計、設計評審、編碼、程式碼評審以及發佈到建置階段。
FDD 的主要概念是，可以使用模型來描述產品的預期未來狀態，而開發功能有助於建立一個整體的產品模型，該模型由「在客戶眼中有用」的東西來表示。
FDD 推薦了一些特定的程式設計師實踐，例如「定期建置」和「組件/類別所有權」。 FDD 的支持者聲稱，與其他方法相比，它更容易擴展，並且更適合大型團隊。
動態系統開發方法（DSDM）
DSDM 是敏捷開發的另一個早期雛形，最早在 1994 年提出。 DSDM 的雛形源自於快速應用開發 (RAD)，目標是標準化… 軟件交付 框架。隨著敏捷方法的出現，DSDM 進一步發展和成熟，為規劃、管理、執行和擴展敏捷流程和迭代軟體開發專案提供了全面的基礎。
DSDM 基於九項關鍵原則，主要圍繞著業務需求/價值、使用者積極參與、賦能團隊、頻繁交付、整合測試和利害關係人協作。 DSDM 特別強調「滿足業務需求」是系統交付和驗收的首要標準，重點關注系統中 80% 的有用功能，這些功能可以在 20% 的時間內部署完成。
DSDM 使用時間盒模型對某些交付成果進行優先排序，優先順序較低的項目會被預先選取並移到一邊，以便滿足時間盒的截止日期。
Crystal 水晶
Crystal 方法論是軟體開發中最輕量級、最靈活的方法之一。其核心原則包括團隊合作、溝通和簡潔性，以及透過反思來頻繁調整和改進流程。與其他敏捷方法論一樣，Crystal 提倡儘早、頻繁地交付可運行的軟體，強調使用者的高度參與、適應性，並消除繁文縟節和乾擾因素。
Crystal 實際上包含一系列敏捷方法論，例如 Crystal Clear、Crystal Yellow、Crystal Orange 等，它們的獨特特性受團隊規模、系統關鍵性和專案優先級等多種因素驅動。 Crystal 系列方法論旨在解決這樣一個問題：每個專案可能都需要一套略微客製化的策略、實踐和流程，以滿足其獨特的專案特性。
敏捷方法的優勢
敏捷方法各有其獨特的優點和用途，但以下優點通常是所有敏捷方法共同具備的：
- 軟體的工作版本交付速度相對較快且頻率較高。
- 建築的品質和完整性在建造過程的早期階段就能得到體現。
- 依賴關係和交付流程瓶頸被降至最低。
- 產品反映了根據客戶、競爭對手和整個市場發出的信號所了解的當前需求狀況。
- 創新可以在產品生命週期的任何階段引入。
- 協作意見來自所有團隊，而不是由高階顧問/行政人員/諮商師向下級下達指令。
- 與不強調功能性建構的開發週期相比，風險有所降低。
- 公司重視顧客滿意度和團隊士氣；如果兩者都不滿意，那就表示產品和流程無法滿足需求。
- 工作變得更加易於管理和預測，同時引入靈活性，以應對策略上的突發變化或乾擾。
敏捷方法中常用的最佳工具
敏捷方法中最推薦的一些工具包括：
- 敏捷規劃軟體: 提供看板和其他工具，用於管理產品待辦事項組合和規劃迭代。
- Release 編排軟體: 允許分配工作項，同時提供發布編排和自動化功能。
- Release Deployment 軟體: 簡化並自動化將新版本部署到作業系統環境（包括雲端和容器化環境）的過程。
- Continuous Testing 軟體：實現高效和 自動化測試 在整個開發過程中，降低風險和成本，同時加快交付速度。
- 商業智慧和分析解決方案: 創建單一資訊來源，提高發佈時間表、變更相關風險以及改善發布品質和價值交付機會的透明度。
