引子：我們?yōu)槭裁葱枰_發(fā)？

我們都知道，人對于世界的認(rèn)識是一項主觀活動，它受到各種因素的影響，使得我們不能夠一下子對所要認(rèn)知的事物有一個清晰的了解。具體到軟件開發(fā)中來，我們會發(fā)現(xiàn)，你很難在開發(fā)之前弄清楚客戶所有的需求。一方面，客戶對自己想要什么可能并沒有一個明確的想法，這就好比在買衣服的時候，我們在專賣店里看到一個衣服，會覺得自己穿起來很帥，但是你仍然需要把它真實的穿在身上才能看到實際效果，而在你看到這件衣服之前，你能夠僅僅憑著想象在腦海里刻畫出這件衣服的樣子么？

其次，軟件工業(yè)中我們講究的是投入和產(chǎn)出比，軟件業(yè)的成本主要是人力資源的成本。這也是軟件項目對時間特別敏感的原因。時間比計劃延長一個月，對于一個數(shù)十人的團(tuán)隊來說就意味著幾十萬的成本增加。但是又有誰能夠保證自己所做的軟件是完美無缺的呢？于是很多時候我們必須對已經(jīng)開發(fā)的部分進(jìn)行修正，而修正就需要時間。 傳統(tǒng)的開發(fā)方式下，很多軟件項目都是在匆忙交付后發(fā)現(xiàn)用戶不滿意，于是繼續(xù)修正，再次引發(fā)用戶的不滿意，再次修正，在這樣反復(fù)地拖延中，客戶和軟件開發(fā)商都筋疲力盡。

我們需要迭代開發(fā)，是因為我們深知對事物的認(rèn)知就是一個探索的過程，軟件開發(fā)也是一樣。在溫博格《探索需求---設(shè)計前的質(zhì)量》一書中提到：

美國第34任總統(tǒng)艾森豪威爾上將曾經(jīng)說過，"計劃本身什么都不是，而編制計劃的過程就是一切"。我們認(rèn)同這樣的說法，并把它推廣到需求過程：
　　　　　　產(chǎn)品什么都不是，而開發(fā)的過程就是一切。
或用另一種方式表達(dá)：
　　　　　　發(fā)現(xiàn)什么都不是，而發(fā)現(xiàn)過程（探索過程）就是一切。

軟件項目本身的意義就在于和用戶一起探索他們真正需要的東西并且?guī)椭麄儗崿F(xiàn)。而這種探索，如同在第一段中我們闡述的那樣，需要不斷的反復(fù)，如果我們沒有做好迭代和反復(fù)的準(zhǔn)備，而是希望一次性的把所有工作都做完并且還做得非常好，結(jié)果可能恰恰相反。

我們需要迭代開發(fā)，是因為我們追求軟件質(zhì)量的最大化。沒有人可以制造出完美無缺的東西，但是我們可以通過不斷的檢查和反饋，使得那些不適合的東西在早期被暴露出來，迭代給予了我們這樣一種檢查合反饋的機制，讓我們不必在事情結(jié)束的時候才驚奇的發(fā)現(xiàn)我們所一直努力在做的東西其實是一堆廢物。

實踐：正確實施迭代開發(fā)

事實上在業(yè)界，迭代開發(fā)的觀念早已經(jīng)深入人心，然而有多少團(tuán)隊在正確地實施著迭代方法呢？有多少團(tuán)隊通過迭代得到了他們想要的東西呢？很多人簡單的把迭代理解為開發(fā)的分階段進(jìn)行。我們常常看到有項目經(jīng)理們這樣說：我們打算通過4次迭代完成軟件的開發(fā)，第一次迭代，完成需求分析和軟件設(shè)計，第二次迭代，完成多少多少模塊的開發(fā)，第三次，完成其他多少模塊的開發(fā)，第四次，配置，部署，上線，測試，修正軟件bug。雖然我們言必稱“迭代”，但是這樣的迭代和過去傳統(tǒng)的瀑布型開發(fā)有多少區(qū)別？我們又能夠從這樣的偽迭代中得到什么好處呢？

