1、細節(jié)需求時期和業(yè)務建模時期是不同的。

前面的章節(jié)談了很多業(yè)務建模的知識，可以看到整個過程基本上是串在一起的，嚴格按照軟件生命周期模型來說是屬于瀑布模型。這里就有問題了，我們在討論瀑布模型的時候已經用了很多的篇幅來鞭笞它了，這里我們又用回了這個模型，這是不是有點…。這樣做的一個很大的原因是業(yè)務建模有它的特性。在一些小的項目中，業(yè)務建模在軟件生命周期中所占比例一般不大，多半是為了了解業(yè)務環(huán)境的，其中BPA的成分會多一些，BPR的部分通常很少。所以其中如果發(fā)生了一些失誤的地方，可以在需求階段彌補。如果是那些諸如ERP的項目，那么業(yè)務建模和BPR會有很重要的位置，這個時候，一般要根據具體的情況來制定戰(zhàn)略，很難說是采用何種周期模型。而且業(yè)務建模一般需要的人手不多，也會安排在項目的早期。所以只要有審查，業(yè)務建模采用何種生命周期模型并不是特別重要的。不過這是對于那些特定的項目而言的，對于市場化的產品來說，應該有另外的過程，但這并不在我們的討論范圍內，以后有機會的話再和大家討論。

再說需求，需求的生命周期絕對不能按照瀑布模型的來。對程序員來說，最痛恨的一件事情就是需求改變。所以呢，大家想出一種需求凝固的辦法，在分析完了需求后，就把它固定起來，寫成文檔，讓客戶簽字。以后再有需求的增加或改變的話，就拿出這張紙說，"看吧，當時的要求可沒有這一項啊。"這種做法的惡果是顯而易見的。不過，有些企業(yè)則會反駁說，"沒有啊，我向來都是視客戶為上帝，這種事情我是不會做的，我會讓程序員增加這個功能。"可惜的是，這種縱容顧客，傷害程序員的做法更糟。還記得我在聽管理學課程的時候的一句話："員工是最重要的，客戶次之。"這是很有道理的，如果你的員工不滿意，那么員工直接服務的客戶又怎會滿意？所以無論是哪一種做法，都只能暫時解決問題，對未來造成的危害卻更大。

需求改變的危害很大，可是不變的需求從來就沒有存在過。如果說，過去的社會中，企業(yè)的需求能夠在一段相對長的時間內保持不變。那么，在現在這個全球化趨勢愈來愈明顯的社會中，一個不會變化的企業(yè)就只有死路一條。

曾經是大陸霸主的恐龍為什么會滅亡，而當時弱小的哺乳動物卻能夠存活下來，最大的原因就是面對著瞬息萬變的自然環(huán)境，恐龍沒有辦法改變自身來適應環(huán)境，而哺乳動物則可以。現在的社會也是一樣的。如果你的軟件企業(yè)所服務的客戶一家家歇菜，那你的下場也就可想而知了。所以，很明顯的，需求和變化幾乎就是同義詞。

回頁首

2、迭代

一方面是要求不變，一方面是要求改變。在這種矛盾的環(huán)境下，如何才能達到一個平衡點呢。

在已往的軟件開發(fā)過程中，多半都要求對未來作出預測。例如，需求要有前瞻性，設計要有可延展性?？墒沁@種做法往往難以實現?，F實中的變化何止千萬種，你都能做到算無遺策嗎？如果你說你在做計劃書的時候，可以估算到9月11號可能會發(fā)生災難，那我就沒話可說了。

一個中型以上的項目往往都需要數十人的團隊工作半年以上才可能完成。這時候的計劃還要加進人這個最不確定的因素。這樣，正確的估計簡直就是比登天還難。有很多自稱考慮周詳的計劃書，在進度安排時連假期都沒有考慮在內。這種計劃，定與不定又有什么差別呢？

我最早接觸迭代這個詞是從一個朋友那里。他對我說："自然界中的物體從來就沒有以直線形式存在的，螺旋狀的物體才是符合規(guī)律的，例如DNA。"他這話雖然聽起來很玄。但是卻很適合放在需求過程中。直線條的需求過程顯得干澀，孤立，易斷。而有螺旋的（迭代的，增量的）需求過程不論從那一個切面去看，都能夠形成比較穩(wěn)定的形狀。

其實這個道理是很簡單的。在我還是個寫程序的菜鳥的時候，為了不至于編譯時出現一大堆的Error，于是就采用穩(wěn)扎穩(wěn)打的方法，寫一小段程序除一次bug。而迭代也是這樣，是把以前需要一年才能看到結果的過程分成多個小過程，每隔一小段時間就可以看到一定的改進。體現在需求上，以前要一口氣做完的需求往往會劃分為多個的階段，每個階段完成一些功能。這樣做有什么好處呢？

1. 人們對較長的未來比較難以估計，但是卻可以大致估計出短時間內的未來。這就好比我說不出兩年后我是什么樣，可如果是兩個星期，我就有把握得多。
2. 把一個大目標分割為多個小目標，這樣人們能夠不斷的看到一個個目標被實現，這比長時間的等待大目標的實現要好的多。
3. 客戶總是說，我想看看軟件才能提出更多的需求。這符合人的本性，應該予以滿足。
4. 不斷的改進有利與開發(fā)人員和客戶的合作程度的提高。
5. 迭代的過程可以一定程度上消除原來品保人員等開發(fā)人員，開發(fā)人員等品保人員的瓶頸現象。

