軟件開發(fā)項目管理

1、 管理目標1、 所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(部/外部客戶，部/外部合作伙伴，經銷商/客戶等)。2、 項目管理三要素平衡（時間/成本/質量），即開發(fā)項目按需按時按質的完成。3、 目標：功能滿足需求，設計支持變化，開發(fā)快速迭代，成果持續(xù)交付。執(zhí)行概述1、 建立有效的工作流程保證項目的順利進行，初期使用傳統(tǒng)RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現(xiàn)敏捷開發(fā)全流程管理。2、 明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。3、 跟蹤設計/開發(fā)/測試/回歸/發(fā)布全流程，推動項目按預定計

2、劃執(zhí)行。4、 解決項目過程中出現(xiàn)的問題和沖突，一般集中在需求不明/工作量或時長/開發(fā)難度/跨部門協(xié)調等幾個方面。5、 調動開發(fā)團隊的積極性，創(chuàng)造力，推動團隊成員在項目過程中的學習成長。6、 風險識別、風險控制以與風險的預案。項目管理1、需求階段對項目進行技術可行性分析、技術評估、成本評估以與風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目圍、功能與優(yōu)先級。組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。2、設計階段根據(jù)確認后的軟件需求規(guī)格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉與到的開發(fā)資源、測試資源、設計資源(包

3、括人員和軟硬件資源)；數(shù)據(jù)庫設計；系統(tǒng)設計；文檔(包括系統(tǒng)用例、Demo、測試用例等)；評審會議。設計階段結果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設計文檔(概要設計和詳細設計)/數(shù)據(jù)庫設計文檔等。該階段交付成果需要進行評審。3、執(zhí)行階段(開發(fā)和測試)準備開發(fā)環(huán)境、測試環(huán)境。跟蹤，推動項目按計劃進行。項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。測試階段BUG響應與改進、收集反饋意見。對項目風險進行管理。4、發(fā)布階段包括制定項目發(fā)布計劃，用戶培訓，發(fā)

4、布上線。5、試運行階段數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問題，與時進行處理，改進性能問題，特定情況執(zhí)行補丁升級。6、收尾階段產品交付，項目總結會。常見問題1、開發(fā)時間的估算制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發(fā)任務中模塊的分配和時間估算，在公司現(xiàn)有的技術框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務邏輯實現(xiàn)上。通常單個模塊開發(fā)時間取決于以下因素：1、負責模塊的業(yè)務邏輯的復雜程度。2、開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。3、模塊技術實現(xiàn)上是否存在難點，所謂的技術難點定義是：在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身未沒接觸過的技術。對

5、于這樣的難點，開發(fā)者沒有相關的代碼可以參考，自己也沒有經驗，所以需要投入學習時間用于研究解決。模塊分配和開發(fā)時間估算的步驟：1、在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發(fā)時間。2、召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，分配給開發(fā)人員，如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動性和參與性。分配模塊的時為確保開發(fā)的速度和質量，基本原則如下：A、類似的模塊由同一人負責開發(fā)，比如用戶信息的增刪改應由同一開發(fā)者負責。這樣開發(fā)者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現(xiàn)的缺陷概率。B、技術難度較大的模塊由技術

6、水平比較高的人負責。C、業(yè)務邏輯比較復雜的由對業(yè)務邏輯比較了解的人負責。3、模塊分配完成后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中應與開發(fā)者討論每個模塊的技術實現(xiàn)細節(jié)，使時間的估算更加準確。4、對開發(fā)人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開發(fā)人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為8-24工時，消除時間周期較長的任務，避免不確定性影響項目的進度。2、CodeReviewCodeReview是保證項目中代碼質量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴往往是測試后出現(xiàn)大

