在軟體世界中，“瀑布”通常用於描述一種軟體過程樣式，該樣式與迭代樣式或敏捷樣式的思想形成對比。像軟體中的許多著名術語一樣，其含義不明確且來源不明確-但我發現其基本主題是根據活動將大量工作分解為多個階段。

目前尚不清楚“瀑布”一詞如何如此流行，但是大多數人都基於Winston Royce的論文，特別是這個數字：

儘管本文似乎被普遍認為是瀑布概念的來源（基於向下的級聯任務的形狀），但“瀑布”一詞在本文中從未出現過。目前尚不清楚該名稱後來如何出現。

Royce的論文描述了他對當時（60年代後期）軟體開發過程的觀察，以及如何改進通常的實現步驟。[1]但是，“瀑布”已經走得更遠了，被用來作為軟體開發風格的一般描述。對於像我這樣在軟體大會上講話的人來說，它幾乎總是以貶義的方式出現-我回想起多年以來沒有任何會議發言人說過有關瀑布的任何好訊息。但是，當與企業從業者交談時，我確實聽說它是一種可行的甚至首選的開發風格。

但是“瀑布”到底是什麼？這不是一個容易回答的問題，因為就像軟體中的許多東西一樣，沒有明確的定義。根據我的判斷，有一個共同的特徵主導著人們對瀑布的任何定義，那就是根據活動將精力分解為多個階段的想法。

讓我解開那個短語。假設我要構建一些軟體，並且我認為將花費大約一年的時間來構建它。很少有人會高興地說“離開一年，告訴我何時完成”。取而代之的是，大多數人希望將這一年分解成較小的部分，以便他們可以監控進度並有信心按計劃進行。那麼問題是我們如何進行這種分解？

正如羅伊斯（Royce）所暗示的那樣，瀑布式風格是通過我們正在做的活動來實現的。因此，我們的1年專案可能分為2個月的分析，4個月的設計，3個月的編碼和3個月的測試。此處的對比是一種迭代方式，在這種方式中，我們將滿足一些較高的要求（構建圖書館管理系統），並將其分為子集（搜尋目錄，預定書籍，退房和退貨，評估罰款）。然後，我們選擇其中一個子集，並花費幾個月的時間來構建可執行的軟體以實現該功能，並將其交付到暫存環境中，或者最好交付到現場製作環境中。完成一個子集的操作後，我們將繼續其他子集。

在這種思維中，瀑布意味著“一次為所有功能執行一項活動”，而迭代意味著“一次為一項功能執行所有活動”。

如果“瀑布”一詞的起源是模糊的，那麼基於階段的故障是如何產生的概念也是如此。我的猜測是，將大型任務分解為不同的活動是很自然的，尤其是當您以架構等活動為靈感時。每種活動需要不同的技能，因此在引入所有編碼人員之前讓所有分析師完成分析是很直觀的。在人們開始編碼之前，對需求的誤解如果在編碼之前解決肯定便宜得多，這似乎是合乎邏輯的，尤其是考慮到60年代後期的計算機狀態（banq注：現在計算機速度提高了，但是編碼效率並沒有提升，尤其相對於複雜系統）。最終，相同的基於活動的細分可以用作許多專案的標準，而基於功能的細分則更難教授。

儘管不難發現這裡解釋了為什麼有人認為這種瀑布式思維對於軟體開發不是一個好主意，這裡總結對瀑布式風格的主要反對意見：

瀑布樣式通常將測試和整合作為週期的兩個最後階段，但是這些是開發專案中最難預測的元素。這些階段中的問題導致早期階段許多步驟的返工，並導致大量專案延誤。將後期階段以外的所有階段都宣告為“完成”太容易了，缺少很多工作，因此很難判斷專案是否進展順利。在完成所有功能之前，沒有機會進行早期釋出。所有這些給開發工作帶來很大的風險。

此外，瀑布式方法迫使我們進入一種預測性的計劃風格，它假定一旦完成了階段（如需求分析），那麼可交付的結果就是以後階段進行工作的穩定平臺。實際上，由於每個人都對領域，軟體環境的特徵以及業務環境的變化有了更多的瞭解，因此絕大多數軟體專案都發現它們需要在幾個月內進行重大更改。實際上，我們已經發現，提供功能的子集比做任何事情都有助於澄清下一步需要做的事情，因此，迭代方法使我們可以轉向適應性計劃方法，在學習真正的軟體內容時可以更新計劃需要。

這就是為什麼我曾大膽地說 “您應該僅在要成功的專案中使用迭代開發”的主要原因。

瀑布和迭代可能相互巢狀。一個為期六年的專案可能包含兩個為期三年的專案，其中兩個專案均以瀑布形式進行結構化，但是第二個專案新增了其他功能。您可以將其視為頂層的兩次迭代專案，而每次迭代都是一個瀑布。由於規模大且迭代次數少，我認為這主要是一個瀑布專案。相反，您可能會看到一個專案，每個專案有16個迭代，每個迭代一個月，其中每個迭代都是以瀑布樣式計劃的。我認為主要是迭代的。從理論上講，存在難以分類的中間專案的潛力，但在實踐中，通常很容易看出一種風格占主導地位。

瀑布式和迭代式混合是可能的，其中早期階段（需求分析，高階設計）以瀑布樣式完成，而後期（詳細設計，程式碼，測試）以迭代方式完成。這降低了後期測試和整合階段固有的風險，但無法進行自適應計劃。

瀑布通常被用作敏捷軟體開發的替代方案，但我認為這並非絕對正確。當然，敏捷過程需要迭代的方法，並且不能以瀑布形式工作。但是，遵循迭代方法（即非瀑布式）很容易，但並不敏捷。為此，我可能會採用100個功能並將它們在明年劃分為十個迭代，然後期望每個迭代應按計劃的功能集按時完成。如果這樣做，我的最初計劃是一個預測性計劃，如果一切順利，我應該期望工作緊跟計劃。但是 適應性的計劃是敏捷思維的必不可少的要素維。我希望功能會在迭代之間移動，會出現新功能，並且由於不再有價值而將許多功能丟棄。

我的經驗法則是，任何說“我們成功的原因是我們準時且按預算”的人都在按照預測性計劃進行思考，即使他們遵循的是迭代過程，因此也不以敏捷的思維方式思考。在敏捷的世界中，成功與商業價值息息相關-不管幾個月前計劃中寫了什麼。計劃已制定，但會定期更新。它們指導下一步的決策，但不作為成功的衡量標準。

（banq注：任何說“按照這種方式肯定成功”的人都在按照預測性計劃進行思考）