迭代

給你一個標準的定義：

在RUP中，迭代被定義為：迭代包括產生產品釋出（穩定、可執行的產品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。

這個定義太學究氣，半天看不明白。這樣解釋可能更容易理解：

我們開發一個產品，如果不太複雜，會採用瀑布模型，簡單的說就是先需求定義，然後構建框架，然後寫程式碼，然後測試，最後釋出一個產品。

這樣，幾個月過去了，直到最後一天釋出時，大家才能見到一個產品。

這樣的方式有明顯的缺點，假如我們對使用者的需求判斷的不是很準確時——這是很常見的問題，一點也不少見——你工作了幾個月甚至是幾年，當你把產品拿給客戶看時，客戶往往會大吃一驚，這就是我要的東西嗎？

迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第一個月就會拿出一個產品來，當然，這個產品會很不完善，會有很多功能還沒有新增進去，bug很多，還不穩定，但客戶看了以後，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以後，再花一個月，在上個月所作的需求分析、框架設計、程式碼、測試等等的基礎上，進一步改進，又拿出一個更完善的產品來，給客戶看，讓他們提意見。

就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血後，直到最後釋出之時才發現根本不是客戶要的東西。

這樣的方法很不錯，但他也有自己的缺陷，那就是週期長、成本很高。在應付大專案、高風險專案——就比如是太空梭的控制系統時，迭代的成本比專案失敗的風險成本低得多，用這種方式明顯有優勢。

如果你是給自己的單位開發一個小MIS，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花一個月重來，沒什麼了不起。