7、量bug的主因，有時甚至導致返工；關于CodeReview執(zhí)行，首先應有編碼規(guī)和代碼審查規(guī)。通過這兩個文檔來規(guī)開發(fā)人員的代碼實現(xiàn)，代碼編寫者必須要嚴格按照規(guī)來進行；代碼審核者根據(jù)這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。CodeReview一般可按以下步驟實施：1、 檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)。2、 從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。3、 代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug，對這些bu

8、g記錄在案。4、 代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發(fā)現(xiàn)的問題與修改建議，提交給相關人員。5、 代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。6、 代碼編寫者bugfixed完畢之后給出反饋。7、 代碼審核者把CodeReview中發(fā)現(xiàn)的有價值的問題更新到"代碼審核規(guī)"的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術人員。3、需求變更管理需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需

9、求變更管理的有效性將直接影響項目的成功與否。對待需求變更的正確態(tài)度：1、需求變更是不可避免的。2、需求變更要必須被管理。3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。需求變更管理的目標：1、相關的干系人必須清楚地了解發(fā)生的變更。2、變更處于有效的管理中。3、盡量降低變更帶來的風險。通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。需求變更流程：1、確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任何需求改變，都需要走需求變更流程。2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理

10、、市場人員、開發(fā)人員、測試人員等。3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以與對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。4、需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。6、相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關容。測試人員修改測試用例的相關容。開發(fā)人員修改代碼中的相關部分。7、按照變更后的計劃實施項目，并進行檢查

11、，跟蹤，對變更后的實施反饋和可能出現(xiàn)的問題與時溝通和處理。8、需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。4、風險管理影響項目成敗的因素涉與方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質量不達標等方面，常見風險如下：1、目標以與需求不明確為了市場競爭或部管理決策的需要，業(yè)務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾紙或口頭的傳達上，沒有正式的業(yè)務需求文檔，在沒有明確的需求圍的情況下，有時為了迎合業(yè)務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人

12、員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業(yè)務部門的認可。在項目的前期一定要采取相應的手段或措施，與業(yè)務部門共同明確項目目標、需求圍，充分考慮現(xiàn)有的時間和資源約束，將需求排定優(yōu)先級，對于關鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。2、項目目標擴大以與需求變更在有了明確的目標和需求圍的情況下，需求的變更還是不可避免的，業(yè)務部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產生，如果不對此加以控制，新的需求的加入通常會影響

13、已實現(xiàn)的需求，并且對項目進度和成本產生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析與評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求。前期的需求討論要詳細、充分。需求文檔中需求的圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產品經理、相關職能主管、客戶)，所有的需求要經過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試

14、階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。3、代碼質量風險質量風險主要指開發(fā)代碼的質量。在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質量的影響很大。開發(fā)人員為了趕進度在比較緊的時間需要完成指定的任務，可能就存在很大的開發(fā)質量問題。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對指導開發(fā)非常重要。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題。這需要在項目實施過程中采取有效的措施來規(guī)避風

15、險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發(fā)現(xiàn)架構設計問題；管理評審，通過組織級的質量審計看產品以與實施過程是否滿足質量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠與時發(fā)現(xiàn)相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。4、人員技能和資源的不足項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，

16、但一個新手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術以與相應的人員技能要求，針對不同的角色，與時采取相應的技能培訓，以保證項目的順利實施。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。5、缺乏良好的團隊協(xié)作軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產，各模塊最終要集成在一起形成一個有機的整體，這就需

17、要各小組之間的密切配合，界定清楚工作界面與接口關系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。6、項目會議組織會議是項目執(zhí)行過程中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。不成功的會議通常表現(xiàn)為如下形式：1、會議氛圍不好，參與者發(fā)言不踴躍；2、會議討論常常偏離主題；3、會議沒有取得預期的結果；4、會議時間常常一拖再拖。這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間

18、又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只是一個發(fā)表想法的人，他不用對會議的成功承擔責任。3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：1、只有需要開會時才開會。有時候兩三個人單獨小圍溝通會更加有效。2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。3、請對人很重要，