在本文以下部分將對迭代開發(fā)實踐中幾個關(guān)鍵方面進(jìn)行闡述，這幾個方面我們概括為以下關(guān)鍵詞：變化，周期，目標(biāo)，反饋，合作。

變化

迭代思想帶給我們最重要的一個啟示，就是要適應(yīng)變化，要積極、主動地?fù)肀ё兓皇蔷芙^變化。

在過去的開發(fā)中，我們常常會拒絕變化，以需求分析工作為例，有些項目組在需求分析完成后會要求用戶簽字，等到交付時，如果客戶有什么意見，他們就會拿出那份客戶已經(jīng)簽字畫押的文件來理直氣壯地說：這是你們簽字過的東西，我們做的難道不是和這里所說的一樣么？

是的，開發(fā)出來的可能是和需求定義文件的內(nèi)容一樣的，但問題是：這份需求定義文件上描述的內(nèi)容是不是真正能夠幫客戶實現(xiàn)自己的價值呢？難道我們進(jìn)行軟件開發(fā)的目的就是讓客戶在一份他們根本不清楚有什么意義的文件上簽字，然后用這個來反駁用戶的真正需求么？我們在軟件立項之前總是會告訴用戶，這個即將開發(fā)的軟件會幫助他們?nèi)绾稳绾巍Ｎ覀冇惺裁蠢碛蔀槲覀冏霾坏竭@一點而理直氣壯地責(zé)備客戶呢？客戶親筆簽名的需求文檔難道不是我們整理出來并且講解給他們聽的么？

如果一個軟件項目的目標(biāo)是幫助客戶實現(xiàn)某一方面的增值，但是這種增值的目的并沒有達(dá)到，我們就可以認(rèn)為這個軟件項目是失敗的。即使軟件廠商通過這個項目達(dá)到了盈利的目的，滿腹牢騷的客戶也會把自己的意見傳播出去。而如果軟件廠商認(rèn)為這種事情是天經(jīng)地義的話，那么它在以后的軟件項目中也很難幫助自己的客戶實現(xiàn)他們想要的價值。

我們必須讓自己具有適應(yīng)變化的能力。因為這種變化是客戶需要的，因為這種變化能夠讓軟件更能體現(xiàn)出自己的價值。我并不是說應(yīng)該無條件地接受這種變化，但是我們可以在事前就這些問題和客戶進(jìn)行充分的討論和溝通，讓他們明白，世界總是變化的，需求本身可能會變化，而這種變化需要人力和物力的支持。讓客戶也能夠適應(yīng)自身的變化，這是非常重要的。

軟件開發(fā)中的每個人都應(yīng)該對變化有著充分的準(zhǔn)備。從事軟件業(yè)的人大都充滿了自信，系統(tǒng)分析師會認(rèn)為自己可以把所有的需求搞清楚，設(shè)計和開發(fā)人員會覺得他們做出來的東西完美地實現(xiàn)了需求。所以，如果我們對一個開發(fā)人員說：某某，你過去做的這個模塊不能用了，我們現(xiàn)在需要重新做起，通常我們會得到積極或者消極地抵制。

應(yīng)該讓人們認(rèn)識到：變化并不是對過去工作的否定，而是著眼于未來，使工作更加完善的必要手段。無論是需求，設(shè)計還是程序代碼，你不可能一次性就把它們做到完美，而只能通過不斷的修正，讓它趨近于完美。這個過程就是所謂的“重構(gòu)”。

