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