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