透視迭代開發

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

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

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

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

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

　　或用另一種方式表達：發現什么都不是，而發現過程（探索過程）就是一切。

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

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

　　實踐：正確實施迭代開發

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

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

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

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

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

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

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

原文轉自：http://www.anti-gravitydesign.com