團隊軟件研發(fā)項目需求變更的管理過程

1、團隊軟件研發(fā)項目需求變更的管理過程需求變更是因為需求發(fā)生變化。根據(jù)軟件工程思想，需求說明書一般要經(jīng)過論證，如果在需求說明書經(jīng)過論證以后，需要在原有需求基礎(chǔ)上追加和補充新的需求或?qū)υ行枨筮M行修改和削減，均屬于需求變更。需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清晰，但實際上他們提出的需求只是依據(jù)當前的工作所需，而采用的新設(shè)備、新技術(shù)通常會改動他們的工作方式;或要研發(fā)的系統(tǒng)對用戶來說也是個未知數(shù)，他們以前沒有過相關(guān)的使用經(jīng)驗。隨著研發(fā)工作的不斷進展，系統(tǒng)開始展現(xiàn)功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，

2、或?qū)σ郧疤岢龅男枨筮M行改動。他們了解得越多，新的需求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。團隊包括一般軟體公司狀況是：需求：定義模糊，我們一般是以客戶為導(dǎo)向，參差不齊的客戶，所以，很多團隊對需求變化的適應(yīng)力差。架構(gòu)：幾乎一半的團隊沒喲架構(gòu)師。我原來的公司沒有?，F(xiàn)在的公司有，但是，我還沒有感覺到他的價值，感覺更像是需求分析師。測試：這個就不說了。評審：不知道大家對這個怎么理解，我覺得應(yīng)該是很重要的，時發(fā)現(xiàn)、糾正問題的一個環(huán)節(jié)。過程：在CMMI中，雖然只占30%，但是，我覺得很重要，開發(fā)文檔、注解、單元測試、項目進度跟蹤?？蛻簦哼@一塊不熟，因為我一直面對公司內(nèi)部客戶，所以比較好搞定。在三

3、者中，CMMI是標準，他描述，量化了團隊的成熟度，和不足的地方，但是沒有告訴你怎么改進;SPI是對目標的檢測和過程的優(yōu)化。AP是過程，包括XP，RUP等等。我們來看看Xp,應(yīng)該是很多程序員喜歡的，但是，有多少團隊導(dǎo)入了XP開發(fā)。XP：開發(fā)周期采用動態(tài)迭代式。關(guān)鍵做法有：1.現(xiàn)場客戶;2.計劃博弈;3.系統(tǒng)隱喻;4.簡化設(shè)計;5，集體擁有代碼;6.結(jié)對編程;7.測試驅(qū)動;8.小型發(fā)布;9.重構(gòu);10.持續(xù)集成;11.每周40小時工作制;12.代碼規(guī)范計劃博弈:XP要求結(jié)合業(yè)務(wù)和技術(shù)情況，快速確定下一次發(fā)布的范圍。在項目計劃的4要素(費用、時間、質(zhì)量和范圍)中，由客戶選擇3個，而程序員可以選擇剩下

4、的1個。通常客戶從業(yè)務(wù)角度確定項目范圍、需求優(yōu)先級和開發(fā)進度，開發(fā)人員則做出具體的成本和技術(shù)估計。XP強調(diào)簡短和突發(fā)性的計劃，有時只用幾個小時甚至幾分鐘就能完成，而且可以隨時按需進行多次計劃。系統(tǒng)隱喻:XP通過一個簡單的關(guān)于整個系統(tǒng)如何運作的隱喻性描述(story)來指導(dǎo)全部開發(fā)。隱喻可以看作是一種高層次的系統(tǒng)構(gòu)想，通常包含了一些可以參照和比較的類和模式，它還給出了后續(xù)開發(fā)所使用的命名規(guī)則。XP不需要事先進行詳細地架構(gòu)設(shè)計。重構(gòu)：重構(gòu)是指在不改變系統(tǒng)行為的前提下，重新調(diào)整、優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)以減少復(fù)雜性、消除冗余、增加靈活性和提高性能。測試驅(qū)動：先寫測試，后編碼結(jié)對編程：由兩名程序員在同一臺電

