IT軟件項(xiàng)目開發(fā)的具體實(shí)施方案

1、項(xiàng)目管理實(shí)施方案作為一個(gè)項(xiàng)目管理者，如何要成功的做好項(xiàng)目管理；首先必須 先要明 白的是在特定的領(lǐng)域中賦予這個(gè)角色所要實(shí)現(xiàn)的目標(biāo)、 承擔(dān)的 職責(zé)、以及項(xiàng)目管理者的具體工作內(nèi)容是什么？ 從我個(gè)人的淺見和 角度以及我們所從事的 IT 領(lǐng)域來分析回答以上三個(gè)問題。第一：目標(biāo)作為一個(gè)項(xiàng)目的管理者，必須要明確的知道自己的工作目標(biāo)； 我 個(gè)人 認(rèn)為項(xiàng)目管理者的目標(biāo)無非就是以下兩點(diǎn)：1、就是清晰明確地了解項(xiàng)目利害關(guān)系者的需求和期望，努力做 到滿足項(xiàng)目利害關(guān)系者的不同需求； 項(xiàng)目利害關(guān)系者包括：項(xiàng)目團(tuán)隊(duì) 成員和 項(xiàng)目團(tuán)隊(duì)外成員 （比如各部門的部門負(fù)責(zé)人和市場(chǎng)人員，客戶 等）。2 、就是保證開發(fā)項(xiàng)目按需按時(shí)保質(zhì)的

2、完成。第二：職責(zé)作為項(xiàng)目的管理者，首先要端正態(tài)度，要明確知道自己的工作 職責(zé)， 認(rèn)識(shí)到這份工作職責(zé)的本質(zhì)。項(xiàng)目管理者不是來管人的，而是 來支持人的， 是來協(xié)調(diào)資源的，是來營(yíng)造一個(gè)適合團(tuán)隊(duì)成員比較認(rèn)同 的工作環(huán)境和氛圍 的，是來為一個(gè)共同的目標(biāo)和大家一起戰(zhàn)斗共同成 長(zhǎng)的?？梢源蟾鸥爬ǔ梢?下幾點(diǎn)：1、建立有效的工作流程保證項(xiàng)目的順利進(jìn)行2、制定詳細(xì)周密的項(xiàng)目計(jì)劃3、跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。4、積極解決項(xiàng)目過程中出現(xiàn)的問題和沖突。5、調(diào)動(dòng)開發(fā)團(tuán)隊(duì)的積極性，創(chuàng)造力，推動(dòng)團(tuán)隊(duì)成員在項(xiàng)目過程中不 斷成長(zhǎng)。6、項(xiàng)目風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)評(píng)估、風(fēng)險(xiǎn)解決和風(fēng)險(xiǎn)管理策略以及做好突 發(fā)風(fēng)險(xiǎn)的應(yīng)急預(yù)案。7、實(shí)現(xiàn)目標(biāo)第三：

3、項(xiàng)目管理者的具體工作內(nèi)容最后一個(gè)是項(xiàng)目管理者的具體工作內(nèi)容，作為項(xiàng)目管理者必須 清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心， 分為 以下六點(diǎn)：1 項(xiàng)目前期階段 對(duì)項(xiàng)目進(jìn)行技術(shù)可行性分析、技術(shù)評(píng)估、成本評(píng)估以及風(fēng)險(xiǎn)評(píng)估。與 需求提 出方的代表進(jìn)行需求討論，明確項(xiàng)目的目標(biāo)、價(jià)值；確定項(xiàng)目 范圍、功能及 優(yōu)先級(jí)。組建項(xiàng)目團(tuán)隊(duì)，特別要搞清楚項(xiàng)目的 key person 對(duì)產(chǎn)品有決定權(quán)的 人 ）。項(xiàng)目啟動(dòng)會(huì)議，相關(guān)的利害關(guān)系人 員都必須參加。該階段完成后的成果：確認(rèn)后的最終軟件需求規(guī)格說明書文檔。2、分析設(shè)計(jì)階段根據(jù)確認(rèn)后的軟件需求規(guī)格說明書，制定項(xiàng)目進(jìn)度計(jì)劃，工作任務(wù)分 解（WBS ）;資

