顯然，團隊，客戶，投資回報率等方面對應用這兩種方法的影響是巨大的，是許多書籍和無盡的討論和會議的主題。發佈頻率是敏捷和瀑布之間唯一真正的區別嗎？
但是當我想到更多關於它的時候，我很難找到兩者之間的任何區別，它們最終不會映射到單個根差異，即發佈頻率。
瀑布在設計上花費時間，然後編寫代碼，然後測試並最終釋放。但是敏捷完成同樣的步驟 - 只是每個步驟都更小。
敏捷方法的一個關鍵部分就是從每個發佈中學習並使用它來讓更大的設計出現，而不是在開始時嘗試預測它。
但瀑布也這樣做。它只是代替每3或4周學習一次，瀑布團隊每6或9個月才學習一次。但瀑布設計仍然出現。也就是說，瀑布版本2將反映在版本1中學到的東西。所以這個過程沒有什麼不同，只是它以不同的速度執行。
敏捷專注於密切客戶協作。但瀑布也是這樣。它只是因爲瀑布的迭代時間較長，所以需要以合同的形式列舉需求列表以更長時間地保持每個人在同一頁面上。但是，這只是一個頻率的人造物。交付頻率越高，合同需求越低。
是否還有其他原始的差異，我缺少 - 或者它只是頻率？
瀑布：
敏捷：
user story）第一（之後的每個要素，完成或時間盒裝時間後（通常稱爲sprint或iteration））
的區別是很清楚的給我。
隨着敏捷，你可以通過頻繁提供一小部分軟件來適應構建什麼。足夠的時候你可以停下來。
這是一個好點 - 通過敏捷，您可以在*功能*完成時開始測試。通過使用瀑布，您可以在完成*整個產品*時開始測試，從而實現更長的端到端循環。 – 2010-08-21 17:27:18
如果我打算討厭，我可能想要交換測試/構建 - 作爲TDD的倡導者，我是:-)如果文檔是必需的，我也只會記錄文檔。我會設計成我以前去過的，而不是所有的前面:-) – adrianh 2010-08-21 17:28:16
哈哈！讓我改變這個 – 2010-08-21 17:29:03
一個不同之處在於透明度：開發團隊之外的人員在開發週期中是否對流程，進度，障礙以及最終結果的外觀具有可見性。
瀑布並不意味着透明度。通常（雖然不一定），它被實現爲「程序員進入他們的洞穴，並且用」完成的產品「出現在n周/個月之後。業務專家預先寫好規格說明，這可能是他們參與的結束 - 當程序員在實施過程中遇到問題時，他們可能不再可用。程序員可能不會向任何人顯示任何交付物，直到週期結束。
敏捷要求透明 - 它是基本結構的一部分。團隊以外的人將（或至少可以）看看團隊正在做什麼。 （如果不是這樣，團隊就是說要成爲敏捷）。這可能是Scrum每日站立式會議，或者大型可見圖表和信息散熱器，或迭代結束時的演示。這可能是XP要求客戶做出所有業務決策，而不是讓程序員在需求不明確時盲目選擇一個選項。測試人員和客戶可能被認爲是團隊的一部分，而不是單獨的團隊。
您當然可以可能運行瀑布透明度，並在一個經營良好的瀑布店，你可能會。但對於敏捷，這是一個給定的。
更快的反饋 - 在所有規模上，不僅僅是發佈，當然是許多敏捷實踐中的一個共同因素。但我並不認爲這是敏捷的瀑布之間的主要區別。例如：
瀑布隊傾向於圍繞狹窄的專業化組建。分析師/建築師/設計師/編碼員/測試人員往往是獨立工作的人羣。敏捷團隊一起工作。
瀑布進程依賴於大量的文檔和切換。敏捷團隊以工作代碼/產品爲導向。
我不同意瀑布關注客戶協作。有一個單一的聯繫點，只有一小部分整體開發團隊，往往只在流程開始時進行。敏捷在整個開發過程中圍繞持續協作而建立。非常不一樣。
瀑布進程是圍繞這樣的想法構建的，您可以在開發開始之前完全定義產品&體系結構。敏捷流程是圍繞您隨時發現產品/架構的想法而構建的。
瀑布每年在設計時，然後編寫代碼，然後測試，最後釋放。但是敏捷完成同樣的步驟 - 只是每個步驟都更小。
敏捷不是一個單一的實體，而是許多不同方法的保護傘。
至少在其中的一些中，正如其他人所指出的，這些「階段」重疊得多得多，而且正常順序有所不同。
事實上，在XP，順序是或多或少：
哪種顛倒了大部分序列。
而測試，代碼和設計是在比發佈更精細的等級上完成的。
敏捷方法的一個關鍵部分就是從每個發佈中學習並使用它來讓更大的設計出現，而不是在開始時嘗試預測它。
但瀑布也這樣做。它只是代替每3或4周學習一次，瀑布團隊每6或9個月才學習一次。但瀑布設計仍然出現。也就是說，瀑布版本2將反映在版本1中學到的東西。所以這個過程沒有什麼不同，只是它以不同的速度執行。
這很大程度上取決於實踐。如DOD-STD-2167A（第4.1.1節）中所述，瀑布模型確實允許開發過程的階段重疊並重復（簡而言之，有點敏捷）。但大多數實際情況都錯過了，直到項目結束時纔有學習。
敏捷專注於密切客戶協作。但瀑布也是這樣。它只是因爲瀑布的迭代時間較長，所以需要以合同的形式列舉需求列表以更長時間地保持每個人在同一頁面上。但是，這只是一個頻率的人造物。交付頻率越高，合同需求越低。
再次依賴於練習。我沒有在上面提到的規範中看到很多客戶責任的提及，更不用說連續不斷。
正如Jerry Coffin在評論中指出的那樣，Waterfall確實是一位曾經支持敏捷的strawman（現在的確如此使用它......），但值得看一下這個文檔並思考它是什麼意味着它是如何應用的。
此規格所表現的內容是密切關注合同，計劃和文檔的交付和維護，並且遵守計劃。我相信確實轉化爲實踐。
與敏捷的對比不是時間框，而是價值的變化。
由於The Agile Manifesto這樣宣稱：
我們做它，幫助別人揭露開發 軟件的更好的方式做到這一點。 通過這項工作，我們都來的值：
個體和交互勝過過程和工具
工作的軟件勝過面面俱到的文檔
客戶協作勝過合同談判
響應變化勝過遵循計劃
也就是說，雖然 的項目中有價值的權利，但我們重視左邊的項目m礦石。
奇怪的是，這個值聲明沒有提到交付頻率（儘管下面的「原則」部分）。然而，確實然而將價值體系從計劃，文件和合同轉移回它所屬的地方，實際上交付工作軟件。
頻繁發佈是實現這些價值的機制。
如果你在「迷你瀑布」工作，它確實會比稻草人BDUF瀑布更敏捷。但是交付頻率當然不是整個故事。
馬克，
正如你指出的那樣，這兩種方法份額「好東西」，應該是每一個好項目。例如，採取這兩種方式：及早反饋和透明度。雖然敏捷確實有一個鼓勵這種結構的結構，但這兩個「好東西」也可以（也應該）在任何瀑布項目中。
但是，我傾向於（恭敬地！）不同意發佈頻率是唯一的區別。一個大幅區別如下：
瀑布每年在設計時， 然後編寫代碼，然後測試 終於釋放。但敏捷並沒有完全相同的步驟 - 它的 只是每一個都更小。
我不這麼認爲。 在敏捷中，您嘗試通過多學科團隊同時完成所有這些事情。 我說「嘗試」，因爲這不是一件容易做到的事情......但至少要幫助。
在傳統的瀑布，相反，你期望有單獨的團隊（研究/分析，質量保證，設計，營銷等），並在他們之間交接。只有在特殊情況下，或者當您需要在複雜項目中進行探索性研究或風險分析時，您纔可以混合學科並組成專門團隊。
只是我的兩分錢...
我真的很喜歡這個問題。
我曾與維修大規模瀑布項目的壞例子。最初的開發人員的交付成果是幾套文檔和一個代碼庫。一旦高層設計文件完成，它就交付了，並且再也不會更新。同上SRS，詳細設計等有文件，所有這些都不可靠和可疑。
隨着敏捷，有代碼。這位早已離開的開發人員認爲這是自我記錄，因爲他們在編寫項目時與項目保持同步。 （你是否曾經校對自己的備忘錄？他們總是對作者有意義。）我將嘗試從1500-2000個模塊中辨別出架構。同樣試圖找出高層設計。我會記下豐富的筆記。也許甚至活頁夾滿了。看着「自我記錄」代碼將告訴我正在做什麼（在該模塊中），但不是爲什麼。哦，是的，與開發者合作的員工被提升（或害怕），並且不再可用。
糟糕的敏捷並不比糟糕的瀑布更好。事實上，糟糕的敏捷可能比糟糕的瀑布更糟糕。好的瀑布比好的靈活得好嗎？
宣言對文件沒有提及。這裏真正的危險是，「敏捷」意味着許多開發人員和客戶需要一個快速便宜的英雄模型的理由。您認爲客戶是否喜歡閱讀高級設計的三厚三環式活頁夾？在計算機科學100中，我們都聽說軟件的大部分成本是維護，而不是開發。我認爲在這個討論中維護方面完全被忽略了嗎？
不同之處在於，現代客戶不能指定「敏捷」，因爲他們害怕被認爲落後。
像這樣的討論主題應該是維基。 – 2010-08-21 17:14:12
談論與瀑布模型的差異是愚蠢的 - 從第一天起，它就成了一個讓人們與他們所倡導的任何東西形成對比的稻草人。我相信有史以來第一次對瀑布模型的描述在：http：//www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf，它描述了它只是作爲一個對比哦，所以不可避免地要優越作者提倡的方法。 – 2010-08-21 17:36:47
不可以在答案中重複自己 - 你應該區分發布和準備發佈：http://www.andybrandt.net/637/to-release-or-not-to-release – Andy 2010-08-25 13:23:35