對(duì)軟件研發(fā)項(xiàng)目管理的深入探討(存儲(chǔ)版)
【正文】 素，特別是在一些大型的涉及重要領(lǐng)域的管理信息系統(tǒng)中。以后對(duì)需求的更改都必須在基線的基礎(chǔ)上進(jìn)行，并需要項(xiàng)目組各成員的一致確認(rèn)，對(duì)需求進(jìn)行嚴(yán)格規(guī)劃評(píng)審的目的也在于在項(xiàng)目的后期能盡量減少對(duì)需求的更改，提高開(kāi)發(fā)的效率。由于這些計(jì)劃安排是預(yù)估粗略的，所以還必須在以后的項(xiàng)目各階段完成后進(jìn)行合理的變更，反應(yīng)項(xiàng)目的實(shí)際需求。一些軟件企業(yè)往往不是很重視風(fēng)險(xiǎn)管理，導(dǎo)致在項(xiàng)目的后期出現(xiàn)了很多預(yù)料之外的事情，使項(xiàng)目進(jìn)度一拖再拖，往往質(zhì)量也達(dá)不到預(yù)期要求。傳統(tǒng)的開(kāi)發(fā)總是在項(xiàng)目的后期才開(kāi)始整合各模塊，使產(chǎn)生的問(wèn)題改正起來(lái)極為困難，成本也大大增加。這種在開(kāi)發(fā)階段的迭代方式不同于整個(gè)項(xiàng)目的完全迭代開(kāi)發(fā)，后者是項(xiàng)目的需求、概要設(shè)計(jì)、開(kāi)發(fā)等全部是迭代進(jìn)行，一次迭代要進(jìn)行所有的項(xiàng)目活動(dòng)。一個(gè)一般的MIS程序，第一階段可以構(gòu)建數(shù)據(jù)庫(kù)結(jié)構(gòu)和基于特定領(lǐng)域的核心平臺(tái)服務(wù)(包括一些基本服務(wù)類)，并進(jìn)行初步整合。項(xiàng)目負(fù)責(zé)人需要把整個(gè)的項(xiàng)目歷程整理成一份文件，其中包括項(xiàng)目的介紹、項(xiàng)目進(jìn)行的具體資料(如實(shí)際花費(fèi)時(shí)間、源代碼數(shù)、功能模塊數(shù)量等)、項(xiàng)目計(jì)劃與實(shí)際的比較等。、過(guò)程、商務(wù)及技術(shù)領(lǐng)域。如果對(duì)這些風(fēng)險(xiǎn)不提前作出計(jì)劃，可能會(huì)對(duì)項(xiàng)目的順利進(jìn)行造成極大的破壞，甚至直接導(dǎo)致項(xiàng)目失敗。，質(zhì)量管理應(yīng)該貫穿整個(gè)項(xiàng)目始終，從需求、設(shè)計(jì)到編碼、測(cè)試。我曾經(jīng)經(jīng)歷過(guò)一個(gè)項(xiàng)目，項(xiàng)目負(fù)責(zé)人堅(jiān)持用C++ Builder開(kāi)發(fā)(可能是為了學(xué)習(xí)的原因)，但是公司沒(méi)有任何一個(gè)人對(duì)這個(gè)工具非常熟悉，也沒(méi)有進(jìn)行相應(yīng)的風(fēng)險(xiǎn)管理。我們碰到最棘手的問(wèn)題就是項(xiàng)目的度量(Metrics)，怎么更合理估算項(xiàng)目的大小，估算軟件開(kāi)發(fā)人員的生產(chǎn)率，更合理的項(xiàng)目計(jì)劃等，這也是CMM4所要求的內(nèi)容。，最好在基本的軟件架構(gòu)上(如COM或J2EE)實(shí)現(xiàn)一個(gè)該領(lǐng)域的基礎(chǔ)開(kāi)發(fā)平臺(tái)，這樣在以后的擴(kuò)展上，在具體項(xiàng)目的實(shí)施上，都會(huì)極大的節(jié)省成本，軟件的質(zhì)量也有良好的保證。我們使用的是MS Project來(lái)管理項(xiàng)目過(guò)程，Project一個(gè)很好的優(yōu)點(diǎn)是能把項(xiàng)目管理的內(nèi)容自動(dòng)發(fā)布到網(wǎng)站上去，這極大地方便了各階層人員對(duì)項(xiàng)目狀態(tài)的了解，有助于及時(shí)發(fā)現(xiàn)問(wèn)題解決問(wèn)題，對(duì)項(xiàng)目組成員也是個(gè)很好的激勵(lì)方法。一個(gè)容易犯的錯(cuò)誤是把質(zhì)量管理和測(cè)試等同起來(lái)，如果軟件有問(wèn)題就是測(cè)試沒(méi)做好。對(duì)風(fēng)險(xiǎn)的評(píng)級(jí)MSF采用的方式是：風(fēng)險(xiǎn)影響程度=風(fēng)險(xiǎn)的可能性風(fēng)險(xiǎn)發(fā)生造成的損失，根據(jù)風(fēng)險(xiǎn)影響程度的大小對(duì)風(fēng)險(xiǎn)進(jìn)行評(píng)級(jí)。一個(gè)項(xiàng)目的風(fēng)險(xiǎn)有許多來(lái)源，如客戶、進(jìn)度、開(kāi)發(fā)過(guò)程、人力資源等，忽視風(fēng)險(xiǎn)的后果可能是成本超支、進(jìn)度推后，最嚴(yán)重導(dǎo)致項(xiàng)目失敗。才能真正地把以往的項(xiàng)目納入公司的資源庫(kù)，轉(zhuǎn)化成巨大的財(cái)富。實(shí)踐證明，這樣的實(shí)施比傳統(tǒng)方法確實(shí)在很大程度上減小了項(xiàng)目失敗的風(fēng)險(xiǎn)，再?zèng)]有產(chǎn)生那種“似乎永遠(yuǎn)也做不完的感覺(jué)”。也有利于項(xiàng)目組在項(xiàng)目后期時(shí)間很緊的情況下，去掉一些不重要的功能，把它們納入下一個(gè)版本處理，確保產(chǎn)品的推出時(shí)間。階段開(kāi)發(fā)過(guò)程不是傳統(tǒng)的根據(jù)模塊劃分來(lái)依次完成各模塊，最后再進(jìn)行項(xiàng)目的整合，而是在每個(gè)階段完成后，項(xiàng)目都可以推出產(chǎn)品，只不過(guò)該產(chǎn)品的功能比最終產(chǎn)品的功能弱一些。如果進(jìn)度表和要求的出貨時(shí)間有沖突，寧愿砍掉一些不重要的功能，也不要盲目增加人手，這種做法可能會(huì)導(dǎo)致產(chǎn)品質(zhì)量下降，最終得不償失，詳細(xì)說(shuō)明請(qǐng)參考[4]。一般國(guó)內(nèi)的中小軟件公司對(duì)項(xiàng)目工作量和開(kāi)發(fā)人員能力的量化程度不高，所以導(dǎo)致進(jìn)度和資源安排不確切，有時(shí)候甚至是相差很遠(yuǎn)。項(xiàng)目管理培訓(xùn)需求的管理也是非常重要的方面。通過(guò)原型法，能讓用戶看到并模擬使用最終的產(chǎn)品界面，能在需求階段通過(guò)修正軟件界面來(lái)適應(yīng)用戶的偏好，從而在很大程度上提高了產(chǎn)品的易用性，使項(xiàng)目更容易成功。根據(jù)我們的經(jīng)驗(yàn)，優(yōu)秀的產(chǎn)品經(jīng)理+用戶參與+原型法=良好的需求說(shuō)明。通過(guò)可行性分析，揭示了即將面臨的各種問(wèn)題及風(fēng)險(xiǎn)，使得公司內(nèi)部對(duì)該項(xiàng)目有了一致的認(rèn)識(shí)，在后來(lái)的資源申請(qǐng)上也更容易得到高層支持，更易于導(dǎo)致項(xiàng)目成功。我以前就碰到過(guò)這種情況，一個(gè)項(xiàng)目的領(lǐng)域和公司以前的領(lǐng)域不盡相同，在立項(xiàng)前沒(méi)有充分考慮各種情況，認(rèn)為這個(gè)項(xiàng)目比較簡(jiǎn)單，應(yīng)該沒(méi)什么問(wèn)題，結(jié)果是沒(méi)有做得很成功，進(jìn)度上也拖了一段時(shí)間。其中“前景范圍確認(rèn)”對(duì)應(yīng)傳統(tǒng)的“可行性分析”。④縮短生命周期。根據(jù)我們的經(jīng)驗(yàn)，通過(guò)設(shè)定產(chǎn)品經(jīng)理，主要的感覺(jué)是產(chǎn)品受用戶的歡迎程度增加了，無(wú)用的特性少了，因而也更容易成功。有一個(gè)項(xiàng)目經(jīng)理對(duì)項(xiàng)目完全負(fù)責(zé)，遇到問(wèn)題容易很快得到解決。項(xiàng)目管理論壇MSF風(fēng)險(xiǎn)管理過(guò)程主要包括：風(fēng)險(xiǎn)識(shí)別、
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1