4、源申請(qǐng)，項(xiàng)目涉及到的開發(fā)資源、測(cè)試資源、設(shè)計(jì)資源包括人員和軟硬件資源）；數(shù)據(jù)庫(kù)設(shè)計(jì)；系統(tǒng)設(shè)計(jì)；文檔包括Use Case Demo 系統(tǒng)原型、 Test Case 等 ）; 評(píng)審會(huì)議。 該階段完成后的成果： A、User Case 系統(tǒng)用例 ）；B、DEMO （系統(tǒng)原 型）；C、系統(tǒng)設(shè)計(jì)文檔（概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)）；D、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔。 最后對(duì) 完成的成果，包括 User Case 和設(shè)計(jì)文檔等進(jìn)行評(píng)審。3、執(zhí)行階段 （開發(fā)和測(cè)試 ） 準(zhǔn)備開發(fā)環(huán)境、測(cè)試環(huán)境；跟蹤，推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行；以周報(bào)的形 式通報(bào) 項(xiàng)目的進(jìn)展情況。對(duì)項(xiàng)目的階段成果進(jìn)行評(píng)估，以確保該階段 完成的質(zhì)量， 包括代碼審核、 SQL

5、審核等。對(duì)需求變更進(jìn)行控制管理； 對(duì)項(xiàng)目風(fēng)險(xiǎn)進(jìn)行管 理；測(cè)試階段 BUG FIXED 及改進(jìn)、收集反饋意見。4、發(fā)布階段包括制定項(xiàng)目發(fā)布計(jì)劃，用戶培訓(xùn)，發(fā)布上線。5、上線后監(jiān)控?cái)?shù)據(jù)監(jiān)控 （ 日志、服務(wù)器狀態(tài) ） ，根據(jù)監(jiān)控出現(xiàn)的問題，及時(shí)進(jìn)行BUG FIXED 及改進(jìn)或做補(bǔ)丁升級(jí)。6、結(jié)束階段產(chǎn)品交付，項(xiàng)目總結(jié)會(huì)。第四：基于以上三個(gè)問題所做的應(yīng)對(duì)細(xì)則要做好項(xiàng)目管理，并能確實(shí)解決好以上三個(gè)問題，實(shí)現(xiàn)目標(biāo)、 履行職責(zé)、完成工作中的具體內(nèi)容，從我個(gè)人這幾年的工作經(jīng)驗(yàn)和面 臨的一些問題，還有所積累的一些項(xiàng)目管理中的一些知識(shí)以及自己的 觀察和思考的角度看，應(yīng)該 要努力做好以下這幾個(gè)方面的具體工作：1、項(xiàng)

6、目開發(fā)時(shí)間的估算 制定項(xiàng)目進(jìn)度時(shí)間表的時(shí)候，需要估算每個(gè)任務(wù)所需的時(shí)間，其中 開發(fā)任務(wù)中模塊的分配和時(shí)間估算是其中最主要的部分； 在分配模塊 和估算 開發(fā)時(shí)間時(shí)需要遵循的原則和目標(biāo)：1、保證項(xiàng)目整體的進(jìn)度。2、有助于確保開發(fā)編碼的質(zhì)量。3、有助于提高開發(fā)編碼的速度。 在公司現(xiàn)有的技術(shù)框架下，開發(fā)人 員主 要的工作是投入在具體的商業(yè)邏輯上。 通常每個(gè)模塊所需的開發(fā) 時(shí)間取決于 以下三個(gè)因素：1、所負(fù)責(zé)模塊的商業(yè)邏輯的復(fù)雜程度。2、開發(fā)人員的技術(shù)水平和對(duì)項(xiàng)目所在應(yīng)用的熟悉程度 （包括對(duì)框架和 應(yīng) 用的熟悉程度 ）。 3、該模塊技術(shù)實(shí)現(xiàn)上是否有技術(shù)難點(diǎn)； 這里所謂 的技術(shù) 難點(diǎn)定義是：在現(xiàn)有系統(tǒng)中還

