敏捷軟體開發（英語：Agile software development），又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的新型軟體開發方法，是一種能應對快速變化需求的軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發過程中人的作用。
基本介紹
- 中文名：敏捷軟體開發
- 外文名：Agile software development
- 別稱：敏捷開發
- 起源時間：1990年
概述,詞源,價值觀,四條原則,對比分析,適用性,管理工具,方法列表,敏捷技術,
概述
敏捷開發是一種從1990年代開始逐漸引起廣泛關注的新型軟體開發方法，是一種能應對快速變化需求的軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。
敏捷軟體開發描述了一套軟體開發的價值和原則，在這些開發中，需求和解決方案皆通過自組織跨功能團隊達成。敏捷軟體開發主張適度的計畫、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多軟體開發方法的定義和持續進化。
詞源
敏捷一詞來源於2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會。
價值觀
雪鳥會議共同起草了敏捷軟體開發宣言。其中最重要的部分就是對一些與會者一致同意的軟體開發價值觀的表述：
宣言中還包括以下內容：
對我們而言，最重要的是通過儘早和不斷交付有價值的軟體滿足客戶需要。我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。業務人員和開發者應該在整個項目過程中始終朝夕在一起工作。圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。可以工作的軟體是進度的主要度量標準。敏捷過程提倡可持續開發。出資人、開發人員和用戶應該總是維持不變的節奏。對卓越技術與良好設計的不斷追求將有助於提高敏捷性。簡單--儘可能減少工作量的藝術至關重要。最好的架構、需求和設計都源自自我組織的團隊。每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。
四條原則
- 遞增，而不是連續的：如果開發實踐是真正的敏捷精神，那么交付的工作軟體是一小部分一小部分遞增的。不必等到一個階段完全完成後才開始另一個，工作也不是向大的發布日期而努力。完成的工作，但並不是業務最終期限，驅動著敏捷交付。但敏捷精神也承認業務操縱著最後截止日期。
- 避免不必要的開銷：如果實踐仍然是真正的敏捷精神，那么團隊就致力於儘可能多地減少項目計畫和文檔。與其討論要做什麼，然後再寫下來，不如趕緊動手去做，否則，就是在浪費時間在工作的工作上。在工作對工作中，敏捷精神有利於實際的工——作交付工作軟體。而且它也值面對面的交流通過郵件和其他書面檔案。
- 協作：根據需求，團隊成員一直與其它人進行互動，以及一些外部利益相關者。在敏捷教練世界中，整個團隊的負責人Lisa Crispin能夠解決所有問題，在問題出現之前 。真正的敏捷精神團隊是自助的。他們分配需要做的工作。雖然每個成員承擔的任務都在他們的專業技能範圍內，他們還是需要與團隊協作的。沒有人的工作是孤立的，也沒有團隊本身是獨立工作的。沒有業務利益相關者，以及諸如用戶體驗方面的外部專家的重大投入，團隊就不可能使項目向前發展，
- 說真話：為了保證真正的敏捷，團隊探討的與項目相關的一切都要是真實的。在一些至關重要的專業領域，如衝刺測試的編碼技能，他們承認存在差距。關於實際生產力，他們的要講事實；這也就是說，在y時間內，團隊是否有能力做到x。他們承認錯誤。說真話是一項挑戰，因為他們害怕承認缺點會讓他們顯得很弱。但敏捷精神知道說出事實需要勇氣。承認問題需要信心，然後快速地去解決問題。
對比分析
敏捷方法有時候被誤認為是無計畫性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.
對比疊代方法
相比疊代式開發兩者都強調在較短的開發周期提交軟體，敏捷方法的周期可能更短，並且更加強調隊伍中的高度協作。
對比瀑布式開發
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。
適用性
在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如疊代開發，關注互動溝通，減少中間過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：
企業文化必須支持談判人員彼此信任，人少但是精幹，開發人員所作決定得到認可，環境設施滿足成員間快速溝通之需要，最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，20、40人或者更少。大規模的敏捷軟體開發尚處於積極研究的領域。
另外的問題是項目初期的大量假定或者快速收集需求可能導致項目走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將項目目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。雖然理論上快速互動的過程可以限制這些錯誤的發生，但前提是有效的負反饋，否則錯誤會迅速膨脹。
管理工具
方法列表
列入敏捷方法的有：
- 軟體開發之韻，Software Development Rhythms
- 敏捷資料庫技術，AD/Agile Database Techniques
- 敏捷建模，AM/Agile Modeling
- 自適應軟體開發，ASD/Adaptive Software Development
- 水晶方法，Crystal
- 特性驅動開發，FDD/Feature Driven Development
- 動態系統開發方法，DSDM/Dynamic Systems Development Method
- 精益軟體開發，Lean Software Development
- AUP（Agile Unified Process）
- XBreed
- 極限編程，XP Extreme Programming
- 探索性測試
