Agile — 敏捷
敏捷軟體開發方法論（Agile software development methodology），簡稱敏捷開發，是一個總稱，涵蓋了基於《敏捷軟體開發宣言》（Agile Manifesto）的核心價值觀及其12項原則的一系列軟體開發方法與系統分析實踐。敏捷開發的興起，主要是為了應對傳統瀑布式開發在面對快速變動的市場需求時，所暴露出的僵化與遞延交付風險。常見的敏捷框架與方法包含Scrum、看板（Kanban）、極限編程（XP）、動態系統開發方法（DSDM）、功能驅動開發（FDD）以及行為驅動開發（BDD）等。
核心概念與迭代開發
大多數敏捷方法旨在透過將開發週期劃分為多個迭代（Iteration；在Scrum框架中常稱為衝刺 Sprint）來最小化專案風險。迭代是一個相對較短且固定的時間區間，即「時間盒」（Timebox），通常為一至四週（最常見為兩至三週）。
每一個迭代猶如一個微型的軟體專案，包含了實現一小部分功能增量（Increment）所需的所有系統分析與開發任務：需求分析、規劃、系統設計、程式編寫、測試與文件撰寫。雖然單一次迭代通常不足以完成整個軟體產品的最終發布，但其核心目標是確保在迭代結束時，所產出的新增功能具備「可運作性」（Working），且達到潛在可發布的狀態（Potentially Shippable Increment）。
迭代的週期通常包含以下關鍵事件：
- 迭代規劃（Sprint Planning）：團隊根據產品待辦列表的優先順序，決定本次迭代要完成的任務。
- 每日站立會議（Daily Stand-up / Scrum）：每天15分鐘的同步會議，團隊成員分享進度、今日計畫與遇到的障礙。
- 迭代審查（Sprint Review）：迭代結束時向利害關係人展示可運作的軟體，取得回饋。
- 迭代回顧（Sprint Retrospective）：團隊內部反思本次迭代的流程與協作，找出持續改善的行動方案。
透過這種短週期的循環，團隊能夠迅速獲得使用者的回饋，並根據業務價值與市場變化，動態調整下一個迭代的開發優先順序，實現「擁抱變化」的核心精神。
團隊協作與角色
敏捷方法高度強調面對面溝通、高頻率的互動與跨職能協作。為了促進協作並減少資訊傳遞的損耗，多數敏捷團隊傾向於在同一個開放式辦公環境（有時稱為「牛棚」Bullpen 或共同協作區）中集中辦公；在遠端工作普及的現代，則依賴高頻率的視訊會議與線上協作工具來維持資訊透明。
一個標準的敏捷團隊（以最廣泛應用的Scrum為例）通常規模較小（建議5至9人），且具備自我管理的能力，主要包含以下關鍵角色：
- 產品負責人（Product Owner, PO）：代表客戶或業務發言人，負責定義產品願景、管理並排序產品待辦列表，並釐清開發團隊的疑問。此角色決定了「做正確的事」，可由專案經理、商業分析師（BA）或客戶端代表擔任。
- 開發團隊（Development Team）：包含程式開發人員、測試工程師（QA）、使用者介面（UI）/使用者體驗（UX）設計師等跨職能成員。團隊具備自我組織能力，共同決定「如何把事情做對」，而非由上而下指派任務。
- 敏捷教練 / Scrum Master：作為服務型領導者，負責確保團隊遵循敏捷原則與框架規則，保護團隊免受外部干擾，並協助排除開發過程中的障礙，促進團隊持續改善。
- 其他支援角色：如技術文件撰寫人員、DevOps工程師等，依專案需求彈性配置。
度量標準與價值觀
敏捷開發的進度度量標準與傳統方法（如瀑布模型）截然不同。傳統方法依賴於詳盡的階段性文件（如需求規格書、設計文件）與甘特圖來衡量進度；敏捷開發則以可運作的軟體（Working Software）作為衡量進度的首要指標。
《敏捷宣言》明確提出了四大核心價值觀：
- 個體與互動 重於 流程與工具
- 可運作的軟體 重於 詳盡的文件
- 客戶合作 重於 合約協商
- 應對變化 重於 遵循計畫
值得一提的是，右側的項目並非毫無價值，而是敏捷實踐者認為左側的項目更具決定性影響。這種「重溝通、輕文件」的特性，有時會被習慣傳統重量級方法論的觀點誤解為「缺乏紀律」或「允許隨意修改需求」。但實際上，敏捷方法極度強調工程實踐的紀律，例如：
- 測試驅動開發（TDD）：先寫測試再寫程式，確保程式碼品質。
- 持續整合/持續交付（CI/CD）：頻繁地將程式碼整合到主幹，自動化測試與部署，降低整合風險。
- 結對編程（Pair Programming）與程式碼審查（Code Review）：透過協作即時把關品質。
- 重構（Refactoring）：持續優化程式碼結構，避免技術債累積。
唯有透過嚴謹的工程紀律，敏捷團隊才能在快速應對變化的同時，確保軟體品質與系統穩定性，實現可持續的快速交付。