靈活開發和瀑布開發的差別

• 引言
• ”靈活”的理由
• “瀑布”對“靈活”的駁斥
• 焦點碰撞
• 靈活開發的優勢
• 靈活開發的劣勢：
• 瀑布開發的優勢
• 瀑布開發的劣勢
• 結論

引言

最近和朋友談起靈活開發和瀑布開發模式，很多人認為靈活開發是未來的項目實施的趨勢，瀑布實施太老土已經過時了。另外确實一些跨國企業如索尼，聯想也在使用靈活的方式實施一些項目。但實際上我們看到絕大多數公司還是依然在采用瀑布的方式實施項目。我之前參與過靈活開發的項目，但當時比較“年輕”，認識不是很深刻，于是最近又補習了下和大家一起分享下我對靈活和瀑布的感悟。

”靈活”的理由

在靈活看來，很多情況下面，我們都無法去了解到全部的内容，或者即使是了解到，我們也不能保證這些内容是不會變化的。是以先根據主路徑，完成主要功能後，我們再通過不斷地疊代，去完善我們的工作，這樣當我們産生變化的時候，我們推翻的工作量也是少量的，可以很快的去完成新的需求變更。通過這樣的不斷地變更、重構，我們可以獲得一個相對客戶滿意的産品。

對于瀑布的開發模型來看，似乎依然具備很可靠的工作邏輯，一個工程或項目分為多個階段，每一個階段都投入相應的資源，來完成本階段的工作。每一個階段到下一個階段，都有明确的輸入輸出産物，不同的階段根據自己所需的輸入，進行工作活動之後，産生自己階段的産出，投入到下一個階段的工作中。如果不放心的話，每一個階段還可以增加一個審批環節，讓每一個環節都可以經過可靠的審批之後，再投入到下一個環節當中。

很多支援靈活的同學會說瀑布缺乏與業務的溝通和疊代次數，是以如果在項目的後期才發現要更改需求的話，則項目可能會失敗或需要重新啟動。這張圖好像也解釋了瀑布開發經常所面臨的困境。

在高舉效率與擁抱變化的大旗之下，似乎靈活模式，就是最好的開發模式。與之相比的是瀑布模式，在這樣的呼喊之中，顯得有些無法跟得上步伐，展現的是陳舊、死闆的。

“瀑布”對“靈活”的駁斥

靈活本身不是項目管理架構，也不是“方法論”。它是一套與産品開發相關的原則和價值，特别是網際網路産品經常會采用靈活的方法來進行開發。但是，有一些基于靈活原則的方法，這些方法是産品開發方法，而不是項目管理架構。

說到需求變更，瀑布也可以走需求變更，提變更申請，按照環節一步一步走，去規劃工作量。雖然比靈活是要慢一些，但是我整個流程是可靠的！為什麼就說瀑布是死闆的，不符合時代的呢？

似乎瀑布的做法也沒有錯誤，我們何不按照這樣的步驟，來完成我們的工作呢？這樣的過程聽起來是如此的可靠。看，我有明确的階段；看，我有明确的審批；看，我有明确的變更流程。以瀑布模式進行開發的項目有這麼多，已經證明了這是一個有效的實施方法，難道不是麼？

另外被靈活所诟病的瀑布項目經常失敗通常是發生了非常嚴重的錯誤情況下才會産生。實際上隻有在對項目的控制很差的情況下才會發生這種情況。瀑布型項目沒有疊代和使用者的多次回報也是不正确的 - 很多項目可以通過産品原型圖的方式和業務部門确認操作的流程，隻是很多項目中并沒有使用這種方法。

焦點碰撞

靈活模式，兩周一個疊代，每個疊代都能進行一定功能子產品的傳遞，讓使用者更早的看到傳遞物，雖然隻有部分，也可以讓使用者來提出自己的看法，産生變更的時候，開發人員也可以在下個疊代中進行修改，讓使用者進行再次的确認。

看來，兩者的碰撞就是在傳遞的及時性上與面對變更的成本上，所看到有極大的變化。瀑布在傳遞階段比較靠後，傳遞的子產品比較完整，在面對變更的時候，變更影響範圍就比較大，變更的成本就極大。問題發現的階段越靠後，解決問題所需要付出的成本就更高。這樣，就展現出來了靈活對瀑布在這樣的情景下面的優勢。

時間和成本，看起來就是靈活和瀑布在選擇時主要考慮的兩個方面。未來能更好的指導未來的選擇，下面還列出了更詳細的靈活和瀑布的優劣勢。

靈活開發的優勢

開發的階段性成果會在開發過程中盡早的進行審查，項目的風險會降低；

适用于需求不明确情況，因為需求不明确，是以需要在不斷疊代的過程中來逐漸理清需求。

靈活性較高，幾乎可以在任何時間進行需求變更；

靈活鼓勵開發人員與業務使用者之間進行多頻次的溝通，業務使用者的不合理需求以及開發人員的錯誤了解都會在這些頻繁的溝通中進行不斷審查和更新，

靈活的協作通常要高得多，通常能開發出更高品質的産品；

适用于快速變化的項目，特别是面向前端業務人員的CRM項目更容易根據業務的變化而變化。

靈活開發的劣勢：

靈活的概念接受度還不算太高，初次嘗試可能不會非常成功；

最終傳遞的内容無法預測，預期和實際完成的内容經常會有很大差異；

靈活需要高水準的協作以及開發人員和使用者之間的定期溝通。 業務和IT人員在溝通前需要做大量的準備工作，但很多情況下業務的溝通時間無法保證；

當存在乙方供應商的情況，靈活會面臨更大的挑戰性。 客戶通常希望盡早了解他們的項目投入。 預估項目時間和成本難度較高；

在靈活項目中，最大的問題可能是業務部門永遠不希望有最終的截止時間。

瀑布開發的優勢

在管理良好的項目中，瀑布可以在早期提供傳遞的信心；

項目團隊成員不需要在同一地點頻繁溝通；

在需要大量的設計或分析的情況下瀑布是一種更合适的方法；

如果在基本産品開發之外存在許多接口和依賴關系，瀑布式項目會使用工具來模組化和管理這些接口和依賴關系。

瀑布開發的劣勢

許多企業和業務人員确實不容易在前期定義清楚需求，早期計劃中所依據的假設需求可能存在很大風險；

溝通的風險要高得多 - 特别是很多項目都是前期單向的溝通，後期項目和業務人員的預期差别很大；

瀑布項目的風險一般都很高，因為基于無效假設基礎上的需求可能會讓項目無限度擴大。 是以你會看到很多瀑布項目都出現成本超出預算或延遲的情況。

結論

靈活和瀑布的實施方法差别還是很大的，瀑布幾乎可以應用于任何類型的項目，尤其是大型的項目。

靈活方法今年來越來越受歡迎，尤其是目前SaaS軟體當道，特别像Salesforce這樣自帶開發平台的SaaS産品可以非常容易的搭建初始原型并進行快速疊代，是以我們才會看到有越來越多的企業采用靈活的方式來進行項目實施。總的來說靈活并不能完全替代瀑布，它隻是給了我們另外一種好的選擇。