敏捷方法鼓勵開發人員不要拘泥於傳統的開發流程， 要相信筒單重構和快速重新設計架構的優勢。這對多數定制軟體來說是可行的，但對產品軟體系統（比如針對成千上萬使用者的大眾網路服務）而言，這個想法就太天真了。 所以，產品軟體團隊使用敏捷方法時遇到問題不足為奇，主要是因為他們照搬了定製軟體的敏捷模式。至今多數介紹敏捷方法的圖書、文章、培訓課程依然不涉及產品經理和使用者體驗設計師（互動設計師和視覺設計師）的作用，因為它們針對的讀者群還是定製軟體團隊。 要想成功轉型成為敏捷開發團隊，選一位合格的敏捷教練相當重要，他必須理解產品軟體與定製軟體的差別， 瞭解產品軟體的特殊需求，而這正是多數人不明白的。 駭驅彌必翟第27章合理運用瀑布式開發方法 Succeeding with the Waterfall Process 揚長避短本章討論目前大多數產品團隊仍然在使用的開發方法— 瀑布式開發方法。 瀑布式開發方法已經有三十多年曆史了。雖然開發人員和產品經理們早已怨聲載道，但它依舊是最常用的軟體開發方法。 大多數開發團隊仍然在使用瀑布式開發方法，只是人們不好意思承認，所以紛紛換了別的稱呼，比如，持續改進方法、 里程碑式開發方法等等。 本章先揭示瀑布式開發方法的主要缺點，然後著重探討產品經理如何在瀑布式開發方法中揚長避短。
第27 章合理運用瀑布式開發方法| 161 瀑布式開發方法的基本原則傳統瀑布式開發方法的理念很簡單，主要有兩點。 1. 採用階段式開發軟體開發過程被事先分成固定的幾個階段：撰寫書面的需求說明文件、設計高層軟體架構、 設計低層細節、編寫程式碼、測試、部署。 2. 採用階段式評審每個階段結束後，對該階段提交的成果進行評審，評審透過後才能進入下一階段。 瀑布式開發方法有正式和非正式兩種形式。正式的形式可以參考美國國防部軟體開發標準2167A 及後來的標準498，其中詳細地描述了該方法所有階段的流程，以及需要提交的文件。 更常見的還是非正式的形式：首先由市場人員收集市場需求， 提交給開發人員；接著由開發人員制訂開發計劃，設計軟體架構，進一步完善設計細節；然後進入開發測試階段，完工後邀請使用者測試產品，最後部署。 在討論瀑布式開發方法的侷限性之前，有必要先回顧一下它經久不衰的原因。 首先，瀑布式開發方法的流程具有可預測性，因而深受管
162 | 啟示錄：打造使用者喜愛的產品理層歡迎。只要能準確理解需求和技術，而且需求不再變更， 開發團隊就能為大規模的、複雜的專案制訂精確的開發計劃。 這種情況雖然很少見，但並非不可能做到。相反，迭代方法的迭代次數不可預估，難以讓管理層安心。 其次，採用瀑布式開發方法，在每個階段結束時都會提交書面材料。有了翔實的文件和設計圖表，管理層、客戶（委託方）、開發人員覺得所有工作都是經過深思熟慮的，才能放心。 這些材料可以從一定程度上增強人們對專案的信心。問題在於把書面材料當成定心丸多少有些靠不住，畢竟文件不能像軟體一樣執行、驗證。 瀑布式開發方法讓產品經理頭痛的地方從產品經理的角度來看，瀑布式開發方法存在不少問題。 產品驗證嚴重滯後這是最嚴重的問題。產品經理必須等到軟體開發的尾聲， 才能看到可以執行的軟體。也就是說，在投入大量人力和資金之前，軟體的可用性無法得到驗證。 進入開發階段之前，產品經理應該製作產品原型，請目標使用者測試，確保最終提交給開發部門的產品設計是透過了使用者