敏捷軟件開發

敏捷開發是一種從1990年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種能應對快速變化需求的軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟件開發中人的作用。

敏捷軟件開發描述了一套軟件開發的價值和原則，在這些開發中，需求和解決方案皆通過自組織跨功能團隊達成。敏捷軟件開發主張適度的計劃、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多軟件開發方法的定義和持續進化。 ^[1] 

敏捷一詞來源於2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會。 ^[1] 

雪鳥會議共同起草了敏捷軟件開發宣言。其中最重要的部分就是對一些與會者一致同意的軟件開發價值觀的表述：

人機交互重於過程和工具。可以工作的軟件重於求全責備的文檔。客户協作重於合同談判。隨時應對變化重於循規蹈矩。其中位於右邊的內容雖然也有其價值，但是左邊的內容最為重要。 ^[1] 

宣言中還包括以下內容：

對我們而言，最重要的是通過儘早和不斷交付有價值的軟件滿足客户需要。我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客户的競爭優勢。經常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好。業務人員和開發者應該在整個項目過程中始終朝夕在一起工作。圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。可以工作的軟件是進度的主要度量標準。敏捷過程提倡可持續開發。出資人、開發人員和用户應該總是維持不變的節奏。對卓越技術與良好設計的不斷追求將有助於提高敏捷性。簡單--儘可能減少工作量的藝術至關重要。最好的架構、需求和設計都源自自我組織的團隊。每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。 ^[1] 

敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的説法是敏捷方法強調適應性而非預見性。

適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.

相比迭代式開發兩者都強調在較短的開發週期提交軟件，敏捷方法的週期可能更短，並且更加強調隊伍中的高度協作。

兩者沒有很多的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閲等等。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

相對來講，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡量小的可用的功能交付使用，並在整個項目週期中持續改善和增強。 ^[2] 

在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如迭代開發，關注互動溝通，減少中間過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：

組織文化必須支持談判人員彼此信任，人少但是精幹，開發人員所作決定得到認可，環境設施滿足成員間快速溝通之需要，最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，20、40人或者更少。大規模的敏捷軟件開發尚處於積極研究的領域。

另外的問題是項目初期的大量假定或者快速收集需求可能導致項目走入誤區，特別是客户對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將項目目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客户，並且直到最後發現問題前都能獲得客户認同。雖然理論上快速交互的過程可以限制這些錯誤的發生，但前提是有效的負反饋，否則錯誤會迅速膨脹。 ^[2] 

已經有一些項目管理工具用於敏捷開發，可以用它們來幫助規劃，跟蹤，分析和整合工作。 這些工具在敏捷開發中扮演的重要的角色，也是知識管理的一種方法。

通常包括：版本控制整合，進度跟蹤，工作分配，集成發佈和迭代規劃，論壇和軟件缺陷的報告和跟蹤。 ^[2] 

列入敏捷方法的有：