前面的章節(jié)談了很多業(yè)務建模的知識，可以看到整個過程基本上是串在一起的，嚴格按照軟件生命周期模型來說是屬于瀑布模型。這里就有問題了，我們在討論瀑布模型的時候已經(jīng)用了很多的篇幅來鞭笞它了，這里我們又用回了這個模型，這是不是有點…。這樣做的一個很大的原因是業(yè)務建模有它的特性。在一些小的項目中，業(yè)務建模在軟件生命周期中所占比例一般不大，多半是為了了解業(yè)務環(huán)境的，其中BPA的成分會多一些，BPR的部分通常很少。所以其中如果發(fā)生了一些失誤的地方，可以在需求階段彌補。如果是那些諸如ERP的項目，那么業(yè)務建模和BPR會有很重要的位置，這個時候，一般要根據(jù)具體的情況來制定戰(zhàn)略，很難說是采用何種周期模型。而且業(yè)務建模一般需要的人手不多，也會安排在項目的早期。所以只要有審查，業(yè)務建模采用何種生命周期模型并不是特別重要的。不過這是對于那些特定的項目而言的，對于市場化的產(chǎn)品來說，應該有另外的過程，但這并不在我們的討論范圍內(nèi)，以后有機會的話再和大家討論。
再說需求，需求的生命周期絕對不能按照瀑布模型的來。對程序員來說，最痛恨的一件事情就是需求改變。所以呢，大家想出一種需求凝固的辦法，在分析完了需求后，就把它固定起來，寫成文檔，讓客戶簽字。以后再有需求的增加或改變的話，就拿出這張紙說，"看吧，當時的要求可沒有這一項啊。"這種做法的惡果是顯而易見的。不過，有些企業(yè)則會反駁說，"沒有啊，我向來都是視客戶為上帝，這種事情我是不會做的，我會讓程序員增加這個功能。"可惜的是，這種縱容顧客，傷害程序員的做法更糟。還記得我在聽管理學課程的時候的一句話："員工是最重要的，客戶次之。"這是很有道理的，如果你的員工不滿意，那么員工直接服務的客戶又怎會滿意？所以無論是哪一種做法，都只能暫時解決問題，對未來造成的危害卻更大。
需求改變的危害很大，可是不變的需求從來就沒有存在過。如果說，過去的社會中，企業(yè)的需求能夠在一段相對長的時間內(nèi)保持不變。那么，在現(xiàn)在這個全球化趨勢愈來愈明顯的社會中，一個不會變化的企業(yè)就只有死路一條。
曾經(jīng)是大陸霸主的恐龍為什么會滅亡，而當時弱小的哺乳動物卻能夠存活下來，最大的原因就是面對著瞬息萬變的自然環(huán)境，恐龍沒有辦法改變自身來適應環(huán)境，而哺乳動物則可以?，F(xiàn)在的社會也是一樣的。如果你的軟件企業(yè)所服務的客戶一家家歇菜，那你的下場也就可想而知了。所以，很明顯的，需求和變化幾乎就是同義詞。
一方面是要求不變，一方面是要求改變。在這種矛盾的環(huán)境下，如何才能達到一個平衡點呢。
在已往的軟件開發(fā)過程中，多半都要求對未來作出預測。例如，需求要有前瞻性，設計要有可延展性?？墒沁@種做法往往難以實現(xiàn)?，F(xiàn)實中的變化何止千萬種，你都能做到算無遺策嗎？如果你說你在做計劃書的時候，可以估算到9月11號可能會發(fā)生災難，那我就沒話可說了。
一個中型以上的項目往往都需要數(shù)十人的團隊工作半年以上才可能完成。這時候的計劃還要加進人這個最不確定的因素。這樣，正確的估計簡直就是比登天還難。有很多自稱考慮周詳?shù)挠媱潟谶M度安排時連假期都沒有考慮在內(nèi)。這種計劃，定與不定又有什么差別呢？
我最早接觸迭代這個詞是從一個朋友那里。他對我說："自然界中的物體從來就沒有以直線形式存在的，螺旋狀的物體才是符合規(guī)律的，例如DNA。"他這話雖然聽起來很玄。但是卻很適合放在需求過程中。直線條的需求過程顯得干澀，孤立，易斷。而有螺旋的（迭代的，增量的）需求過程不論從那一個切面去看，都能夠形成比較穩(wěn)定的形狀。
其實這個道理是很簡單的。在我還是個寫程序的菜鳥的時候，為了不至于編譯時出現(xiàn)一大堆的Error，于是就采用穩(wěn)扎穩(wěn)打的方法，寫一小段程序除一次bug。而迭代也是這樣，是把以前需要一年才能看到結果的過程分成多個小過程，每隔一小段時間就可以看到一定的改進。體現(xiàn)在需求上，以前要一口氣做完的需求往往會劃分為多個的階段，每個階段完成一些功能。這樣做有什么好處呢？
迭代式的需求開發(fā)并不是意味著需求開發(fā)平均分到各個迭代周期來進行。在理論上，應該是先做完需求分析（還有構架設計），再著手進行各階段的開發(fā)工作?？墒菍嶋H情況中，需求要保持不變可太難了。根據(jù)自身的經(jīng)驗，一個項目，在一開始往往可以完成的需求開發(fā)可以占全部需求開發(fā)任務的80%（估算的數(shù)字）。但是在隨后的軟件開發(fā)中浮現(xiàn)出來的需求（新增或改動）又會有20%。可是這20%的需求是極不穩(wěn)定的，可能分布在項目中期，也可能分布在項目晚期，甚至可能會在項目在部署階段才會呈現(xiàn)出來，這些都取決于團隊的能力。這樣的項目的風險其實是很高的，有些較晚才浮現(xiàn)出來的需求可能會花費大量的資源來實現(xiàn)，如果這需求又對軟件架構有影響的話，那后果更是災難性的。
在XP中，一個迭代周期會包括多張素材卡片（Story Card），一張素材卡片都代表了系統(tǒng)的一項功能（functionality），這些素材卡片由項目負責人和客戶、領域?qū)＜野凑找欢ǖ囊?guī)則，共同從需求集中抽取，決定在本次迭代中實現(xiàn)。一次迭代經(jīng)過計劃、準備素材卡片、分析、編碼實現(xiàn)、測試、構建等步驟，呈現(xiàn)在用戶面前的將是一個可以運行（can work）的軟件。用戶可以清晰的看到軟件的界面，軟件的使用手冊，軟件的輸出結果。一切都是一覽無遺的，不需要任何的敘述性的語句來描述軟件，因為用戶會自己去感受。接下來，用戶的反饋意見被收集，分析，處理，必要的需求改變被安排在隨后的某個迭代周期中實現(xiàn)。
單獨的迭代可能是線性的，但是從整體上來看，多個迭代周期形成了一個流水線般的生產(chǎn)方式：
| 迭代示例 | |||||||||||
| 迭代1 | 迭代2 | 迭代3 | 迭代4 | ||||||||
| 準備迭代2 | 構建迭代1 | 準備迭代3 | 構建迭代2 | 交付迭代1 | 準備迭代4 | 構建迭代3 | 交付迭代2 | 準備迭代5 | 構建迭代4 | 交付迭代3 | |
所以呢，需求迭代的特殊性在于需求的出現(xiàn)并非是迭代的，但是需求的分析和實現(xiàn)則是迭代的。
就和計算機中任何的算法都必須尋求空間和時間的平衡一樣，迭代方法雖然有其優(yōu)勢，但是同樣需要付出代價。
由于要不斷的對軟件進行調(diào)整，所以軟件的架構（Architecture）需要比較穩(wěn)定，經(jīng)得起變動。這一點可能在過去比較難，現(xiàn)在的軟件架構都相當成熟，都能勝任這種工作。例如J2EE就是一個非常出色的架構。除了架構，系統(tǒng)的框架（Framework）也是非常的重要，框架要足夠"軟"，這個方面雖然沒有現(xiàn)成的框架可以利用，但是業(yè)界有很多關于這方面的資料，例如設計模式、分析模式。這些都是告訴你一些經(jīng)驗之談。都是可以參考和采用的。
多個的發(fā)布版本要求開發(fā)團隊有控制版本的能力。多個的開發(fā)版本如果不加控制到最后必然如同洪水猛獸一般可怕，開發(fā)人員的時間都浪費在各個版本的統(tǒng)一上。關于版本控制，有很多的軟件都能夠完成這一工作。對于比較小的團隊來說，簡單的目錄控制可能就足夠了。
上面畫出的迭代示意圖雖然好看，要實現(xiàn)可沒有那么簡單，如果功力不足，畫虎不成反似犬，原來安排的迭代計劃沒有嚴格執(zhí)行，結果是更加混亂。這時候就要求團隊的項目經(jīng)理有足夠的計劃能力，以及團隊的配合。
需求變更，并不是所有的需求都一概接受。對于時間所剩無幾的項目，一個簡單的需求變更都可能是駱駝身上的最后一根稻草。這就要求團隊能夠有需求變更的管理能力。
在進入細節(jié)需求之前，千萬要先確定系統(tǒng)的架構。國內(nèi)的程序員很少會專門去思考這個問題，但是會自發(fā)的去做這件事情。比如，你是選用微軟的DNA，還是J2EE。這就是架構決策的一種。但是我們并沒有重視架構的設計。架構方面的欠考慮，會使得架構的涉眾蒙受重大的損失。想想看，一家企業(yè)想要改變原有的架構，那是需要多大的成本啊。
由于我們文章的主題是需求，所以架構方面的問題并不在討論范圍之內(nèi)。但是，請記住，先決定架構，再進入細節(jié)需求階段。當然，這并不是說，進入細節(jié)需求階段就不能改變原先的架構了。原因很簡單，亡羊補牢嘛！
由于細節(jié)需求是迭代進行的，所以每一次迭代就像是一個小型的瀑布模型，要經(jīng)歷需求、分析、設計、編碼、接受測試、交付等階段。這樣，細節(jié)需求實際上是和軟件開發(fā)過程中的其它階段緊密相連，其中可能并沒有很明顯的界限。在下一章中，我們其實可以發(fā)現(xiàn)，探究需求活動和其它的活動都是同步進行的。
林星，辰訊軟件工作室項目管理組資深項目經(jīng)理，有多年項目實施經(jīng)驗。辰訊軟件工作室致力于先進軟件思想、軟件技術的應用，主要的研究方向在于軟件過程思想、Linux集群技術、OO技術和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com 和他聯(lián)系。
聯(lián)系客服