有些團(tuán)隊為了保持開發(fā)的穩(wěn)定性，會 “凍結(jié)需求”。所謂的凍結(jié)，也就是說在一段時間內(nèi)要客戶方代表承諾不對已經(jīng)開發(fā)中的需求進(jìn)行變動。如果你打算做這件事情，首先必須意識到，需求本身就是需求，它是不會因為一個承諾就真正地“凍結(jié)”了。如果目前的需求定義并不能反映用戶真正的愿景，在凍結(jié)的周期過去以后我們?nèi)匀恍枰獙σ呀?jīng)做完的工作進(jìn)行修改。當(dāng)然，如果需求變化太頻繁，在某些時候有必要對需求進(jìn)行凍結(jié)以便讓開發(fā)更加平穩(wěn)，同時也給軟件開發(fā)者和客戶一個反思的時間。但如果是需求分析工作方法有誤，那就有必要作一些檢討了。

要適應(yīng)變化，我們需要讓客戶和開發(fā)團(tuán)隊有心理上的準(zhǔn)備，從而能夠以認(rèn)真的態(tài)度來對待它。還需要有正確的方法來應(yīng)對變化，比如對變化的成本估算，效果的跟蹤，如何快速有效的對各種變化進(jìn)行反映等，這是我們必須注意的問題。

周期

很多人簡單的把迭代理解為開發(fā)的分階段進(jìn)行。有些項目經(jīng)理會這樣說：我們打算通過4次迭代完成軟件的開發(fā)，第一次迭代，完成需求分析和軟件設(shè)計，第二次迭代，完成多少多少模塊的開發(fā)，第三次，完成其他多少模塊的開發(fā)，第四次，配置，部署，上線，測試，修正軟件bug。在這里，雖然他們言必稱“迭代”，但是這樣的迭代和過去傳統(tǒng)的瀑布型開發(fā)有多少區(qū)別？

迭代開發(fā)是要分周期分階段地進(jìn)行，但是不能認(rèn)為簡單地把開發(fā)周期劃分為幾個不同的階段就是迭代。

很多人對于迭代周期有一些誤解，比如：

n         認(rèn)為迭代只適用于開發(fā)階段，而需求分析和設(shè)計工作則不在此范圍內(nèi)。

n         認(rèn)為迭代周期可以拉得很長，比如兩個月，三個月，甚至一個季度，半年。

n         將需求分析，設(shè)計，開發(fā)，測試，部署，用戶反饋，修改當(dāng)作完整的迭代周期，并要求在前一階段工作完全（或者大部分）完成以后再進(jìn)行下一步工作（迭代）。

在一個迭代周期內(nèi)，我們可以做什么事情呢？可以說：所有的事情。如果你認(rèn)為迭代需要在需求分析完成之后才能開始，或者系統(tǒng)集成必須在所有迭代完成之后才可以進(jìn)行，你會獲得一個真正的瀑布流程開發(fā)。

一個迭代周期意味著對一些特定功能（用例）的探索。“探索”一詞可能隨情況不同而有不同的含義。對于抽象級別較高，模糊程度比較高的用例，我們需要通過和用戶的討論將它逐漸分解為更加清楚和清晰的用例。對于目前我們認(rèn)為已經(jīng)得到了詳細(xì)定義的需求，需要選取合適的部分進(jìn)行設(shè)計和實現(xiàn)，通過這些部分的實現(xiàn)，對需求定義和技術(shù)可行性進(jìn)行反饋。對那些在上次迭代中已經(jīng)開發(fā)完的模塊，應(yīng)該盡可能快速地讓用戶提出他們的意見，以便了解是否真正解決了用戶面臨的問題，以及還有沒有可以改進(jìn)的方面，再根據(jù)這些意見安排下一階段的工作。

我們是否可以在開發(fā)進(jìn)行之前把需求或者設(shè)計全部弄清楚呢？我認(rèn)為很難。因為通常來講，用戶對于自己的需求只有一個模糊的概念。讓我們假設(shè)一個飲食業(yè)的例子，有一天餐廳經(jīng)理把你叫入辦公室說：馬上設(shè)計一個新的菜譜，這個菜譜是為某某特定人群定制的，你要讓這些人感覺色香味俱全。不過在你把配料和烹調(diào)方法都設(shè)計出來之前，我們不打算讓大廚來具體做這道菜，我們不允許失敗，所以你的設(shè)計一定要一次成功，你可以用調(diào)查問卷，用戶面談等方法獲取最終用戶的需求，但是記住：你不能去做這道菜。

