瀑布模型已經被實踐證明是不適用於絕大部分軟體開發專案的，如果說還有專案“可以”採用瀑布模型的話，它也完全可以採用更加先進的開發模型獲得更好的效果。事實上，還是有很多專案採用瀑布模型開發，與此對應的事實是，一半的軟體開發專案都可以稱之為“失敗”。

最近看了本書叫Manage Project with Growth,從理論上解釋了為什麼瀑布式模型不適用於軟體開發，以及為什麼這樣的模式還在大量被採用。

瀑布模型，也就是先計劃然後收集需求、然後分析、然後設計、然後編碼、然後測試的開發模式，這起源於其他類別的工程學，如建築和機械生產，軟體工程出現的比這些硬體工程晚的多，沒有辦法，一開始只有學習其他工程的份，但是到了二十一世紀，還是對這種生產方式執迷不悟，就太不應該了。

二十世紀初一個Taylor的美國人對生產過程做了細緻的研究，這哥們出生貴族，他認為原有的生產方式很大的弊端是manager不是管理，只是在監督，工人完全按照自己的方式生產，Taylor認為manager有責任瞭解工作性質，指定出嚴格的process，工人不能自己想怎麼幹就怎麼幹，需要按照統一的process來工作，簡而言之，即使manager動腦，工人出力。Taylor的觀點被稱為Talyorism，透過實踐證明這種觀點在生產性的工業中是正確的，軟體工程的前輩們自然而然的就將Talyorism應用到軟體開發中了。

Talyorsim對可以預見結果的生產是適用的，之可惜軟體生產有其不同於其他工業的特點。軟體生產不是簡單的，如果硬體能夠達到軟體的複雜性的話，還需要軟體幹什麼；軟體生產不是可重複的，漢堡包可以被用同樣的方式生產無數次，但是每一次軟體開發幾乎有不同的問題需要解決......

傳統的工程學基於這樣的假設，生產過程是線性的，即有這樣的特點
1）結果是輸入之和；
2）小的改變只產生小的影響；
3）結果是可以預測的。

但是軟體開發不是簡單系統，不是線性的。根據混沌理論，非線性的過程結果是無法預料的，因為一點點的輸入改變可能產生巨大的結果改變（此書作者一定是一個工程師出生，引經據點都是工程師的經歷和口吻，提到1986年MIT一個氣象研究者最早發現混沌現象）。

既然軟體開發是一個混沌過程，那麼一開始所謂周詳的計劃，再到周詳的需求分析，還有周詳的設計文件，都價值不大，因為一個小小的改變就讓大量的人力投入變成白費勁。還好混沌的過程不是完全失去控制的，有的情況下開始的工作多少還是有點作用，但是某些時候（不幸的是這樣的時候很多）會產生重創。

但是很多軟體專案的manager為什麼還是用老式的工程方法來管理專案呢？此書透過心理學分析，引文manager需要心理上的安慰，透過制定不切實際的計劃，獲得“專案在可控制之中”的心理暗示，如果實際專案沒有按照計劃進行，出現延誤現象，可以說“沒有做好計劃“，於是陷入尋找一種指定”好計劃“的陷阱，殊不知，絕大多數情況下，更本不可能一開始就指定出”好計劃“，隨機應變才是最好的計劃。

專案失敗的時候，manager可以說，我已經指定了計劃，只不過計劃沒有切實得到執行；如果專案成功哦你了或者勉強成功了，mananger又會說，計劃發生功效了。似乎這樣的生產方式永遠能夠存活下去，這種方式能夠存活是因為在一定範圍內普遍還是採用這種方式，敵我都有傷亡，如果有一支力量能夠打破這種局面，採用先進的方式，獲得更高的生產力，整個行業的生產方式就有可能得到改變。

至於什麼是先進的方式，莫衷一是。個人認為對絕大多數軟體開發，迭代式(iterative)開發是正途。不完全拋棄計劃，但是不要一開始指定死板不切實際的計劃，制定just enough的計劃，然後隨著專案的推進不斷的完善計劃。迭代式開發也不是銀彈，也有陷阱，再說了。[@more@]

混沌理論和專案管理（轉）

相關文章