引子：我們為什么需要迭代開發？

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

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

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

美國第34任總統艾森豪威爾上將曾經說過，"計劃本身什么都不是，而編制計劃的過程就是一切"。我們認同這樣的說法，并把它推廣到需求過程：
　　　　　　產品什么都不是，而開發的過程就是一切。
或用另一種方式表達：
　　　　　　發現什么都不是，而發現過程（探索過程）就是一切。

軟件項目本身的意義就在于和用戶一起探索他們真正需要的東西并且幫助他們實現。而這種探索，如同在第一段中我們闡述的那樣，需要不斷的反復，如果我們沒有做好迭代和反復的準備，而是希望一次性的把所有工作都做完并且還做得非常好，結果可能恰恰相反。

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

實踐：正確實施迭代開發

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

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

變化

迭代思想帶給我們最重要的一個啟示，就是要適應變化，要積極、主動地擁抱變化而不是拒絕變化。

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

是的，開發出來的可能是和需求定義文件的內容一樣的，但問題是：這份需求定義文件上描述的內容是不是真正能夠幫客戶實現自己的價值呢？難道我們進行軟件開發的目的就是讓客戶在一份他們根本不清楚有什么意義的文件上簽字，然后用這個來反駁用戶的真正需求么？我們在軟件立項之前總是會告訴用戶，這個即將開發的軟件會幫助他們如何如何。我們有什么理由為我們做不到這一點而理直氣壯地責備客戶呢？客戶親筆簽名的需求文檔難道不是我們整理出來并且講解給他們聽的么？

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

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

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

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

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

要適應變化，我們需要讓客戶和開發團隊有心理上的準備，從而能夠以認真的態度來對待它。還需要有正確的方法來應對變化，比如對變化的成本估算，效果的跟蹤，如何快速有效的對各種變化進行反映等，這是我們必須注意的問題。

周期

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

迭代開發是要分周期分階段地進行，但是不能認為簡單地把開發周期劃分為幾個不同的階段就是迭代。

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

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

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

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

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

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

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

這樣的事情你可能會覺得很滑稽，但是在軟件業，類似的事情人們卻認為是天經地義的。

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

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

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

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

n         將本次迭代的結束時間向后延遲，等待任務的完成

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

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

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

不要認為下一次迭代應該和上次迭代的時間差不多，刻板地把所有迭代規定一個統一的時間是一個很壞的做法。但是你可以把以前迭代周期中的工作效率作為估算下次迭代時間的一個依據。

目標

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

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

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

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

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

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

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

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

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

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

反饋

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

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

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

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

“反饋”意味著兩個意思，對一件事情的調查和根據調查做出決策。

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

中國國家隊前主教練米盧曾經說過“態度決定一切”，反饋作為迭代開發中至關重要的一個方面，必須得到足夠的重視。

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

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

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

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

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

合作

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

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

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

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

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

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

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

總結

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

Email:jayliu@mail.csdn.net

http://www.tkk7.com/jayliu