5、腦上結(jié)成對子共同編寫解決同一問題的代碼。通常一個人寫代碼，另一個人同時負責保證代碼的正確性和可讀性，比如編寫單元測試程序、進行代碼走查。PP可以看作是一種非正式的持續(xù)進行的同行評審(peer review)。哎呀，看到這些，我就有點感慨了，是不是這些東西太理論化了，和實際情況相差太多了。實際情況，項目來了，馬上開需求會，分任務(wù)，然后需求評審，然后系統(tǒng)設(shè)計，數(shù)據(jù)建模，系統(tǒng)框架，開發(fā)，測試，小版本出來。一系列。最起碼，根本不可能一周40工作小時。實施需求變更管理需要遵循如下原則：1.建立需求基線。需求基線是需求變更的依據(jù)。在研發(fā)過程中，需求確定并經(jīng)過評審后(用戶參和評審)，能建立第一個需求基線。此

6、后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。2.制訂簡單、有效的變更控制流程，并形成文件。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以后的項目研發(fā)和其他項目都有借鑒作用。3.成立項目變更控制委員會(CCB)或相關(guān)職能的類似組織，負責裁定接受哪些變更。CCB由項目所涉及的多方人員一起組成，應(yīng)該包括用戶方和研發(fā)方的決策人員在內(nèi)。4.需求變更一定要先申請然后再評估，最后經(jīng)過和變更大小相當級別的評審確認。5.需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。6.妥善保存變更產(chǎn)生的相關(guān)文件。應(yīng)對之道需求變更控

7、制一般要經(jīng)過變更申請、變更評估、決策、回復(fù)這四大步驟。如果變更被接受，還要增加實施變更和驗證兩個步驟，有時還會有取消變更的步驟。變更控制流程如圖所示。針對變更控制流程，筆者在實際工作中總結(jié)出了軟件研發(fā)人員在需求變更管理實踐中的幾點對策：相互協(xié)作非常難想像遭到用戶抵制的項目能夠成功。在討論需求時，研發(fā)人員和用戶應(yīng)該盡量采取相互理解、相互協(xié)作的態(tài)度，對能解決的問題盡量解決。即使用戶提出了在研發(fā)人員看來"過分"的需求，也應(yīng)該仔細分析原因，積極提出可行的替代方案。充分交流需求變更管理的過程非常大程度上就是用戶和研發(fā)人員的交流過程。軟件研發(fā)人員必須學會認真聽取用戶的需求、考慮和設(shè)想，

8、并加以分析和整理。同時，軟件研發(fā)人員應(yīng)該向用戶說明，進入設(shè)計階段以后，再提出需求變更會給整個研發(fā)工作帶來什么樣的沖擊和不良后果。安排專職人員負責需求變更管理有時研發(fā)任務(wù)較重，研發(fā)人員容易陷入研發(fā)工作中而忽略了和用戶的隨時溝通，因此需要一名專職的需求變更管理人員負責和用戶及時交流。合同約束需求變更給軟件研發(fā)帶來的影響有目共睹，所以在和用戶簽訂合同時，能增加一些相關(guān)條款，如限定用戶提出需求變更的時間，規(guī)定何種情況的變更能接受、拒絕接受或部分接受，還能規(guī)定發(fā)生需求變更時必須執(zhí)行變更控制流程。差別對待隨著研發(fā)進展，有些用戶會不斷提出一些在項目組看來確實無法實現(xiàn)或工作量比較大、對項目進度有重大影響的需求

9、。遇見這種情況，研發(fā)人員能向用戶說明，項目的啟動是以最初的基本需求作為研發(fā)前提的，如果大量增加新的需求(雖然用戶認為是細化需求，但實際上是增加了工作量的新需求)，會使項目不能按時完成。如果用戶堅持實施新需求，能建議用戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據(jù)。同時，還要注意控制新需求提出的頻率。選用適當?shù)难邪l(fā)模型采用建立原型的研發(fā)模型比較適合需求不明確的研發(fā)項目。研發(fā)人員先根據(jù)用戶對需求的說明建立一個系統(tǒng)原型，再和用戶溝通。一般用戶看到一些實際的東西后，對需求會有更為周詳?shù)慕忉?，研發(fā)人員可根據(jù)用戶的說明進一步完善系統(tǒng)原型。這個過程重復(fù)幾次后，系統(tǒng)原型逐漸向最終的用戶需求靠攏，從根本上減少需求