迭代是數值分析中通過從一個初始估計出發尋找一系列近似解來解決問題(一般是以方程或者方程組）的過程，為了實現這一過程所使用的方法統稱為迭代法。
作為程式設計師，我想大家都很熟悉RUP的概念或都在專案或產品中也實施過RUP。
我在現有負責的產品聚聚呀架構工作所能感受到的，迭代它無處不在。
無論是產品的概念還是在產品的設計，架構和開發。

  任何一次新功能釋出整個生命週期都需要迭代。
網際網路產品的需求相對於傳統軟體產品來說產品的功能生命週期很短，需要不斷的去創新，發掘，並且以最快的速度去釋出才有可能在網際網路這塊市場上去驗證產品成功還是失敗。而傳統軟體服務的物件是傳統企業，組織或者是行業標準類的公司。因為組織無論是它的組織結構還是業務規範，商業模式，這種變化來的時間會比網際網路產品慢，並不是說這些傳統軟體不需要迭代，而是迭代的層面的時間會有很大的差異，網際網路更多的表現在一個“快”字，從產品的概念到原型，設計，切割，開發現實，測試上線等整個過程都需要快速，有時這個週期只需要一週，特別是像網遊類的產品更是。

  在我負責的產品也是如此，運營部門收集到使用者的某些需求經過整理後，提交產品部門，產品部門需要經過快速的PK後產生的最終的產品新功能的需求交由設計部門產品圖，這個時間會很短一般不會超過一週。就這二個過程也算要一個小小的迭代，設計完稿後才會到頁面工程師手裡切出HTML出來，然後會給開發人員。
同樣，設計師與開發人員之間也會有迭代，在實現的難易度和產品的“價值取向”上會做調整，有時設計出來的東西很好，但從產品的全域性來看未必了，就如產品的效能和使用者的體驗有時感覺是一矛盾體。程式設計師實現功能後會與測試部門的同學進行迭代。

  在整個過程中好像沒有看到架構什麼事！其實不然，架構是需要從產品需求的提出就需要切入在整個的週期裡面，如果把架構劃入實現的階段那是很悲哀的事，架構師基本不知道為誰而做？也不知道做出來是什麼樣子，更不知道將來會是什麼樣子，更不要去談什麼擴充套件了。但事實上很多公司會這麼做。
架構師就像“全科醫生”什麼都需要懂，更重要的是每一次的“用藥”都需要從各個方面考慮然在不傷害根本的前提下再做出相對靠譜的選擇。
所以做為一個架構師的能力不是憋的，是需要磨歷。
架構師所需要的十項技能：
http://developer.51cto.com/developer/top10Architect/