這樣的事情你可能會覺得很滑稽，但是在軟件業(yè)，類似的事情人們卻認(rèn)為是天經(jīng)地義的。

迭代允許我們將開發(fā)本身也作為需求探索的一部分，通過用戶對已經(jīng)實現(xiàn)功能的反饋我們和用戶都會逐漸明白什么樣的軟件是我們最終想要開發(fā)的。所以，不要等到所有（或者大部分）的分析完了才開始開發(fā)，而是盡早對已經(jīng)捕獲到的需求進(jìn)行細(xì)化，盡早開發(fā)，以獲得反饋。

在安排迭代計劃時，應(yīng)該指明，這次迭代的目標(biāo)是什么，在結(jié)束時應(yīng)達(dá)到的里程碑是什么。如果有任務(wù)提前達(dá)到了這個里程碑，我們可以提前結(jié)束迭代，或者順便在剩下的時間內(nèi)安排其他的任務(wù)，但是要注意這種安排的合理性，不要因為這個而使得迭代周期被延長。

在一次迭代到達(dá)所設(shè)定的結(jié)束日期時，就必須審視各項任務(wù)是否達(dá)到了里程碑的要求，如果有任務(wù)沒有達(dá)到，原因是什么，我們是否需要對需求和技術(shù)方案做出調(diào)整。對于沒有達(dá)到里程碑要求的任務(wù)，我們可以采取的辦法有兩種：

n         將剩余的工作列入下一次迭代計劃中去，

n         將本次迭代的結(jié)束時間向后延遲，等待任務(wù)的完成

前一種辦法適合于有很大工作量沒有完成的情況，這可能也同時說明計劃的制定有問題，在制定下次迭代計劃時應(yīng)該考慮對任務(wù)完成時間進(jìn)行調(diào)整。后一種辦法適合剩余工作量不是很大的情況。

通常來說，一次迭代完成以后應(yīng)該有一個產(chǎn)品的新版本可用。這也就意味著：將集成和發(fā)布分散到每次迭代中去。借助于一些自動化工具（比如ant），我們甚至可以做到每日構(gòu)建。

一個迭代周期應(yīng)該有多長呢？這并沒有一個統(tǒng)一的說法，而是應(yīng)該視目標(biāo)和可用的資源而定。但是，迭代周期不宜過長，也不宜過短。迭代周期過長的話，會延緩反饋的時間，可能將許多問題隱藏或是堆積了起來。迭代周期過短，會讓人身心疲勞，事情難有大的成效。一般來說，迭代周期應(yīng)該在2-6周之間。如果安排的迭代周期超過了兩個月，你可能就必須審視一下迭代計劃的合理性了。

不要認(rèn)為下一次迭代應(yīng)該和上次迭代的時間差不多，刻板地把所有迭代規(guī)定一個統(tǒng)一的時間是一個很壞的做法。但是你可以把以前迭代周期中的工作效率作為估算下次迭代時間的一個依據(jù)。

目標(biāo)

一次迭代必須有明確的目標(biāo)：我們希望通過這次迭代達(dá)到什么目的。在制定目標(biāo)時，應(yīng)該同時考慮另外一個問題：如何檢查該目標(biāo)是否已經(jīng)達(dá)成。這就是所謂的“里程碑”。

