2010年軟考系統(tǒng)分析師：敏捷開(kāi)發(fā)的迭代

　　在團(tuán)隊(duì)設(shè)計(jì)中，我們一直在強(qiáng)調(diào)，設(shè)計(jì)組最開(kāi)始得到的設(shè)計(jì)一定只是一個(gè)原始架構(gòu)，然后把這個(gè)原始架構(gòu)傳播到每一位開(kāi)發(fā)者的手中，從而在開(kāi)發(fā)團(tuán)隊(duì)中形成共同的愿景。(愿景(Vision)：源自于管理學(xué)，表示未來(lái)的愿望和景象。這里借用來(lái)表示軟件在開(kāi)發(fā)人員心中的樣子。在后面的文章中我們會(huì)有一個(gè)章節(jié)專(zhuān)門(mén)的討論架構(gòu)愿景。)

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

　　我們可以把早期的原始架構(gòu)當(dāng)作第一次迭代前的早期投入，也可以把它做為第一次迭代的重點(diǎn)，這些都是無(wú)所謂的。關(guān)鍵在于，原始架構(gòu)對(duì)于后續(xù)的架構(gòu)設(shè)計(jì)而言是非常重要的，我們討論過(guò)架構(gòu)是來(lái)源于需求的，但是原始架構(gòu)應(yīng)該來(lái)源于那些比較穩(wěn)定的需求。

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

　　從實(shí)踐的經(jīng)驗(yàn)中，我們發(fā)現(xiàn)，把原該在目前就該解決的問(wèn)題退后是造成這一問(wèn)題的主要原因之一。因此，請(qǐng)嚴(yán)格的對(duì)待每一次的迭代，確保計(jì)劃已經(jīng)完成、確保軟件的質(zhì)量、確保用戶(hù)的需求得到滿(mǎn)足，這樣才是正統(tǒng)的迭代之路。

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

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

　　基于我們對(duì)運(yùn)籌學(xué)的一點(diǎn)經(jīng)驗(yàn)，迭代設(shè)計(jì)之間肯定不是線(xiàn)性的關(guān)系。這樣說(shuō)的一個(gè)原因架構(gòu)設(shè)計(jì)和后續(xù)的工作間還是時(shí)間差的。因此，我們不會(huì)傻到把時(shí)間浪費(fèi)在等待其它工作上。一般而言，當(dāng)下一次迭代的需求開(kāi)始之后，詳細(xì)需求開(kāi)始之前，我們就已經(jīng)可以開(kāi)始下一次迭代的架構(gòu)設(shè)計(jì)了。

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