軟件研發(fā)項目管理最早源自于70年代中期。當(dāng)時美國國防部曾立題專門研究軟件項目做不好的原因,發(fā)現(xiàn)70%的項目是因為管理不善引起的,而并不是因為技術(shù)實力不夠,進而得出一個結(jié)論,即管理是影響軟件研發(fā)項目全局的因素,而技術(shù)只影響局部。這個結(jié)論非常重要。到了90年代中期,軟件研發(fā)項目管理不善的問題仍然存在。據(jù)美國軟件工程實施現(xiàn)狀的調(diào)查,軟件研發(fā)的情況仍然很難預(yù)測,大約只有10%的項目能夠在預(yù)定的費用和進度下交付。針對軟件項目管理不善的局面,我簡要談?wù)勗谲浖椖抗芾碇写嬖诘囊恍﹩栴}。
1 客戶需不需要全程參與
不少軟件企業(yè)認(rèn)為客戶的參與主要在三件事情上:協(xié)議簽訂和需求調(diào)研、客戶需求變更和項目驗收簽字,其它事情是企業(yè)內(nèi)部項目開發(fā)管理的事情,屬公司內(nèi)部行為,無需客戶參與。結(jié)果,企業(yè)經(jīng)常發(fā)現(xiàn)客戶嚴(yán)重拖延驗收,而且在驗收期間客戶大量的需求變更,致使項目的進展嚴(yán)重推遲。經(jīng)常一個預(yù)期盈利的項目,最后拖的不堪重負(fù)。
我認(rèn)為這里邊的一個重要原因就是客戶沒有參與項目的全過程。比方,項目初期的啟動會議、項目過程中所有干系人的知情制度,每周的工作例會、項目階段性工作總結(jié)等等都需要客戶的參與和反饋。否則當(dāng)企業(yè)一年之后提交一個無比龐大和復(fù)雜的最終方案時,客戶方根本不了解你的方案的進程,由誰敢簽字驗收呢?客戶只能花上幾個月來完全“肢解”消化整個方案,最終當(dāng)然是發(fā)現(xiàn)一大堆問題需要改進,企業(yè)只能再花上幾個月重新修改,如此往而復(fù)始,惡性循環(huán)。
2 如果需求分析很困難,可不可以先做軟件
對需求把握得越準(zhǔn)確,軟件的修修補補就越少。有些需求在一開始時很難確定,在開發(fā)過程中要不斷地加以改正。軟件修改越早代價越少,修改越晚代價越大,就跟治病一樣道理。
一是在項目的需求分析階段,開發(fā)方與客戶方在各種的問題的基本輪廓上達成一致即可,具體細(xì)節(jié)可以在以后填充。軟件過程改善是一個持續(xù)改善的過程,需要不斷地學(xué)習(xí),需要知識的積累,特別是當(dāng)主客觀環(huán)境發(fā)生變化時,需要對過程進行修改,以適應(yīng)變化了的情況。無論多么細(xì)致的需求分析,幾乎都難以避免修改。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細(xì)致,導(dǎo)致后來預(yù)算超出或者時間 進度達不到要求。這就要求在項目需求分析階段,開發(fā)方與客戶方必須全面地盡可能細(xì)致地討論項目的應(yīng)用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求,以及對項目進行評估的各種評價標(biāo)準(zhǔn)。并且,在需求分析結(jié)束以后,雙方還要建立可以直接聯(lián)系的渠道,以盡早地對需求變動問題進行溝通。
3 軟件項目需求的改變?nèi)菀讓崿F(xiàn)嗎
在具體實際中由于種種原因客戶方很難在需求分析階段全面而準(zhǔn)確地描述所有問題。隨著開發(fā)進度的推進,往往會有一些需求的改變。而現(xiàn)代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應(yīng)這種情況。不過,這并不表明“軟件項目的需求可以持續(xù)不斷的改變 ,而且這些改變可很容易地被實現(xiàn)”。實踐表明,隨著開發(fā)進度的推進,實現(xiàn)軟件需求更改所需要的代價呈指數(shù)形式增長。假定在需求分析階段實現(xiàn)需求更改需要花費1倍的代價;那么,在系統(tǒng)設(shè)計和編碼階段,需要花費1.5-6倍的代價;在系統(tǒng)測試階段需要花費10-20倍的代價;在軟件版本發(fā)布以后,甚至可能要花費60-100倍的代價。由此可見,在項目開展過程中,軟件需求的改變應(yīng)當(dāng)盡量早地提出。這樣才可能花費少,容易被實現(xiàn)。
4 項目的質(zhì)量提高是否要依賴完善的質(zhì)量測試制度
不少企業(yè)把軟件的測試工作定位于提高軟件開發(fā)項目的質(zhì)量。我認(rèn)為質(zhì)量測試制度只是一個補救措施,是來挑出各種因素造成的缺陷,但不能避免新的缺陷的出現(xiàn)。真正有效的質(zhì)量管理是建立在