透視迭代開發(fā)2007-04-23 來自：java060515


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　將剩余的工作列入下一次迭代計劃中去，
　　將本次迭代的結(jié)束時間向后延遲，等待任務(wù)的完成
　　前一種辦法適合于有很大工作量沒有完成的情況，這可能也同時說明計劃的制定有問題，在制定下次迭代計劃時應(yīng)該考慮對任務(wù)完成時間進行調(diào)整。后一種辦法適合剩余工作量不是很大的情況。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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