最近和朋友談起敏捷開發(fā)和瀑布開發(fā)模式，很多人認(rèn)為敏捷開發(fā)是未來的項(xiàng)目實(shí)施的趨勢，瀑布實(shí)施太老土已經(jīng)過時了。另外確實(shí)一些跨國企業(yè)如索尼，聯(lián)想也在使用敏捷的方式實(shí)施一些項(xiàng)目。但實(shí)際上我們看到絕大多數(shù)公司還是依然在采用瀑布的方式實(shí)施項(xiàng)目。這里和大家一起分享下敏捷開發(fā)和瀑布開發(fā)的區(qū)別。

 

”敏捷”的理由
在敏捷開發(fā)看來，很多情況下面，我們都無法去了解到全部的內(nèi)容，或者即使是了解到，我們也不能保證這些內(nèi)容是不會變化的。所以先根據(jù)主路徑，完成主要功能后，我們再通過不斷地迭代，去完善我們的工作，這樣當(dāng)我們產(chǎn)生變化的時候，我們推翻的工作量也是少量的，可以很快的去完成新的需求變更。通過這樣的不斷地變更、重構(gòu)，我們可以獲得一個相對客戶滿意的產(chǎn)品。

 

對于瀑布的開發(fā)模型來看，似乎依然具備很可靠的工作邏輯，一個工程或項(xiàng)目分為多個階段，每一個階段都投入相應(yīng)的資源，來完成本階段的工作。每一個階段到下一個階段，都有明確的輸入輸出產(chǎn)物，不同的階段根據(jù)自己所需的輸入，進(jìn)行工作活動之后，產(chǎn)生自己階段的產(chǎn)出，投入到下一個階段的工作中。如果不放心的話，每一個階段還可以增加一個審批環(huán)節(jié)，讓每一個環(huán)節(jié)都可以經(jīng)過可靠的審批之后，再投入到下一個環(huán)節(jié)當(dāng)中。

很多支持敏捷開發(fā)的同學(xué)會說瀑布缺乏與業(yè)務(wù)的溝通和迭代次數(shù)，所以如果在項(xiàng)目的后期才發(fā)現(xiàn)要更改需求的話，則項(xiàng)目可能會失敗或需要重新啟動。這張圖好像也解釋了瀑布開發(fā)經(jīng)常所面臨的困境。

在高舉效率與擁抱變化的大旗之下，似乎敏捷開發(fā)模式，就是更好的開發(fā)模式。與之相比的是瀑布模式，在這樣的呼喊之中，顯得有些無法跟得上步伐，體現(xiàn)的是陳舊、死板的。

 

“瀑布”對“敏捷”的駁斥
敏捷開發(fā)本身不是項(xiàng)目管理框架，也不是“方法論”。它是一套與產(chǎn)品開發(fā)相關(guān)的原則和價值，特別是互聯(lián)網(wǎng)產(chǎn)品經(jīng)常會采用敏捷的方法來進(jìn)行開發(fā)。但是，有一些基于敏捷原則的方法，這些方法是產(chǎn)品開發(fā)方法，而不是項(xiàng)目管理框架。

 

說到需求變更，瀑布開發(fā)也可以走需求變更，提變更申請，按照環(huán)節(jié)一步一步走，去規(guī)劃工作量。雖然比敏捷開發(fā)是要慢一些，但是我整個流程是可靠的！為什么就說瀑布是死板的，不符合時代的呢？

 

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

 

另外被敏捷開發(fā)所詬病的瀑布開發(fā)項(xiàng)目經(jīng)常失敗通常是發(fā)生了非常嚴(yán)重的錯誤情況下才會產(chǎn)生。實(shí)際上只有在對項(xiàng)目的控制很差的情況下才會發(fā)生這種情況。瀑布開發(fā)項(xiàng)目沒有迭代和用戶的多次反饋也是不正確的 - 很多項(xiàng)目可以通過產(chǎn)品原型圖的方式和業(yè)務(wù)部門確認(rèn)操作的流程，只是很多項(xiàng)目中并沒有使用這種方法。

 

焦點(diǎn)碰撞
敏捷開發(fā)模式，兩周一個迭代，每個迭代都能進(jìn)行一定功能模塊的交付，讓用戶更早的看到交付物，雖然只有部分，也可以讓用戶來提出自己的看法，產(chǎn)生變更的時候，開發(fā)人員也可以在下個迭代中進(jìn)行修改，讓用戶進(jìn)行再次的確認(rèn)。

 

從這樣看來，兩者的碰撞就是在交付的及時性上與面對變更的成本上，所看到有非常大的變化。瀑布開發(fā)在交付階段比較靠后，交付的模塊比較完整，在面對變更的時候，變更影響范圍就比較大，變更的成本就更大。問題發(fā)現(xiàn)的階段越靠后，解決問題所需要付出的成本就更高。這樣，就體現(xiàn)出來了敏捷開發(fā)對瀑布開發(fā)在這樣的情景下面的優(yōu)勢。

 

