【正文】 第一篇：軟件開發(fā)項目管理實施方案.項目管理實施方案作為一個項目管理者,如何要成功的做好項目管理。首先必須先要明白的是在特定的領(lǐng)域中賦予這個角色所要實現(xiàn)的目標、承擔的職責、以及項目管理者的具體工作內(nèi)容是什么? 從我個人的淺見和角度以及我們所從事的IT領(lǐng)域來分析回答以上三個問題。第一:目標作為一個項目的管理者,必須要明確的知道自己的工作目標。我個人認為項目管理者的目標無非就是以下兩點:就是清晰明確地了解項目利害關(guān)系者的需求和期望,努力做到滿足項目利害關(guān)系者的不同需求。項目利害關(guān)系者包括:項目團隊成員和項目團隊外成員(比如各部門的部門負責人和市場人員,客戶等。就是保證開發(fā)項目按需按時保質(zhì)的完成。第二:職責作為項目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責,認識到這份工作職責的本質(zhì)。項目管理者不是來管人的,而是來支持人的,是來協(xié)調(diào)資源的,是來營造一個適合團隊成員比較認同的工作環(huán)境和氛圍的,是來為一個共同的目標和大家一起戰(zhàn)斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c:建立有效的工作流程保證項目的順利進行。制定詳細周密的項目計劃。跟蹤,推動項目按計劃進行。積極解決項目過程中出現(xiàn)的問題和沖突。調(diào)動開發(fā)團隊的積極性,創(chuàng)造力,推動團隊成員在項目過程中不斷成長。項目風險識別、風險評估、風險解決和風險管理策略以及做好突發(fā)風險的應(yīng)急預(yù)案。實現(xiàn)目標第三:項目管理者的具體工作內(nèi)容最后一個是項目管理者的具體工作內(nèi)容,作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心,分為以下六點:項目前期階段對項目進行技術(shù)可行性分析、技術(shù)評估、成本評估以及風險評估。與需求提出方的代表進行需求討論,明確項目的目標、價值。確定項目范圍、功能及優(yōu)先級。組建項目團隊,特別要搞清楚項目的key person(對產(chǎn)品有決定權(quán)的人。項目啟動會議,相關(guān)的利害關(guān)系人員都必須參加。該階段完成后的成果:確認后的最終軟件需求規(guī)格說明書文檔。分析設(shè)計階段根據(jù)確認后的軟件需求規(guī)格說明書,制定項目進度計劃,工作任務(wù)分解(WBS。資源申請,項目涉及到的開發(fā)資源、測試資源、設(shè)計資源(包括人員和軟硬件資源。數(shù)據(jù)庫設(shè)計。系統(tǒng)設(shè)計。文檔(包括Use Case、Demo系統(tǒng)原型、Test Case等。評審會議。該階段完成后的成果: A、User Case(系統(tǒng)用例。B、DEMO(系統(tǒng)原型。C、系統(tǒng)設(shè)計文檔(概要設(shè)計和詳細設(shè)計。D、數(shù)據(jù)庫設(shè)計文檔。最后對完成的成果,包括User Case和設(shè)計文檔等進行評審。執(zhí)行階段(開發(fā)和測試準備開發(fā)環(huán)境、測試環(huán)境。跟蹤,推動項目按計劃進行。以周報的形式通報項目的進展情況。對項目的階段成果進行評估,以確保該階段完成的質(zhì)量,包括代碼審核、SQL 審核等。對需求變更進行控制管理。對項目風險進行管理。測試階段BUG FIXED及改進、收集反饋意見。發(fā)布階段包括制定項目發(fā)布計劃,用戶培訓,發(fā)布上線。上線后監(jiān)控數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài),根據(jù)監(jiān)控出現(xiàn)的問題,及時進行BUG FIXED及改進或做補丁升級。結(jié)束階段產(chǎn)品交付,項目總結(jié)會。第四:基于以上三個問題所做的應(yīng)對細則要做好項目管理,并能確實解決好以上三個問題,實現(xiàn)目標、履行職責、完成工作中的具體內(nèi)容,從我個人這幾年的工作經(jīng)驗和面臨的一些問題,還有所積累的一些項目管理中的一些知識以及自己的觀察和思考的角度看,應(yīng)該要努力做好以下這幾個方面的具體工作:項目開發(fā)時間的估算制定項目進度時間表的時候,需要估算每個任務(wù)所需的時間,其中開發(fā)任務(wù)中模塊的分配和時間估算是其中最主要的部分。在分配模塊和估算開發(fā)時間時需要遵循的原則和目標:保證項目整體的進度。有助于確保開發(fā)編碼的質(zhì)量。有助于提高開發(fā)編碼的速度。在公司現(xiàn)有的技術(shù)框架下,開發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個模塊所需的開發(fā)時間取決于以下三個因素:所負責模塊的商業(yè)邏輯的復(fù)雜程度。開發(fā)人員的技術(shù)水平和對項目所在應(yīng)用的熟悉程度(包括對框架和應(yīng)用的熟悉程度。該模塊技術(shù)實現(xiàn)上是否有技術(shù)難點。這里所謂的技術(shù)難點定義是:在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未沒接觸過的技術(shù)。對于這樣的難點,開發(fā)者沒有相關(guān)的代碼可以參考,自己也沒有經(jīng)驗,所以需要投入一些時間研究解決。模塊分配和開發(fā)時間估算的步驟:在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發(fā)時間。然后召集所有開發(fā)人員,討論模塊的分配和開發(fā)時間估算。將劃分好的模塊,讓開發(fā)人員從中挑選他們感興趣的模塊。這樣做可以提高開發(fā)人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮,以確保開發(fā)的速度和質(zhì)量: A、相同類似的模塊由同一人負責開發(fā),比如用戶管理的增刪改由同一開發(fā)者負責。這樣做的好處就是開發(fā)者對相關(guān)邏輯會更加熟悉,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現(xiàn)的缺陷也相應(yīng)的會降低。B、技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負責。C、業(yè)務(wù)邏輯比較復(fù)雜的由對這塊邏輯比較了解的人負責。模塊分配完后,開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術(shù)實現(xiàn),以便使時間的估算更加準確。對開發(fā)人員估算的時間進行確認。在確認過程中作為項目管理者應(yīng)參考以上提到的三個因素,同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的,將與技術(shù)人員探討其中的緣由。對于時間周期比較長的任務(wù),盡量將任務(wù)通過再細分的手段細化任務(wù),爭取每個任務(wù)的最長時間不超過3天。時間周期越長的任務(wù),不確定性越高,風險也越高,越有可能成為項目的瓶頸,影響項目的進度。Code Review Code Review是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié),在這一環(huán)中我們公司做的非常欠缺,把關(guān)不嚴格。這是導(dǎo)致每次測試后出現(xiàn)大量bug的主要原因,這一環(huán)需要納入績效考核中,實行責任追究制,實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié),造成這樣的原因,我想也是有很多因素造成的。比如開發(fā)人員對需求不是很明確,以自己比較主觀的因素去完成任務(wù)的。還有對整個系統(tǒng)業(yè)務(wù)邏輯沒有正確的清晰的認識的原因,以及對項目組成員培訓不到位的原因等眾多因素糾集在一起才產(chǎn)生的。如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,Code Review要有“代碼審核規(guī)范”文檔:記錄代碼實現(xiàn)應(yīng)該遵循的標準。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn),代碼編寫者必須要嚴格按照規(guī)范來進行。代碼審核者根據(jù)這些標準來Code Review代碼,同時在Code Review過程中不斷完善該文檔。在做好這些前期工作的前提下,分以下幾個步驟來實施:檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。從代碼的易維護性、可擴展性角度考察代碼的質(zhì)量,提出修改建議。代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照Use Case依次講解自己負責 的代碼和相關(guān)邏輯,從Web層到Manage層再到Dao層。代碼審核者在此過程中可以隨時提出自己的疑問,同時積極發(fā)現(xiàn)隱藏的bug。對這些bug記錄在案。代碼講解完畢后,代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設(shè)計優(yōu)良。代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報告”,“審核報告”中記錄發(fā)現(xiàn)的問題及修改建議,然后把“審核報告”發(fā)送給相關(guān)人員。代碼編寫者根據(jù)“代碼審核報告”給出的修改意見,修改好代碼,有不清楚的地方可積極向代碼審核者提出。代碼編寫者bug fixed完畢之后給出反饋。代碼審核者把Code Review中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中, 對于特別值得提醒的問題可群發(fā)給所有技術(shù)人員。如果通過以上步驟,還因為是代碼編寫者的原因而出現(xiàn)嚴重的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批評。需求變更管理需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的成功與否。對待需求變更的態(tài)度:需求變更是不可避免的。需求變更要必須被管理。積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風險。需求變更管理的目標:相關(guān)的干系人必須清楚地了解發(fā)生的變更。變更處于有效的管理中。盡量降低變更帶來的風險。通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現(xiàn)上述的目標。需求變更流程:確定需求的基準線。將以User Case作為需求基準線,在User Case確認之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工作很混亂,也就是因為沒有一個規(guī)范的變更流程而造成的。如果建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認可。項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關(guān)人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進度,費用,質(zhì)量等計劃。項目管理者作為項目的負責人,對項目的成功與否負有主要的責任。所以需求變更的決策者應(yīng)該由項目管理者承擔。需求變更確認后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關(guān)的,他們必須知曉并認可此需求變更。包括(客戶方,需求分析人員,測試人員,相關(guān)開發(fā)人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 原因變更提出 者開發(fā)人員對進度的 影響(工 作量