迭代計劃必須有明確而可行的目標(biāo)。明確的意思是它應(yīng)該是可度量的，不能太模糊，因為你很難檢查一個模糊的目標(biāo)是否達(dá)成。比如，我們可以說，這次迭代的目標(biāo)是對xxx方面的需求作進(jìn)一步細(xì)化和評審，完成xxx模塊的開發(fā)以加入到軟件的下一版本中去。這樣的目標(biāo)是明確而且可行的。反過來，如果我們這樣說：我們要通過和用戶的討論明確絕大部分愿景，同時要有一個初步的開發(fā)。“絕大部分”和“初步”這樣的詞讓人感到困惑：多少是絕大部分呢，在總量尚未明確的前提下，怎么能夠知道完成的確是“絕大部分”而不是“一小部分”？“初步的開發(fā)”似乎告訴我們這次開發(fā)量比較小，但是具體開發(fā)哪個部分，或者開發(fā)到什么程度，并沒有指出一個明確的概念。

由此產(chǎn)生了一個困惑，軟件項目是一個不斷探索的過程，我們怎么能夠明確地對未來的事情作安排呢？譬如在項目初始調(diào)查用戶愿景時，為了實現(xiàn)“明確”的目標(biāo)，是否這樣定義任務(wù)：完成20%的用戶愿景調(diào)查？

很顯然，用戶愿景總量到底有多少我們并不知道，所以在這次迭代完成以后如果我們問：是否真的完成了20%而不是15%？很難得到答案。

為了避免出現(xiàn)這種情況，你必須換個角度來看問題，比如我們可以說：對xxx部門和yyy部門的用戶做愿景調(diào)查。在迭代完成后，可以檢查是否這兩個部門所有用戶的訪談，調(diào)查都已經(jīng)完成，是否這些部門每個人都認(rèn)為自己表達(dá)了全部的意思。

所以，如果你發(fā)現(xiàn)很難對制定的目標(biāo)進(jìn)行度量，那么換一個角度來看事情吧，你可能就會找到一個合適的表達(dá)方式。如果你從所有的角度都看不到事情是可以度量的，那么這可能意味著這件事情可能還沒有到應(yīng)該去實施的地步，這時你應(yīng)該把它從迭代計劃中去掉。對于這種情況，有人可能會說：那我們這次迭代可做的事情就很少了，如果真是這樣，那就進(jìn)行一次小的迭代吧，可能把這次迭代的工作做完了以后就會有更多的工作可以安排了。

有些項目經(jīng)理在日程表上，很詳細(xì)地寫著：第一次迭代，某月某日到某月某日，第二次迭代：某月某日到某月某日，第三次迭代。。。這樣的做法是不恰當(dāng)?shù)摹Ｒ驗樗僭O(shè)了后面幾次迭代的任務(wù)量，但是實際上，在前面的工作完成之前，你很難對以后的工作得到一個明確地概念。而且在這樣的計劃上，可能并沒有用于測量迭代成果的里程碑，這樣的迭代最后很可能會演變成為瀑布式的開發(fā)。所以，在一次迭代完成之前，不要對急著去計劃下次迭代，特別是不要試圖精確定義下次迭代的時間，因為你連下次迭代要做什么都還不清楚。

為什么目標(biāo)的可度量性這么重要呢？在團(tuán)隊開發(fā)中，很多信息因為人與人的交流不暢而無法得到正確地反饋，這讓我們沒有辦法實時地掌握項目的進(jìn)展情況，退而求其次，我們必須階段性地了解這些信息。如果目標(biāo)難以度量，迭代結(jié)束后我們很難明確到底有哪些工作沒有完成，也就無法看到事情的問題所在。

有些團(tuán)隊中會要求每個成員每天對自己的工作進(jìn)度以百分比的形式做匯報，他們以為通過這樣的方式可以確實的掌握事情的進(jìn)展，但實際上并不行，因為軟件開發(fā)中存在很多不確定因素，有時候我們認(rèn)為事情已經(jīng)完成了一大半，但是可能因為技術(shù)或者其他的原因發(fā)現(xiàn)這一大半工作方向是錯的，這時候就要推倒重來，而且人們在匯報工作量的時候總是會有一些感情的因素在里面，這就使那些看似精確的百分比打了個折扣。