時間和成本，看起來就是敏捷開發(fā)和瀑布開發(fā)在選擇時主要考慮的兩個方面。未來能更好的指導(dǎo)未來的選擇，下面還列出了更詳細(xì)的敏捷和瀑布的優(yōu)劣勢。

 

敏捷開發(fā)的優(yōu)勢：
開發(fā)的階段性成果會在開發(fā)過程中盡早的進(jìn)行審查，項(xiàng)目的風(fēng)險(xiǎn)會降低；
適用于需求不明確情況，因?yàn)樾枨蟛幻鞔_，所以需要在不斷迭代的過程中來逐步理清需求；
靈活性較高，幾乎可以在任何時間進(jìn)行需求變更；
敏捷開發(fā)鼓勵開發(fā)人員與業(yè)務(wù)用戶之間進(jìn)行多頻次的溝通，業(yè)務(wù)用戶的不合理需求以及開發(fā)人員的錯誤理解都會在這些頻繁的溝通中進(jìn)行不斷審查和更新；
敏捷開發(fā)的協(xié)作通常要高得多，通常能開發(fā)出更高質(zhì)量的產(chǎn)品；
適用于快速變化的項(xiàng)目，特別是面向前端業(yè)務(wù)人員的CRM項(xiàng)目更容易根據(jù)業(yè)務(wù)的變化而變化。

 

敏捷開發(fā)的劣勢：
敏捷開發(fā)的概念接受度還不算太高，初次嘗試可能不會非常成功；
最終交付的內(nèi)容無法預(yù)測，預(yù)期和實(shí)際完成的內(nèi)容經(jīng)常會有很大差異；
敏捷需要高水平的協(xié)作以及開發(fā)人員和用戶之間的定期溝通。 業(yè)務(wù)和IT人員在溝通前需要做大量的準(zhǔn)備工作，但很多情況下業(yè)務(wù)的溝通時間無法保證；
當(dāng)存在乙方供應(yīng)商的情況，敏捷開發(fā)會面臨更大的挑戰(zhàn)性。 客戶通常希望盡早了解他們的項(xiàng)目投入； 預(yù)估項(xiàng)目時間和成本難度較高；
在敏捷開發(fā)項(xiàng)目中，較大的問題可能是業(yè)務(wù)部門永遠(yuǎn)不希望有最終的截止時間。

 

瀑布開發(fā)的優(yōu)勢：
在管理良好的項(xiàng)目中，瀑布開發(fā)可以在早期提供交付的信心；
項(xiàng)目團(tuán)隊(duì)成員不需要在同一地點(diǎn)頻繁溝通；
在需要大量的設(shè)計(jì)或分析的情況下瀑布是一種更合適的方法；
如果在基本產(chǎn)品開發(fā)之外存在許多接口和依賴關(guān)系，瀑布式項(xiàng)目會使用工具來建模和管理這些接口和依賴關(guān)系。

 

瀑布開發(fā)的劣勢：
許多企業(yè)和業(yè)務(wù)人員確實(shí)不容易在前期定義清楚需求，早期計(jì)劃中所依據(jù)的假設(shè)需求可能存在很大風(fēng)險(xiǎn)；
溝通的風(fēng)險(xiǎn)要高得多 - 特別是很多項(xiàng)目都是前期單向的溝通，后期項(xiàng)目和業(yè)務(wù)人員的預(yù)期差別很大；
瀑布開發(fā)項(xiàng)目的風(fēng)險(xiǎn)一般都很高，因?yàn)榛跓o效假設(shè)基礎(chǔ)上的需求可能會讓項(xiàng)目無限度擴(kuò)大。 所以你會看到很多瀑布項(xiàng)目都出現(xiàn)成本超出預(yù)算或延遲的情況。

 

結(jié)論：
敏捷開發(fā)和瀑布開發(fā)的實(shí)施方法差別還是很大的，瀑布幾乎可以應(yīng)用于任何類型的項(xiàng)目，尤其是大型的項(xiàng)目。

 

敏捷開發(fā)方法今年來越來越受歡迎，尤其是當(dāng)前SaaS軟件當(dāng)?shù)?，特別像Salesforce這樣自帶開發(fā)平臺的SaaS產(chǎn)品可以非常容易的搭建初始原型并進(jìn)行快速迭代，所以我們才會看到有越來越多的企業(yè)采用敏捷的方式來進(jìn)行項(xiàng)目實(shí)施?？偟膩碚f敏捷開發(fā)并不能完全替代瀑布開發(fā)，它只是給了我們另外一種好的選擇。