7、未實(shí)現(xiàn)的、開發(fā)人員自身也未沒 接觸過的技 術(shù)。對(duì)于這樣的難點(diǎn)，開發(fā)者沒有相關(guān)的代碼可以參考， 自己也沒有經(jīng)驗(yàn)， 所以需要投入一些時(shí)間研究解決。模塊分配和開發(fā)時(shí)間估算的步驟：1、在劃分好模塊后，首先自己先估算一下每個(gè)模塊所需要的開發(fā)時(shí) 間。2、然后召集所有開發(fā)人員，討論模塊的分配和開發(fā)時(shí)間估算。將劃 分好的模塊，讓開發(fā)人員從中挑選他們感興趣的模塊。 這樣做可以提 高開發(fā)人員的主動(dòng)性和參與性。在分配模塊的時(shí)候還需從以下幾方面 考慮，以確保開發(fā)的速度和質(zhì)量：A 、 相同類似的模塊由同一人負(fù)責(zé)開發(fā)，比如用戶管理的增刪改由同 一開發(fā)者負(fù)責(zé)。這樣做的好處就是開發(fā)者對(duì)相關(guān)邏輯會(huì)更加熟悉， 同 時(shí)接口 的定義

8、也會(huì)比較明確，溝通的成本比較低，同時(shí)功能實(shí)現(xiàn)的缺 陷也相應(yīng)的會(huì) 降低。B、 技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。C、 業(yè)務(wù)邏輯比較復(fù)雜的由對(duì)這塊邏輯比較了解的人負(fù)責(zé)。3、模塊分配完后，開發(fā)人員評(píng)估自己負(fù)責(zé)開發(fā)的模塊所需要的時(shí)間。在此過程中最好做到要和開發(fā)者比較詳細(xì)的討論每個(gè)模塊的技術(shù)實(shí) 現(xiàn)，以便使時(shí) 間的估算更加準(zhǔn)確。4、對(duì)開發(fā)人員估算的時(shí)間進(jìn)行確認(rèn)。在確認(rèn)過程中作為項(xiàng)目管理者 應(yīng)參考 以上提到的三個(gè)因素，同時(shí)將自己估算的時(shí)間和開發(fā)人員估算 的時(shí)間進(jìn)行比 較。這其中的差異當(dāng)然會(huì)存在的。對(duì)于那些差異比較大 的，將與技術(shù)人員探 討其中的緣由。對(duì)于時(shí)間周期比較長(zhǎng)的任務(wù)，盡 量將任務(wù)通過再細(xì)

9、分的手段 細(xì)化任務(wù)，爭(zhēng)取每個(gè)任務(wù)的最長(zhǎng)時(shí)間不超 過 3 天；時(shí)間周期越長(zhǎng)的任務(wù)，不 確定性越高，風(fēng)險(xiǎn)也越高，越有可 能成為項(xiàng)目的瓶頸，影響項(xiàng)目的進(jìn)度。2、 Code ReviewCode Review 是保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié)，在這一環(huán)中我們公司做的非常欠缺，把關(guān)不嚴(yán)格；這是導(dǎo)致每次測(cè)試后出 現(xiàn)大量bug 的主要原因，這一環(huán)需要納入績(jī)效考核中，實(shí)行責(zé)任追究 制，實(shí)施重點(diǎn) 監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié)，造成這樣的原因，我想也 是有很多因素造成 的；比如開發(fā)人員對(duì)需求不是很明確，以自己比較 主觀的因素去完成任務(wù) 的；還有對(duì)整個(gè)系統(tǒng)業(yè)務(wù)邏輯沒有正確的清晰 的認(rèn)識(shí)的原因，以及對(duì)項(xiàng)目組 成員培訓(xùn)不到位的原因等眾多因素糾集 在一起才產(chǎn)生的。如何做好這方面的工作？首先編碼要有“編碼規(guī)范”文檔，Code Review 要有“代碼審核規(guī)范”文檔：記錄代碼實(shí)現(xiàn)應(yīng)該遵循的 標(biāo)準(zhǔn) 通過這兩個(gè)文檔來規(guī)范開發(fā)人員的代碼實(shí)現(xiàn)， 代碼編寫者必須 要嚴(yán)格按照規(guī)范來進(jìn)行；代碼審核者根據(jù)這些標(biāo)準(zhǔn)來 Code Review 代 碼， 同時(shí)在 Code Review 過程中不斷完善該文檔。在做好這些前期工作的前提下，分以下幾個(gè)步驟來實(shí)施：1、 檢查開發(fā)者的代碼實(shí)現(xiàn)是否遵循了編碼規(guī)范。2、 從代碼的易維護(hù)性、可擴(kuò)展性角度考察代碼的質(zhì)量，提出修改建 議。3、代碼編寫