所以，我們需要更加實際和細(xì)致地劃分工作，對目標(biāo)的完成情況進(jìn)行度量。這也是迭代周期不能太長的一個原因：如果你把大量有前后關(guān)聯(lián)的工作劃分入一個迭代周期，在設(shè)定的結(jié)束到來時，突然發(fā)現(xiàn)只完成了一小部分，這時候雖然亡羊補牢仍然可以，但是中間浪費了大量的人力和物力。

反饋

一個男人在大街上走著，他并沒有發(fā)現(xiàn)褲子上的拉鏈已經(jīng)松開了，雖然看到這個情況的人有很多，但他們有各種各樣的擔(dān)心，比如不想多管閑事，怕讓那個男人難堪，或者干脆就是想看笑話。結(jié)果就是這個人繼續(xù)穿著一條敞開拉鏈的褲子在大街上行走。

這件事情至少帶給我們兩個啟示：1，得到反饋是重要的；2，要想得到正確的，有價值的反饋，你需要其他人的配合。

對于用戶需求來說，沒有用戶及時地反饋，我們就可能把那些不符合需求的開發(fā)繼續(xù)下去，由于軟件中各種功能和模塊的依賴性，這種不符合最后可能被放大到數(shù)倍。越遲得到反饋，問題可能就越大。

軟件開發(fā)中一個很重要的概念是“可行性”和“合理性”，無論我們做需求，設(shè)計還是開發(fā)，集成，測試，都會遇到這兩個問題。有些事情的可行性和合理性是我們可以通過事前的分析進(jìn)行判斷的，但是有些問題就必須有一定的實踐作為基礎(chǔ)。這也是一個反饋的問題。譬如說在某項目中技術(shù)架構(gòu)師決定采取一個技術(shù)架構(gòu)，但是經(jīng)過一些階段的開發(fā)發(fā)現(xiàn)它有一些技術(shù)上問題不能實現(xiàn)用戶的關(guān)鍵需求，這時候就必須放棄它。

“反饋”意味著兩個意思，對一件事情的調(diào)查和根據(jù)調(diào)查做出決策。

在意識到反饋的重要性之后，你會要求所有的人都對迭代的成果做出反饋。可能存在的問題是，是不是所有的人都意識到了反饋的重要性并且認(rèn)真地去做了呢？如果客戶認(rèn)為他們只需要對迭代出來的產(chǎn)品“看看而已”，那么你就很難了解他們一些深層次的想法。再比如一次迭代中某些模塊開發(fā)的進(jìn)度比較慢，開發(fā)人員可能會抱怨技術(shù)方案不能滿足要求，而實際的原因可能是設(shè)計不合理或者根本就是有人沒有認(rèn)真工作。

中國國家隊前主教練米盧曾經(jīng)說過“態(tài)度決定一切”，反饋作為迭代開發(fā)中至關(guān)重要的一個方面，必須得到足夠的重視。

獲得反饋的方式和對于反饋信息的分析是另外一個重要的方面。一般來講，根據(jù)軟件開發(fā)角色的不同，我們非常關(guān)注的是兩類人的反饋：項目組之外的客戶和項目組之內(nèi)的各種實施人員。

軟件項目一般都會要求客戶方安排專門的業(yè)務(wù)人員進(jìn)行配合，在迭代開發(fā)中，這種配合不只是進(jìn)行需求的整理和發(fā)掘，還包括對已經(jīng)完成軟件版本的評測。在這個過程中應(yīng)該有需求分析師的配合。

在每次迭代完成之后，軟件項目組應(yīng)該有一些總結(jié)和分析活動。通過這些總結(jié)和分析，找到做得好和做得不好的方面。

在非迭代式的開發(fā)中，也有反饋的環(huán)節(jié)。比如通常在軟件交付階段會有一個試用期讓用戶提出意見。而軟件團(tuán)隊在各種開發(fā)中都會有一些總結(jié)活動。迭代式開發(fā)的獨特之處在于盡量早地引入反饋機制；使得反饋機制更加制度化；并且，更加快速和靈活地分析這些反饋，把得到的結(jié)論應(yīng)用到下一階段的開發(fā)中去。

