1.2 重新審視瀑布模式為代表的傳統開發方法

40多年前Winston Royce（1970）博士提出的瀑布開發模式（Managing the Development of Large Software Systems,1970年8月）對軟件的發展起到了一定的好的作用。這個開發生命周期識別出了軟件開發需要做的重要活動以及除代碼外的中間產出物。它對需求明確、開發技術成熟的項目確實有很好的指導作用。令人遺憾的是，40多年來絕大多數人忽略了Royce博士在他的文章里面的一句話“I believe in this concept but, the implementation described above is risky and invites failure.”這句話的意思是：“雖然我相信提出的概念，但是要注意，具體實施這個開發模式時會有很大的風險，它也可能帶來失敗。”

瀑布模式到底適用于什么樣的項目呢？如果下面這些假設是對的話，瀑布模式會是一個非常合適的軟件開發方法。

（1）客戶在項目開始時，可以準確描述他們真正需要的產品需求；而且開發團隊在整個開發過程中不需要客戶的任何反饋，僅需要客戶在項目結束時對實現的功能進行確認。

（2）開發團隊在項目開始時已經很清楚為完成開發工作所需要的一切：人、技術方法和工具等。

（3）項目的進展狀況可以通過里程碑完成的文檔（而非通過測試的代碼）來評估。我們也可以有效地將團隊分成4個不同的組：分析、設計、編碼和測試。雖然前面組的輸出是后面組的輸入，但這個接力過程不會有信心的流失。

（4）僅在項目結束時對代碼進行測試就能保證產品質量。

1.2.1 來自制造業的接力式開發模式

工業革命帶來的流水線生產模式極大提高了生產效率，同時通過對生產制造過程的持續完善改進，產品質量也得到了保證。雖然軟件瀑布開發有一條看不見的流水線，但它基本采用了生產線的思路。圖1-3是大家熟悉的瀑布式開發生命周期。

很明顯這是個接力過程。讓我們考慮一個最簡單的場景：我們需要在一個已有系統上追加一個功能特性。首先系統分析員會寫好一個描述需要實現功能的需求文檔，開發人員沒有機會和這些功能的使用者有任何溝通，他們將僅僅依賴于這個文檔完成代碼編寫。寫好的代碼被提交給測試人員，通過測試后，當剛剛實現的功能特性第一次展現給客戶時，如果客戶的反應是“這不是我要的！”，相信你不會太意外吧！

那么這是誰的錯呢？你可能會抱怨客戶一開始沒講清楚，也可能指責分析師沒有把需求寫清楚，程序員有可能成為替罪羊，測試人員也可能是主要的責任人。如果我們好好反思一下，也許真正的問題出在我們的方法上：在這個接力過程中，每個人只負責一段，沒有必要的反饋環，以保證及時發現問題、及時調整。任何階段出現的問題都會繼續被傳遞下去。同時在接力過程中，信息流失是經常發生的。記得看過一個5人參與的電視節目，第一個人做個動作給第二個人看，然后第二個人努力將看到的做給第三個人看，直到最后一個人做給觀眾看。往往最后一個人展示的動作已經和第一個人的原始動作相差很大了。正是這些差距讓觀眾哈哈大笑。

當這些差異在軟件開發過程中出現時，就一點也不好笑了。這些差異正是讓客戶、管理者、團隊頭疼的問題。

軟件產品開發由一系列互不相交的階段組成，瀑布模式要求上個階段所有工作完成并通過了出口檢查評審后，下個階段才可以開始。如設計工作應該在明確定義了所有產品需求，這些需求通過了相關評審后才會開始。實際情況是什么呢？如果讀者做一下調查，會發現95%的調查對象會承認設計工作在需求活動完成前已經開始了。這應該是業內公開的秘密，所以很少有團隊真正在100%執行瀑布模式。

制造業的生產過程是高度重復，其過程明確定義了每一個生產步驟。而軟件開發中的不確定性，導致了過程重復度是有限的。任何兩個項目都不會完全一樣，不可能走過同樣的開發步驟。這個差異是“明確定義的過程”不適用于復雜軟件項目管理的重要原因。

1.2.2 瀑布開發模式的不合理之處

從項目立項開始到產品發布，什么時候我們對所開發產品了解得最少？答案很清楚：項目的起點是我們對產品需求、所需技術、團隊人員能力等關鍵信息了解最少的時候。瀑布模式要求我們在這個時間制訂出并承諾項目目標和計劃，包括實現產品范圍、功能、性能、進度和成本。

那么在信息最少時做計劃的最可能的后果是什么？一個字：變。需求會變，人員會變，技術方案會變。可令人沮喪的是，瀑布模式同時會懲罰變更，因為變更的代價往往是團隊不能承受的。

在瀑布模式下需求變更一定是壞事嗎？請你稍微考慮一下再回答這個問題。比較恰當的答案是：視情況而定。那么視什么情況呢？答案是變更的時機。前期變不是壞事，因為變更成本不高，很可能就是改一下需求文檔并和相關人員澄清而已。需求變更時機越靠后，變更影響范圍越大，變更成本就越高。在驗收時客戶提出大的需求變更的話，對項目組來說更是災難性的。接力模式也大大增加了技術變更及人員變更的成本。

看一下軟件項目管理中著名的七大惡：

不穩定的需求；

不靠譜的計劃；

不切實際的項目進度及預算；

項目失控；

項目投入不當；

永遠的借口——“我們特殊”；

缺乏對質量的真正關注。

如果我們認真做一下根源分析，瀑布開發模式及在對所開發產品了解最少時做出對產品功能、性能、進度、成本的承諾并懲罰變更，是一個重要的原因。