敏捷和瀑布的恩恩怨怨

是采用瀑布模型還是敏捷方法？網站Scrumology的站長David J Blant認為答案應該取決于對所要解決的問題和方案的了解程度。

David在他的文章中提出了以下幾個觀點：

1. 當幾乎完全了解所需解決的問題和方案的時候，用敏捷方法還是瀑布模型只是個人口味不同而已。

2. 當幾乎完全了解所需解決的問題但對相應的方案知之甚少的時候，敏捷方法行得通，而瀑布模型則不適用。

3. 當對要解決的問題和方案都幾乎知之甚少時，敏捷方法行得通，而瀑布模型則不適用。

在文章結尾處，David總結了他的觀點：

敏捷方法與瀑布模型之間的爭論曠日持久。短期內沒有一方打算退出，但這爭吵儼然成了白色噪聲(white noise)。它讓我們偏離了真正的問題，即我們是否都清楚要解決的問題或方案。

所以讓我們停止把所有的災難都歸咎于瀑布模型，相反大家捫心自問，我們是不是為手頭上的工作選擇了正確的工具。

此文在LinkedIn的敏捷群組中備受關注。起初很多跟帖都贊成David的觀點，但隨著大家的進一步討論，很多人逐漸清晰地認識到，在軟件開發過程中，需要解決的問題和相應的方案都很清晰的情況已經幾乎不存在了。比如來自Chris Shield的一條評論就談到：

我認為在軟件開發中永遠不可能100%了解解決方案——永遠不會。從第一天開始，就一直有變更，新的假設層出不窮，隨后假設再被證明是不成立的，業務部門的新需求姍姍來遲，等等。

Greg Robinson認為：

軟件開發本質上是一個探索和開發的過程，在此過程中，你歷經無數潛在方案蜿蜒前行，最終得到一個合適的最佳選擇。順著這個思路，你可以考慮從制造業流程中引入更多實踐，比如規劃藍圖、與每個人達成共識，但第一次構建就正確無誤地完成(OTOBOS)是最樂觀的情況，也是所有瀑布模型的根本性缺陷。應該說，即使是為一個兩周的sprint制訂計劃都很難，更何況是為項目做一年的詳細計劃了（你現在還打算不折不扣照著所謂的需求文檔做一年的計劃嗎，即使當時它們是正確的？）

其他的評論則討論了在軟件開發過程之初就已經非常了解所要解決的問題和/或方案的可能性。然而，似乎能夠一致確定的是，瀑布模型和敏捷方法在管理這類的項目時都能占有一席之地。

另外，我們也聽到了網上一些不同的聲音，包括Pawel Bradzinski撰寫的博文。他的觀點是：人，而不是流程或方法決定了軟件開發過程的成功。

另外有些人針對影響軟件開發的各種相關因素做了許多深入透徹的分析。Tom Peplow就在2008年給出過很棒的建議。

作者 Christopher R. Goldsbury 譯者 金毅