在團隊設計中，我們一直在強調，設計組最開始得到的設計一定只是一個原始架構，然后把這個原始架構傳播到每一位開發(fā)者的手中，從而在開發(fā)團隊中形成共同的愿景。(愿景(Vision)：源自于管理學，表示未來的愿望和景象。這里借用來表示軟件在開發(fā)人員心中的樣子。在后面的文章中我們會有一個章節(jié)專門的討論架構愿景。)

　　迭代(Iterate)設計，或者我們稱之為增量(Incremental)設計的思想和XP提倡的Evolutionary Design有異曲同工之妙。我們可以從XP、Crystal、RUP、ClearRoom等方法學中對比、體會迭代設計的精妙之處：每一次的迭代都是在上一次迭代的基礎上進行的，迭代將致力于重用、修改、增強目前的架構，以使架構越來越強壯。在軟件生命周期的最后，我們除了得到軟件，還得到了一個非常穩(wěn)定的架構。對于一個軟件組織來說，這個架構很有可能就是下一個軟件的投入或參考。

　　我們可以把早期的原始架構當作第一次迭代前的早期投入，也可以把它做為第一次迭代的重點，這些都是無所謂的。關鍵在于，原始架構對于后續(xù)的架構設計而言是非常重要的，我們討論過架構是來源于需求的，但是原始架構應該來源于那些比較穩(wěn)定的需求。

　　TIP：現實中迭代設計退化為"Code and Fix"的設計的情況屢見不鮮("Code and Fix"參見簡單設計)。從表面上看，兩者的做法并沒有太大的差別，都是針對原有的設計進行改進。但是，二者效果的差別是明顯的："Code and Fix"是混沌的，毫無方向感可言，每一次的改進只是給原先就已搖搖欲墜的積木上再加一塊積木而已。而迭代設計的每一次改進都朝著一個穩(wěn)定的目標在前進，他給開發(fā)人員帶來信心，而不是打擊。在過程上，我們說迭代設計是在控制之下的。

　　從實踐的經驗中，我們發(fā)現，把原該在目前就該解決的問題退后是造成這一問題的主要原因之一。因此，請嚴格的對待每一次的迭代，確保計劃已經完成、確保軟件的質量、確保用戶的需求得到滿足，這樣才是正統(tǒng)的迭代之路。

　　我們說，每一次的迭代其實是一個完整的小過程。也就是說，它同樣要經歷文章中討論的這些過程模式。只不過，這些模式的工作量都不大，你甚至可以在很短的時間內做完所有的事情。因此，我們好像又回到了文章的開頭，重新討論架構設計的過程。

　　單次迭代最令我們興奮的就是我們總是可以得到一個在當前迭代中相當穩(wěn)定的結果，而不像普通的架構設計那樣，我們深怕架構會出現問題，但又不得不依賴這個架構。從我們的心理上來分析，我們是在持續(xù)的建設架構中，我們不需要回避需求的變更，因為我們相信，在需求相對應的迭代中，我們會繼續(xù)對架構進行改進。大家不要認為這種心理的改變是無關緊要的，我起初并沒有意識到這個問題，但是我很快發(fā)現新的架構設計過程仍然籠罩在原先的懼怕改變的陰影之下的時候，迭代設計很容易就退化為"Code and Fix"的情形。開發(fā)人員難以接受新方法的主要原因還是在心理上。因此，我不得不花了很多的時間來和開發(fā)人員進行溝通，這就是我現實的經驗。

　　基于我們對運籌學的一點經驗，迭代設計之間肯定不是線性的關系。這樣說的一個原因架構設計和后續(xù)的工作間還是時間差的。因此，我們不會傻到把時間浪費在等待其它工作上。一般而言，當下一次迭代的需求開始之后，詳細需求開始之前，我們就已經可以開始下一次迭代的架構設計了。

　　各次迭代之間的時間距離要視項目的具體情況而定。比如，人員比較緊張的項目中，主要的架構設計人員可能也要擔任編碼人員的角色，下一次迭代的架構設計就可能要等到編碼工作的高峰期過了之后�？墒�，多次的交錯迭代就可能產生版本的問題。比如，本次的迭代的編碼中發(fā)現了架構的一個問題，反饋給架構設計組，但是架構設計組已經根據偽修改的本次迭代的架構開始了下一次迭代的架構設計，這時候就會出現不同的設計之間的沖突問題。這種情況當然可以通過加強對設計模型的管理和引入版本控制機制來解決，但肯定會隨之帶來管理成本上升的問題，而這是不符合敏捷的思想的。這時候，團隊設計就體現了他的威力了，這也是我們在團隊設計中沒有提到的一個原因。團隊設計通過完全的溝通，可以解決架構設計中存在沖突的問題。