敏捷開發，首先把客戶最關注的軟體原型先做出來，交付或者上線，在實際場景中去修改彌補需求中的不足，快速修改，再次發布版本。再次上線或者交付。通過一些敏捷實踐方式，細化story，可以提供更小的迭代。如此迴圈，直到使用者（客戶）滿意。適用於需求不明確的專案、創新性的專案或者需要搶占市場的專案。
瀑布式開發，要求明確的需求，大家按照需求一步步做好規劃，在專案運作過程中嚴格產出各種文件，按著流程一步步走下去。這種模式一般適用於需求比較明確、to b端專案
但總的來說，在現在管理專案過程中，並沒有嚴格的按照完全的敏捷或者完全的瀑布模式，都是各自摻雜了其他的方式。在實際專案過程中，過於強調模式並沒有意義，重要的是能不能預防問題的發生，在問題發生之後能不能用最小的成本解決，模式更多起乙個參考作用
2023年溫斯頓·羅伊斯（winston royce）提出了著名的「瀑布模型」，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。
瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計畫、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序， 如同瀑布流水，逐級下落。
(1)為專案提供了按階段劃分的檢查點。
(2)當前一階段完成後，您只需要去關注後續階段。
(3)可在迭代模型中應用瀑布模型。
增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生乙個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。
(1)在專案各個階段之間極少有反饋。
(2)只有在專案生命週期的後期才能看到結果。
(3)通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
(4)瀑布模型的突出缺點是不適應使用者需求的變化。
在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。實質上，它類似小型的瀑布式專案。rup認為，所有的階段都可以細分為迭代。每一次的迭代都會產生乙個可以發布的產品，這個產品是最終產品的乙個子集。
(1)在專案開發早期需求可能有所變化。
(2)分析設計人員對應用領域很熟悉。
(3)高風險專案。
(4)使用者可不同程度地參與整個專案的開發過程。
(5)使用物件導向的語言或統一建模語言（unified modeling language，uml）。
(6)使用case（computer aided software engineering，計算機輔助軟體工程）工具，如rose（rose是非常受歡迎的物件軟體開發工具。）。
(7)具有高素質的專案管理者和軟體研發團隊。
與傳統的瀑布模型相比較，迭代過程具有以下優點：
(1)降低了在乙個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這乙個開發有誤的迭代的花費。
(2)降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙。
(3)加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
(4)由於使用者的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。
敏捷開發是一種從2023年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。相對於「非敏捷」，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本。能夠很好地適應需求變化的**編寫和 團隊組織方法，也更注重軟體開發中人的作用。敏捷建模（agile modeling，am）的價值觀包括了xp的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴充套件了第五個價值觀：謙遜。
(1)人和互動 重於過程和工具。
(2)可以工作的軟體 重於求全而完備的文件。
(3)客戶協作重於合同談判。
(4)隨時應對變化重於循規蹈矩。
專案的敏捷開發,敏捷開發小組主要的工作方式可以歸納為：作為乙個整體工作； 按短迭代週期工作； 每次迭代交付一些成果:關注業務優先順序； 檢查與調整。最重要的因素恐怕是專案的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。
螺旋模型是一種演化軟體開發過程模型，它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個迭代階段構建原型是螺旋模型用以減小風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟體應用。
2023年，巴利·玻姆(barry boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。
快速原型模型需要迅速建造乙個可以執行的軟體原型 ，以便理解和澄清問題，使開發人員與使用者達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟體產品。 快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向使用者展示待開發軟體的全部或部分功能和效能；使用者對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至使用者滿意認可之後，進行軟體的完整實現及測試、維護。
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每乙個開發階段都要做到最好。特別是前期階段，設計的越完美，提交後的成本損失就越少。
迭代式開發，不要求每乙個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來為目的，以最短的時間，最少的損失先完成乙個「不完美的成果物」直至提交。
然後再通過客戶或使用者的反饋資訊，在這個「不完美的成果物」上逐步進行完善。
螺旋開發，很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的迴圈之前，都必須首先進行風險評估。
敏捷開發，相比迭代式開發兩者都強調在較短的開發周期提交軟體，但是，敏捷開發的週期可能更短，並且更加強調隊伍中的高度協作。敏捷方法有時候被誤認為是無計畫性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。適應性的方法集中在快速適應現實的變化。當專案的 需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化。
敏捷開發和瀑布開發的區別
個人覺得 敏捷開發強調以人為中心,快速迭代，客戶參與多溝通，減少不必要的文件,包括scrum和xp 優點 快速適應變化,做出的專案比較接近客戶需要的 缺點 文件不多，如果人員流動大，維護相對更難 瀑布開發強調文件，就是不同階段按照順序自上而下而來，如需求 設計 編碼 測試 單元測試 系統測試 維護，...
敏捷開發和瀑布開發的區別
最近和朋友談起敏捷開發和瀑布開發模式，很多人認為敏捷開發是未來的專案實施的趨勢，瀑布實施太老土已經過時了。另外確實一些跨國企業如索尼，聯想也在使用敏捷的方式實施一些專案。但實際上我們看到絕大多數公司還是依然在採用瀑布的方式實施專案。我之前參與過敏捷開發的專案，但當時比較 年輕 認識不是很深刻，於是最...
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...