應(yīng)變之道 淺析需求變更管理
閱讀提示:本文作者從項(xiàng)目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量,然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤,最后講述了當(dāng)真正發(fā)生需求變更的時候,我們應(yīng)該如何去面對。
需求總是在變化,客戶總會有新的想法,項(xiàng)目好像沒有終結(jié),我們軟件開發(fā)人員應(yīng)對軟件需求變化時,為了擁有更多的準(zhǔn)備,應(yīng)該做些什么呢?
這個世界唯一不變的就是變化了。月有陰晴圓缺,潮漲潮落,千年前的滄海是現(xiàn)在的良田,這是自然界的變化;人有悲歡離合,生老病死,這是人情世故。變化是并不一定總是給我們帶來驚喜,更多的是帶來意外,使得我們被迫去作一些改變來適應(yīng)這種變化。
所以,變化也是我們?nèi)祟惖靡詮暮唵紊镞M(jìn)化到今天的推動力。
回到我們軟件需求這個論題上來,無疑,變化是需求的一個基本特性。
沒有一成不變的需求,無論我們在正式構(gòu)建之前對需求進(jìn)行了多么深入的開發(fā),和客戶進(jìn)行了多少回合的反復(fù)驗(yàn)證,而最終卻不得不接受這樣的現(xiàn)實(shí):系統(tǒng)正式上線之后,在客戶提交的試運(yùn)行報告中,客戶的需求發(fā)生了變化,或者客戶又提出了新的需求等等。
我們的軟件開發(fā)人員陷入了這樣的一個困境:需求總是在變化,客戶總會有新的想法,項(xiàng)目好像沒有終結(jié),即使驗(yàn)收通過,那也是草草完事,而不是想象中的那么完美。
這是一個殘酷的現(xiàn)實(shí)。之所以Fred Brooks敢在1987的《沒有銀彈》這篇論文中強(qiáng)調(diào)即使不存在銀彈,也能使得軟件工程的生產(chǎn)力在十年之內(nèi)提高十倍,這也是基于軟件需求自身復(fù)雜性的原因。
在本文中,筆者從項(xiàng)目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量,然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤,最后講述了當(dāng)真正發(fā)生需求變更的時候,我們應(yīng)該如何去面對。
我們先來看軟件需求的生命周期,正如軟件項(xiàng)目具有一般的過程,軟件需求也有著一個普遍的生命周期,如圖1所示:
圖1:軟件普遍的生命周期
圖1中的項(xiàng)目階段反映的是一般的項(xiàng)目過程,不管采用瀑布模型還是迭代開發(fā)或者是其他的軟件開發(fā)生命周期模型,這樣的一個基本過程都是需要遵循的。而需求的生命周期和項(xiàng)目的階段也是一一對應(yīng)的。
在項(xiàng)目的啟動階段,我們需要對項(xiàng)目進(jìn)行可行性分析,完成立項(xiàng)報告,在這個階段,也就種下了需求的“種子”,這個“種子”也決定了下面所有階段的努力是否有成果,如果項(xiàng)目根本就是不可行的,那么就別提最后的“結(jié)果”了,“種子”是否能“萌芽”也都是個未知之?dāng)?shù)。
如果通過了可行性分析,完成了項(xiàng)目的啟動過程。接下來我們就要把需求這顆“種子”種下去,通過需求調(diào)研和需求分析階段的努力,需求的“種子”開始“萌芽”,并且一直“成長”,直到“成熟”,需求“成熟”之后,我們就可以構(gòu)建需求基線,進(jìn)入項(xiàng)目構(gòu)建階段。
如果對還沒有“成熟”的需求就開始構(gòu)建,那么后果就是在構(gòu)建階段需求的反復(fù)變化,開發(fā)人員疲于奔命。
對“成熟”的需求進(jìn)行構(gòu)建,我們所交付的才是優(yōu)質(zhì)的“果實(shí)”,當(dāng)然,項(xiàng)目后期也不可避免有需求變更,這時,只要我們按照規(guī)定的流程進(jìn)行需求變更,將變更控制在一個可以接受的范圍,這是不會影響到我們最終的交付的“果實(shí)”。
做好需求變更的管理,最終的目的是為了有優(yōu)質(zhì)的交付品。從上面的圖中,我們可以得知,首先必須要有良好的“種子”和健康的“果樹”,最后才有可能結(jié)出優(yōu)質(zhì)的“果實(shí)”。所以,做好需求開發(fā)是有效需求變更管理的基礎(chǔ)。
重視需求開發(fā)
需求開發(fā)是在問題及其最終解決方案之間架設(shè)橋梁的第一步,是軟件需求過程的主體。一個項(xiàng)目的目的就是致力于開發(fā)正確的系統(tǒng),要做到這一點(diǎn)就要足夠詳細(xì)地描述需求,也就是系統(tǒng)必須達(dá)到的條件或能力,使用戶和開發(fā)人員在系統(tǒng)應(yīng)該做什么,不應(yīng)該做什么方面達(dá)成共識。
我們都知道開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么,最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求,這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。
需求開發(fā)就是為了解決這些問題,它必不可少的成果就是對項(xiàng)目中描述的用戶需求的普遍理解,一旦理解了需求,分析者、開發(fā)者和用戶就能探索出描述這些需求的多種解決方案。
這一階段的工作一旦做錯,將最終會給系統(tǒng)帶來極大損害的部分,由于需求獲取事物造成的對需求定義的任何改動,都將導(dǎo)致設(shè)計、實(shí)現(xiàn)和測試上的大量返工,而這時花費(fèi)的資源和時間將大大超過仔細(xì)精確獲取需求的時間和資源。
首先,軟件需求不能如實(shí)反映用戶的真正需要。比較常見的一種誤解是需求的簡單和復(fù)雜程度決定了用戶是否能夠真正理解相應(yīng)的內(nèi)容:誤認(rèn)為客戶只能看懂簡單的需求,但是對開發(fā)沒有直接幫助;只有復(fù)雜的需求才有用,但是大多用戶又不可能看得懂。事實(shí)上,造成這類問題的主要原因是捕獲的需求不能反映用戶的視角,因而,用戶站在自己的立場上很難判斷需求是否完備和正確,特別是在開發(fā)活動的早期。
其次,軟件需求不能被開發(fā)團(tuán)隊(duì)的不同工種直接共用。理論上,開發(fā)團(tuán)隊(duì)所有成員的工作內(nèi)容都受軟件需求制約;現(xiàn)實(shí)中,如果不采用理想的需求捕獲方式,只有分析人員的工作看起來和軟件需求的內(nèi)容直接關(guān)聯(lián),其它人的工作內(nèi)容和軟件需求的關(guān)聯(lián)并不直觀,形式上的差異或轉(zhuǎn)述往往不易察覺地造成了諸多歧義、冗余或者缺失。
本文并不會就此開始探討需求開發(fā)的問題,只是強(qiáng)調(diào)需求開發(fā)過程的重要,以及需求開發(fā)過程對需求變更的影響。就拿筆者親身參與的一個項(xiàng)目來說:我們遵循一般的軟件開發(fā)過程,通過前期一段時間的調(diào)研,做需求分析,客戶基本確認(rèn)之后,開發(fā)人員就投入到緊張的開發(fā)工作中,由于項(xiàng)目時間要求緊迫,在經(jīng)過測試人員的簡單確認(rèn)之后,進(jìn)入到試運(yùn)行階段。
結(jié)果是,在客戶的試運(yùn)行報告中,提出了很多問題,其中就有一條,關(guān)于一個數(shù)據(jù)查詢條件的設(shè)置,客戶要求的是模糊匹配查詢,而實(shí)現(xiàn)的卻是精確匹配查詢。在相關(guān)的需求文檔中,卻找不到任何相關(guān)的需求說明。
需求開發(fā)完成之后,進(jìn)入系統(tǒng)構(gòu)建階段,下面我們來談構(gòu)建過程中如何做好需求跟蹤,以便于后期需求變更的管理。
構(gòu)建過程中的需求跟蹤
跟蹤需求是高質(zhì)量軟件開發(fā)過程中必需的一個特性。用以保證開發(fā)過程中每一個步驟的正確性,以及該步驟與上一步的一致性。經(jīng)驗(yàn)表明,在需求規(guī)格、架構(gòu)、設(shè)計、開發(fā)和測試階段,對需求的跟蹤能力是確保實(shí)現(xiàn)高質(zhì)量軟件的重要因素,同時也為需求變更管理提供有力的支持。
跟蹤這些需求在每個階段的變化,并且分析變更帶來的影響,是現(xiàn)代軟件過程的一個主線,尤其是在一些事關(guān)重大的軟件工程項(xiàng)目中,需求跟蹤的影響更加突出。
歷史數(shù)據(jù)表明,如果需求沒有被完整的跟蹤,那么總會有遺失的需求或者是沒有解決的需求,或者是需求的變更沒有徹底進(jìn)行,導(dǎo)致部分影響被忽略了,而往往是這樣的失誤導(dǎo)致很嚴(yán)重的安全問題和可靠性問題,給客戶帶來不可估量的損失。
這樣的教訓(xùn)往往是非常慘痛而且印象深刻,筆者至今尤對這樣的一次“事故”記憶猶新。那是參加的一個預(yù)算項(xiàng)目,在我們開發(fā)即將結(jié)束的時候,客戶由于業(yè)務(wù)情況發(fā)生變化,提出了一條業(yè)務(wù)數(shù)據(jù)修改規(guī)則的變更。
對于這個這個業(yè)務(wù)數(shù)據(jù)的寫規(guī)則,雖然我們在需求文檔中有記錄,但是沒有將其與設(shè)計、開發(fā)構(gòu)件一一對應(yīng),建立它們之間的關(guān)聯(lián),導(dǎo)致在處理這條變更的時候,開發(fā)人員遺漏了一種情況的處理。
而這樣的問題直到在客戶的應(yīng)用系統(tǒng)運(yùn)行半年之后才由客戶發(fā)現(xiàn),雖然事情最后通過升級軟件、人工加工數(shù)據(jù)處理了這次意外,但是,事故給企業(yè)帶來的不僅是金錢上的損失,也給企業(yè)的聲譽(yù)帶來非常不利的影響。
圖2:需求跟蹤模型
在圖2跟蹤模型中,箭頭代表的是跟蹤的方向,模型表明,不僅在需求定義的領(lǐng)域跟蹤需求,而且我們也在實(shí)現(xiàn)領(lǐng)域和測試領(lǐng)域跟蹤需求。
在系統(tǒng)定義領(lǐng)域,包括有三個方向的跟蹤:從業(yè)務(wù)需求到產(chǎn)品特性的跟蹤;從用例到產(chǎn)品特性的跟蹤;從變更的需求到產(chǎn)品新特性的跟蹤。對于每一種跟蹤,我們都可以使用類似于如下的一個表格來管理。在實(shí)際項(xiàng)目中,要做好需求的跟蹤管理并非易事,也許我們可以使用電子表格,辦公軟件來協(xié)助處理,確實(shí),它們對于項(xiàng)目的管理非常有用。
但是,表格的問題在于難于維護(hù),特別是當(dāng)項(xiàng)目較大,存在復(fù)雜的關(guān)聯(lián)關(guān)系的情況,改變一個鏈接可能涉及到很多相關(guān)的鏈接,在這種情況下,維護(hù)就成了一場噩夢。
在這種情況下,我們要么簡化需求跟蹤處理,對大的模塊進(jìn)行跟蹤;要么使用專門的需求管理工具。如果是大型項(xiàng)目,最好使用工具來進(jìn)行管理。這樣,在我們面臨需求變更的時候,才能有備無患。
因時而變,做好需求變更控制
就如前文所述,變化總是避免不了的。變更天生就是軟件過程的一部分。在這種情況下,我們需要建立一個管理變更的過程,使得變更的工作得到控制,并能高效的發(fā)現(xiàn)變更,進(jìn)行影響分析,將變更有效的集成到現(xiàn)有系統(tǒng)中。
產(chǎn)生需求變更的因素包括內(nèi)部因素和外部因素,不管需求變更來自哪里,都需要遵循一個既定的流程來提出變更請求。
這樣的渠道根據(jù)實(shí)際的企業(yè)情況有各自的方案。一般說來,如果是來自客戶的變更,都需要遵照一個固定流程,通過一種正式的方式提交。即使客戶口頭的提出,那么也需要通過會議記錄、文件交由客戶簽字確認(rèn)后才正式進(jìn)入變更流程。
否則,如果在沒有正式依據(jù)下就進(jìn)行需求變更,這樣的項(xiàng)目將進(jìn)入無休止的修改和維護(hù)狀態(tài)。
對于提出的變更請求,首先可以通過項(xiàng)目小組指派專人負(fù)責(zé)進(jìn)行分析,包括該變更的可行性分析,對其他需求的影響分析,對項(xiàng)目進(jìn)度的影響分析等。在這個過程中,就需要利用前文中所述的各種需求跟蹤表格。
通過需求跟蹤表格,列舉出該變更所涉及需要修改的其他需求,影響的其他用例、測試用例、用例實(shí)現(xiàn)等。然后才可以對工作量進(jìn)行估算,評估該變更的可行性以及對項(xiàng)目進(jìn)度影響等。
變更開發(fā)結(jié)束之后,也需要組織相關(guān)人員對變更進(jìn)行評審,這樣的評審?fù)馨l(fā)現(xiàn)不少潛在的問題,比如有遺漏的需求沒有修改等。只有評審?fù)ㄟ^后,才能進(jìn)入下一階段,對變更相關(guān)的文檔、產(chǎn)品進(jìn)行維護(hù),使得需求文檔、設(shè)計文檔、產(chǎn)品保持一致性。至此,整個需求變更過程結(jié)束。
需求變更管理是需求管理中的一個重要部分,只有有效的需求變更管理提才能高產(chǎn)品的可能性,并使最終產(chǎn)品更接近于解決需求,提高了用戶對產(chǎn)品的滿意度,從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說,需求變更管理是產(chǎn)品質(zhì)量的基礎(chǔ)。
筆者通過對需求開發(fā)、需求跟蹤和需求變更過程三個方面對需求的變更管理進(jìn)行討論。一方面希望能引起業(yè)界對需求管理的關(guān)注,另外也希望能借此拋磚引玉,引發(fā)各位方家對需求管理方面的討論。
管理變更步驟:
● 提出變更請求
● 變更分析
● 變更評審
● 制定變更計劃
● 變更需求的開發(fā)
● 變更結(jié)果評審
● 維護(hù)變更
跟蹤需求變更的問題:
● 誰提出變更;
● 什么時候提出變更;
● 變更的內(nèi)容是什么;
● 為什么變更;
● 變更處理意見;
● 變更執(zhí)行結(jié)果。