對于一些機制引起的問題，比如組織結(jié)構(gòu)不合理，角色分配不明確之類。最好有一個明確的問題記錄表。在每次迭代完成以后將這些問題記錄下來，同時在下次迭代中努力改善它。如果相同的問題連續(xù)出現(xiàn)在幾次迭代中，可能就說明項目管理出了問題。

合作

軟件團(tuán)隊中的合作是人們一直都在提倡的。我們在這里提到“合作”的意思并不只包含團(tuán)隊內(nèi)部的協(xié)作，還包括和客戶的合作。

迭代開發(fā)需要快速反應(yīng)，這需要各種不通角色人員的配合。如果人們做事情總是拖拖拉拉，就會延緩軟件項目的進(jìn)度。而且每個人對自己在迭代中應(yīng)該做什么事情必須很清楚，這需要事前的準(zhǔn)備和角色的合理分配。

迭代需要用戶的配合，實際上最好能夠有客戶方真正的系統(tǒng)使用者參加到迭代過程中來，因為他們是最有發(fā)言權(quán)的。很多項目中會讓項目經(jīng)理或是系統(tǒng)分析師擔(dān)當(dāng)客戶代表的角色，這樣做有很多弊病。有時出于各種原因客戶確實不能到現(xiàn)場配合的，我們也可以通過其他的途徑獲得客戶反饋。比如一個階段迭代完成以后，可以把相關(guān)操作用截屏加文字說明的方式發(fā)給客戶，讓他們對產(chǎn)品有一個直觀的印象。

為了讓團(tuán)隊能夠有效快速地配合，應(yīng)該盡可能使用各種自動化工具。比如自動化測試管理工具，以及配置管理，集成以及發(fā)布之類的工具。通過對這些工具的有效應(yīng)用，使得各個成員能夠快速獲得信息。

迭代開發(fā)要擁抱變化，主動適應(yīng)變化。要讓每個參與者都認(rèn)識到這一點：不能夠固步自封，或者滿足于現(xiàn)有的成就，不去思考可改進(jìn)的地方。從管理者的角度上，必須重視每一個反饋信息。

迭代開發(fā)追求對任務(wù)的度量。很多組織會把這種度量和員工的績效考評聯(lián)系起來。這種做法可能是合適的，但是如果只是簡單衡量工作量或者工作完成速度和質(zhì)量，有可能會比較片面。畢竟軟件開發(fā)是一個環(huán)環(huán)相扣的過程，表面上來看這個環(huán)節(jié)處理不好，實際上可能是準(zhǔn)備工作做得不好，或者其他人的配合不好。

所以如果在迭代過程中出現(xiàn)了問題，一定要客觀地分析，特別是應(yīng)該挖掘?qū)е逻@些問題出現(xiàn)的深層次原因。譬如在一次迭代中測試人員發(fā)現(xiàn)了一些bug，但是兩次迭代過去了，這些bug仍然存在，這就說明對bug的處理不夠迅速（當(dāng)然如果因為某些原因這些事情被故意推遲了的情況不算）。這時就必須分析一下到底是什么原因造成了信息的不通暢。而不能簡單地批評相關(guān)責(zé)任人。

總結(jié)

本文對迭代開發(fā)的五個關(guān)鍵（變化，周期，目標(biāo)，反饋，合作）方面進(jìn)行了討論。作為一種方法論，迭代開發(fā)的好處在于它使軟件團(tuán)隊變得更加靈活。在實施迭代開發(fā)的過程中，應(yīng)注意不能流于形式化，切實做好每個環(huán)節(jié)的工作，這樣才能獲得滿意的結(jié)果。

Email:jayliu@mail.csdn.net

http://www.tkk7.com/jayliu