是一種從2023年代開始逐漸引起廣泛關注的一些新型
軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的**編寫和團隊組織方法，也更注重做為軟體開發中人的作用。
敏捷一詞**於2023年初
美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會
在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如迭代開發，關注互動溝通，減少中介過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通澤決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：
組織文化必須支援談判人員彼此信任，人少但是精幹，開發人員所作決定得到認可，環境設施滿足成員間快速溝通之需要。最重要的因素恐怕是專案的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，20、40人或者更少。大規模的
敏捷軟體開發尚處於積極研究的階段。
另外的問題是專案初期的大量設想或快速的需求收集可能導致專案走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將專案目標和設計引入錯誤方向的境況。開發者經常會把不恰當的方案授予客戶，而直到最後出問題前都能獲得客戶認同。雖然理論上快速互動的過程可以限制這些錯誤的發生，但前提是有效的負反饋，否則錯誤會迅速膨脹。
敏捷方法有時候被誤認為是無計畫性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當專案的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.相比迭代式開發兩者都強調在較短的開發周期提交
軟體，敏捷方法的週期可能更短，並且更加強調隊伍中的高度協作。兩者沒有很多的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，
測試計畫和**審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，專案早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在專案進行過程中可能變化的情況下基本是不可行的。
相對來講，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡量小的可用的功能交付使用，並在整個專案週期中持續改善和增強。
有人可能在這樣小規模的範圍內的每次迭代中使用瀑布式方法，另外的人可能將選擇各種工作並行進行，例如
開發模式之敏捷
今天在公司等復聯3的首映，無聊之餘想起來好久沒寫部落格吹牛b了，借這點時間補一下之前瀑布開發的續集。之前也分享過瀑布模型，關鍵乙個字 細 瀑布流式的節奏，充分利用資源避免浪費，重規劃輕迭代，去繁從簡，找關鍵指標，避免反覆試錯，節省迭代壓力。而今天的主題，敏捷開發恰恰相反。敏捷開發的關鍵字 快 將專案...
敏捷開發模式學習筆記
前言 資訊來自網路,沒有原創,只是當成筆記儲存而已 典型的開發模式 流程 調研 開發 測試 驗收 上線 一次 付 缺點 1.研發周期長 2.研發不能很好的相應需求變化 3.風險控制不到位 改善 1.小團隊 2.分析需求與業務同步交流 3.需求池,按照先後順序開發 4.客戶參與研發 1.挑選代表性專案...
敏捷開發 重構與設計模式
最近，同事 朋友跟我聊天的過程中，提到了設計模式方方面面的問題。隨著物件導向 敏捷開發的深入人心，越來越多的程式設計師希望能夠借助設計模式，使自己的 更利於重用 更利於被人理解 可靠性更 不同的情況下需要用什麼樣的模式，如何實現這些模式，在各類著作中已經介紹的相當清晰了，但是關於設計模式實現的時機，...