第三節 “摸著石頭過河”——增量型和迭代型

增量型和迭代型都是典型的“摸著石頭過河”，相當于我們日常所說的“先練練手”。

但是這兩種類型也有區別。區別就在于提交的交付物不同?？梢蕴峤灰粋€版本的，叫迭代型，另外一個就叫增量型。迭代型要求每迭代一次要提交一個版本，通過這次迭代，可以經歷項目的幾乎所有過程——從需求一直到交付。雖然有的時候可能不是真的交付給用戶。

增量型則是要求先做一部分，根據這部分積累的經驗再做下一部分。不同部分之間可能在時間上有重疊，所以有的人又形象地稱之為“疊生魚片型”或者“噴泉型”等。

迭代型曾經流行過一段時間，這主要是雅各布森等軟件工程領域赫赫有名的三位大師搞的統一開發過程（RUP）的貢獻。作者一直認為RUP的產生是對軟件工程領域最大的毒害。這種模型首先對軟件研發過程用了類似于當年泰勒工廠流水線的那套思維進行了建模。用層次化的方法對軟件過程機械地進行切分，之后再把過程分成活動。而活動或者過程再分解成步驟，角色，過程中使用的方法、工具以及輸出的文檔。這一整套東西提出來之后發布了一套看上去十分完備的文檔系統，因為其幾乎匯集了所有軟件項目過程的方法流程和技術，如下圖。

這套方法的最大問題就是在其產生之后，大師們更多地從理論的完備性來闡述這套方法，陷入了理論的自我完善當中而脫離了實際情況。其對所有流程使用了相同的處理方法，雖然其一再強調可以裁剪，但是由于受其建模本身要求完備性的影響，使用起來十分不方便，會讓整個項目組套上沉重的枷鎖而失去了應用的靈活性。

這種方法可以說影響了2000—2010年近十年的軟件工程領域。由于三位大師的名頭，加上十分詳盡的文檔資料，使得很多年間的軟件工程類的文章以及培訓課程大量復制了里面的資料。同時也就意味著復制了里面的思想，給自己的項目帶來了重負。當年一家很有名的軟件公司，斥巨資號稱要打造中國軟件行業最大的航母，要做中國最大的軟件工廠，讓軟件研發從此變成藍領的工作。該公司照辦了這套方法，結果管理人員十分龐大，軟件項目搞得一塌糊涂，技術人員疲于應對各種文檔的撰寫。

事實上，這套方法本身也有其商業目的，那就是Rational公司想通過推廣這種方法，來推銷它的工具，包括建模、版本控制以及各種輔助開發工具。這家公司后來被IBM收購了，至今仍活躍在軟件工程領域，但是已經式微了。主要的創始人雅各布森離開了Rational公司，又在繼續著建模之路，提出了SEMAT模型，我們對其效果拭目以待。總體來看，真正使用RUP方法的公司并不多，甚至連收購了這家公司的IBM公司的開發小組也不使用其中的方法。而號稱使用了RUP的微軟公司實際上也是一直在使用自己公司的一套軟件工程方法而已。

好的一面是，迭代型生命周期模型的概念開始深入人心，讓項目管理者們有了新的思路應對各種項目困境。另外，建模及其優化已經成為了軟件工程領域一個主要的方向。

其實迭代型本身也十分符合心理學的要求，尤其是對于需要長時間才能完成的項目。迭代不僅是從技術和業務上不斷地促進項目組變得成熟，降低變更風險，同時也是參與項目人員的一個心理需求。

人為了和系統一致，必須要不斷地從系統中也就是周圍環境中獲得反饋才能保持正常的認知能力和健康心理。而迭代型中，每次提交的版本就是給參與人員的反饋。如果人在項目中長期得不到反饋，看不到一個成果，那項目組人員的注意力就會分散，工作動力就會嚴重下降。

前面講過了“感覺剝奪”實驗，這個實驗證明了人在社會生活中多么需要一個反饋來知道自己工作的效果。關于認知失調，會在后面的章節中更加詳細地論述。

知道了這個特點之后，就知道迭代型正好符合了人類本身的心理需求，那就是需要不斷地得到反饋。所以，有的時候為了增加團隊的動力，我們可能會故意降低版本的要求以便可以及時發布版本，鼓舞士氣。為此，有時我們就需要設計多個小版本進行發布，而不是大版本。

如今在“云計算”的影響下，軟件產品大多都具有自動檢查版本更新的功能。一個不斷有新的版本更新的軟件產品和一個半年都沒有什么新版本的軟件產品哪個更有活力，更值得信任呢？不用說，是前者。所以，如果仔細觀察你就會發現，許多軟件產品的更新實際上沒有什么改動，只是變換了一下界面，刺激一下你的注意力而已。