回頁首

3、需求迭代的特殊性

迭代式的需求開發(fā)并不是意味著需求開發(fā)平均分到各個迭代周期來進行。在理論上，應該是先做完需求分析（還有構架設計），再著手進行各階段的開發(fā)工作?？墒菍嶋H情況中，需求要保持不變可太難了。根據自身的經驗，一個項目，在一開始往往可以完成的需求開發(fā)可以占全部需求開發(fā)任務的80%（估算的數字）。但是在隨后的軟件開發(fā)中浮現出來的需求（新增或改動）又會有20%。可是這20%的需求是極不穩(wěn)定的，可能分布在項目中期，也可能分布在項目晚期，甚至可能會在項目在部署階段才會呈現出來，這些都取決于團隊的能力。這樣的項目的風險其實是很高的，有些較晚才浮現出來的需求可能會花費大量的資源來實現，如果這需求又對軟件架構有影響的話，那后果更是災難性的。

在XP中，一個迭代周期會包括多張素材卡片（Story Card），一張素材卡片都代表了系統(tǒng)的一項功能（functionality），這些素材卡片由項目負責人和客戶、領域專家按照一定的規(guī)則，共同從需求集中抽取，決定在本次迭代中實現。一次迭代經過計劃、準備素材卡片、分析、編碼實現、測試、構建等步驟，呈現在用戶面前的將是一個可以運行（can work）的軟件。用戶可以清晰的看到軟件的界面，軟件的使用手冊，軟件的輸出結果。一切都是一覽無遺的，不需要任何的敘述性的語句來描述軟件，因為用戶會自己去感受。接下來，用戶的反饋意見被收集，分析，處理，必要的需求改變被安排在隨后的某個迭代周期中實現。

單獨的迭代可能是線性的，但是從整體上來看，多個迭代周期形成了一個流水線般的生產方式：

所以呢，需求迭代的特殊性在于需求的出現并非是迭代的，但是需求的分析和實現則是迭代的。

回頁首

4、迭代的代價

就和計算機中任何的算法都必須尋求空間和時間的平衡一樣，迭代方法雖然有其優(yōu)勢，但是同樣需要付出代價。

由于要不斷的對軟件進行調整，所以軟件的架構（Architecture）需要比較穩(wěn)定，經得起變動。這一點可能在過去比較難，現在的軟件架構都相當成熟，都能勝任這種工作。例如J2EE就是一個非常出色的架構。除了架構，系統(tǒng)的框架（Framework）也是非常的重要，框架要足夠"軟"，這個方面雖然沒有現成的框架可以利用，但是業(yè)界有很多關于這方面的資料，例如設計模式、分析模式。這些都是告訴你一些經驗之談。都是可以參考和采用的。

多個的發(fā)布版本要求開發(fā)團隊有控制版本的能力。多個的開發(fā)版本如果不加控制到最后必然如同洪水猛獸一般可怕，開發(fā)人員的時間都浪費在各個版本的統(tǒng)一上。關于版本控制，有很多的軟件都能夠完成這一工作。對于比較小的團隊來說，簡單的目錄控制可能就足夠了。

上面畫出的迭代示意圖雖然好看，要實現可沒有那么簡單，如果功力不足，畫虎不成反似犬，原來安排的迭代計劃沒有嚴格執(zhí)行，結果是更加混亂。這時候就要求團隊的項目經理有足夠的計劃能力，以及團隊的配合。

需求變更，并不是所有的需求都一概接受。對于時間所剩無幾的項目，一個簡單的需求變更都可能是駱駝身上的最后一根稻草。這就要求團隊能夠有需求變更的管理能力。

回頁首

5、和其它階段的關系

在進入細節(jié)需求之前，千萬要先確定系統(tǒng)的架構。國內的程序員很少會專門去思考這個問題，但是會自發(fā)的去做這件事情。比如，你是選用微軟的DNA，還是J2EE。這就是架構決策的一種。但是我們并沒有重視架構的設計。架構方面的欠考慮，會使得架構的涉眾蒙受重大的損失。想想看，一家企業(yè)想要改變原有的架構，那是需要多大的成本啊。

由于我們文章的主題是需求，所以架構方面的問題并不在討論范圍之內。但是，請記住，先決定架構，再進入細節(jié)需求階段。當然，這并不是說，進入細節(jié)需求階段就不能改變原先的架構了。原因很簡單，亡羊補牢嘛！

由于細節(jié)需求是迭代進行的，所以每一次迭代就像是一個小型的瀑布模型，要經歷需求、分析、設計、編碼、接受測試、交付等階段。這樣，細節(jié)需求實際上是和軟件開發(fā)過程中的其它階段緊密相連，其中可能并沒有很明顯的界限。在下一章中，我們其實可以發(fā)現，探究需求活動和其它的活動都是同步進行的。

關于作者