史蒂夫·邁克康奈爾（Steve McConnell）在這裏提到了不少開發流程。第一個提到的開發流程。這個流程也有好處，不需要太多其他準備或相關知識，大家上來就寫代碼，也許就能寫出來，寫不出來就改，也許能改好。當面臨下面的任務時，也許這個方法是有用的。但是，要寫一個有實際用戶、解決實際需求的軟件，這個方法的缺點就太大了。

瀑布模型

當軟件行業還在年幼的時期，它從別的成熟行業（硬件設計，建築工程）借用了不少經驗和模型。在那些“硬”的行業中，產品大多遵循 [分析→設計→實現（制造）→銷售→維護] 這個流程。由於在“硬”行業中產品一旦大規模生產，要再返回去修改時就非常困難，甚至是不可能的。因此這個模型描述了單向的、不可逆的生產過程。

在設計大型系統時，要做相鄰步驟的回溯，解決上一階段未能解決的問題：又如，溫斯頓指出，要讓產品成功，最好把這個模型走兩遍，先有一個模擬版本（Simulation of FinalProduct），在此基礎上收集反饋，改進各個步驟，並交付一個最終的版本。

了解了老板驅動的流程

開發流程事實上是由行政領導主導，或者由公司的老板驅動，我們姑且把它命名為老板驅動的流程（Boss-Driven Process）

1. 存在的原理

當軟件訂單的獲得不是主要靠技術實力，而是靠個人關系，或者暗箱操作的時候，老板的能力決定了一個團隊是否能獲得訂單，既然軟件的具體功能並不重要（或者哪個團隊做水平都差不多），那麽老板說做什麽就做什麽

在大型企業內部，軟件功能往往由行政體系來決定

有些老板比一般技術人員更懂市場和競爭

軟件團隊尚未成熟，不懂得如何獨立地進行需求分析，不懂得如何對行政領導有技巧地說“不”，也不知道如何說服利益相關者（Stakeholder）同意並支持正確的項目方向

既然不能驅動團隊成員，那只能靠外力來驅動了

2. 存在的問題

領導對許多技術細節是外行

領導未必懂得軟件項目的管理，領導的權威影響了自由的交流和創造

領導最擅長的管理方式是行政命令，這未必能管好軟件團隊或任何需要創造力的團隊

領導的精力有限，領導很忙時，團隊怎麽辦？

構建之法第五章學習

團隊和流程