需求管理和變更控制的經(jīng)驗

申請免費(fèi)試用、咨詢電話：400-8352-114

　　軟件工程里的許多問題，諸如缺陷及資源運(yùn)用不當(dāng)，都是源于需求的不確定。在90年代，我曾在美國一個擁有數(shù)千員工的公司里從事大型軟件開發(fā)工作。該軟件主要是賣給汽車修復(fù)廠用的，它可估算出修復(fù)汽車的零件及勞力兩項費(fèi)用，甚至還可以找到提供新零件及舊零件的廠家。軟件的的復(fù)雜度相當(dāng)?shù)馗撸缍ㄊ裁礃拥慕缑婧凸δ苁亲钸m合市場的著實不易。所以，需求一變再變。在聊天時有個同事戲稱：“需求變更乃萬惡之源!”其他的人紛紛響應(yīng)。當(dāng)時，所有的需求都是寫在Word文檔里的，那些文檔不是放在一個共享的服務(wù)器里，就是交由負(fù)責(zé)編寫程序的人員管理。雖然沒用什么管理平臺及工具，但在團(tuán)隊成員的配合和默契下，一切事情都有序地在進(jìn)展著。項目管理者聯(lián)盟

　　但有一天產(chǎn)品經(jīng)理換了個新的，一切事情似乎就全改變了。新的產(chǎn)品經(jīng)理原是某汽車修復(fù)廠的經(jīng)理，他對修汽車及車廠管理有不少的經(jīng)驗，但對軟件的開發(fā)是很不懂的。很快地下列問題出現(xiàn)了：PgMp.mypm.net

　　(一)需求描述不清楚，導(dǎo)致開發(fā)任務(wù)的時間估算誤差可到100%，甚至200%;項目管理論壇

　　(二)優(yōu)先及全由產(chǎn)品經(jīng)理決定，有時不太重要的任務(wù)先做了，重要的反倒后做;

　　(三)需求變更一再發(fā)生，并且當(dāng)某需求變更了，它的連鎖反應(yīng)會沖擊其他的部分，許多缺陷因此產(chǎn)生了。training.mypm.net

　　我們幾個資深人員分析整個過程，發(fā)現(xiàn)造成問題的原因是這樣的：項目管理者聯(lián)盟

　　(一)我們的現(xiàn)有需求文檔管理太亂，通常是找不到所要的版本。就算是找到要的文檔，常常也沒法找到要的那段內(nèi)容。bbs.mypm.net

　　(二)可判斷任務(wù)優(yōu)先級的因素頗多，可以是在商業(yè)層面或技術(shù)層面，每人的視角不同，公說公有理，婆說婆有理。blog.mypm.net

　　(三)需求文檔、代碼、測試用例及其他的工件(artifacts)之間應(yīng)是相關(guān)聯(lián)的，但在系統(tǒng)中我們無法從其中任一個工件找到其他的工件。項目管理者聯(lián)盟

　　由于文檔不全，這位新的產(chǎn)品經(jīng)理很難在短時間內(nèi)對整個系統(tǒng)有個概括性的了解。當(dāng)他和資深人員溝通產(chǎn)品設(shè)計理念及歷史緣由時，資深人員也沒能明確地回答他的問題，這導(dǎo)致需求設(shè)計不完善，優(yōu)先級也有誤。找到原因后，我們想既然需求變更這一頭兇猛野獸是殺不死的，那我們所能做的大概也就是將這獸關(guān)在籠子里，使它溫馴點。 為解決這問題，我們建立了以下的體制。項目管理者聯(lián)盟

　　(一)細(xì)化需求的時間估算 – 我們將需求分解到程序員能清楚估算出完成時間的小單位，原則上每單位是可以讓一個程序員及一個測試人員在二至十天內(nèi)做完，而且每個單位都有個編號。bbs.mypm.net

　　(二)使用版本控制系統(tǒng)管理需求文檔 – 所有需求文檔全保存在一中樞版本控制系統(tǒng)里。項目管理者聯(lián)盟

　　(三)將需求分組并設(shè)優(yōu)先級 – 所有的需求單位按照不同的版本區(qū)分開來，每個需求單位都有個優(yōu)先級。

       (四)建立工件之間的關(guān)聯(lián)性 – 將程序及測試用例與相對應(yīng)的需求單位連接上，明確地寫上需求編號。training.mypm.net

　　(五)建立評審團(tuán)隊 – 當(dāng)需求產(chǎn)生或變更時，產(chǎn)品經(jīng)理及干系人要一起評審，通過后才做更改。項目管理論壇