【文章內容簡介】 要的人召來開會，當然也不要漏掉那些關鍵人物。在確 保必要人物都在的情況下一次會議參與者越少效果越好。提前預約參與者的時間，以確保他們能按時到場。會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調會議的目標，我們來做什么。B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論 如何做上面。C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人 的講 話，等別人說完你再說等等。會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍 是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成 果之一。會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。會議后別忘發(fā)會議紀要，以及一些 Action，什么人什么時候做什么。會議后的 action 執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知 了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性 也會降低。很多會議往往都不注意這一點。1按時結束的會議會受到所有人的歡迎。版本控制 版本控制也是項目管理者的一個重要工作內容之一，一個項目或產品的完成不可能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布 版本等）。需要做好版本的管理和控制。項目總結 在項目完成后，總結整個完成項目的過程和經歷，為下一次的項目啟動提供參考經驗，完善不足，避免在類似的項目中出現可能存在的相同的錯誤發(fā)生。第二篇：軟件開發(fā)項目管理（范文）管理目標所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(內部/外部客戶，內部/外部合作伙伴，經銷商/客戶等)。項目管理三要素平衡（時間/成本/質量），即開發(fā)項目按需按時按質的完成。目標：功能滿足需求，設計支持變化，開發(fā)快速迭代，成果持續(xù)交付。執(zhí)行概述建立有效的工作流程保證項目的順利進行，初期使用傳統(tǒng)RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現敏捷開發(fā)全流程管理。明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。跟蹤設計/開發(fā)/測試/回歸/發(fā)布全流程，推動項目按預定計劃執(zhí)行。解決項目過程中出現的問題和沖突，一般集中在需求不明/工作量或時長/開發(fā)難度/跨部門協(xié)調等幾個方面。調動開發(fā)團隊的積極性，創(chuàng)造力，推動團隊成員在項目過程中的學習成長。風險識別、風險控制以及風險的預案。項目管理需求階段對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目范圍、功能及優(yōu)先級。組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。設計階段根據確認后的軟件需求規(guī)格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉及到的開發(fā)資源、測試資源、設計資源(包括人員和軟硬件資源)；數據庫設計；系統(tǒng)設計；文檔(包括系統(tǒng)用例、Demo、測試用例等)；評審會議。設計階段結果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設計文檔(概要設計和詳細設計)/數據庫設計文檔等。該階段交付成果需要進行評審。執(zhí)行階段(開發(fā)和測試)準備開發(fā)環(huán)境、測試環(huán)境。跟蹤，推動項目按計劃進行。項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。發(fā)布階段包括制定項目發(fā)布計劃，用戶培訓，發(fā)布上線。試運行階段數據監(jiān)控(日志、服務器狀態(tài))，根據監(jiān)控出現的問題，及時進行處理，改進性能問題，特定情況執(zhí)行補丁升級。收尾階段產品交付，項目總結會。常見問題開發(fā)時間的估算制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發(fā)任務中模塊的分配和時間估算，在公司現有的技術框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務邏輯實現上。通常單個模塊開發(fā)時間取決于以下因素：負責模塊的業(yè)務邏輯的復雜程度。開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。模塊技術實現上是否存在難點，所謂的技術難點定義是：在現有系統(tǒng)中還未實現的、開發(fā)人員自身未沒接觸過的技術。對于這樣的難點，開發(fā)者沒有相關的代碼可以參考，自己也沒有經驗，所以需要投入學習時間用于研究解決。模塊分配和開發(fā)時間估算的步驟：在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發(fā)時間。召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，分配給開發(fā)人員，如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動性和參與性。分配模塊的時為確保開發(fā)的速度和質量，基本原則如下：A、類似的模塊由同一人負責開發(fā)，比如用戶信息的增刪改應由同一開發(fā)者負責。這樣開發(fā)者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現的缺陷概率。B、技術難度較大的模塊由技術水平比較高的人負責。C、業(yè)務邏輯比較復雜的由對業(yè)務邏輯比較了解的人負責。模塊分配完成后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中應對開發(fā)人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開與開發(fā)者討論每個模塊的技術實現細節(jié)，使時間的估算更加準確。發(fā)人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為824工時，消除時間周期較長的任務，避免不確定性影響項目的進度。CodeReview CodeReview是保證項目中代碼質量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴往往是測試后出現大量bug的主因，有時甚至導致返工；關于CodeReview執(zhí)行，首先應有編碼規(guī)范和代碼審查規(guī)范。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現，代碼編寫者必須要嚴格按照規(guī)范來進行；代碼審核者根據這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。CodeReview一般可按以下步驟實施：檢查開發(fā)者的代碼實現是否遵循了編碼規(guī)范。從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現隱藏的bug，對這些bug記錄在案。代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發(fā)現的問題及修改建議，提交給相關人員。代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。代碼編寫者bugfixed完畢之后給出反饋。代碼審核者把CodeReview中發(fā)現的有價值的問題更新到“代碼審核規(guī)范”的文檔中，對于特別值得提醒的問題可群發(fā)給所有技術人員。需求變更管理需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需求變更管理的有效性將直接影響對待需求變更的正確態(tài)度：需求變更是不可避免的。需求變更要必須被管理。積極發(fā)現引起變更的因素，促使變更盡可能早的出現，減低變更帶來的風險。需求變更管理的目標：相關的干系人必須清楚地了解發(fā)生的變更。變更處于有效的管理中。盡量降低變更帶來的風險。通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現上述的目標。需求變更流程：確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任項目的成功與否。何需求改變，都需要走需求變更流程。項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理、市場人員、開發(fā)人員、測試人員等。項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關內容。測試人員修改測試用例的相關內容。開發(fā)人員修改代碼中的相關部分。按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現的問題及時溝通和處理。需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。風險管理影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現在進度延后、成本超支、質量不達標等方面，常見風險如下：目標以及需求不明確為了市場競爭或內部管理決策的需要，業(yè)務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業(yè)務需求文