軟體專案管理論文
軟體企業的生產效率不僅僅取決於軟體開發過程中所使用的軟體開發思想和方法，還依賴於是否採用了高效的軟體專案管理技術。下面是小編為大家整理的，供大家參考。
範文一：軟體專案管理中的進度控制問題
一、軟體專案管理中的進度計劃編制
1.1進度編制方法的選擇
進度編制的方法是根據計劃的變化而變化的，其中關鍵日期的製表費用較低，需要的時間也比較短。而甘特圖則需要的時間和資金較高。與此同時，CPM還要將每一階段的活動日程進行分析，一旦活動的日程較多，超出了CMP的閾值，就需要計算機來計算出工期和路線，所以RT法是進度編制方法中難度最大、耗費時間最長的一種。所以專案組選擇哪一種進度編制方法，要從專案的規模、緊急程度來進行全面的分析。
1.2進度編制工具的選擇
進度編制的方法確定之後，就要對編制的工具進行選擇了。編制工具要具備輸入、核算工期、資源的成本預算、材料價格、計算人員資金需求等一系列因素進行分配，並最終形成成本預算的功能。在專案實施時，相關技術人員可以對每個資源或整個成本的預算進行比較，使用者對任務的開始和結束的時間、工期的估算、和各個任務的順序進行實時的監督和控制，在資源的使用方面，編制工具還可根據任務資訊的日程進行適當的調整，按照任務的要求對資金、人力、物力進行一系列的調整和配置。
1.3進度計劃的制定
進度計劃的制定也可稱為專案範圍的制定。對專案過程中的一系列活動、責任和組織結構進行定義。WBS是範圍定義組織架構。WBSWorkBreakdownStructure可以將專案產生的各項任務按照樹狀圖的走勢一樣一級一級向下層的管理單位分配任務，所以這也進一步的對進度的計劃制定提供的堅實基礎，併為其劃分出了工作範圍。
二、軟體專案管理中的進度計劃實施
專案的實施計劃需要得到技術人員和使用者的一致認可。當專案得到認可並公佈後，相關的人員就可按照原定計劃進行實施。在實施的過程中，技術人員應在不斷的實踐中發現問題和解決問題，在這裡我們提倡採用走動式的管理方式，專案組應該根據不同人員的不同技術型別才實施相應的跟進措施。
1針對自身能力較弱，沒有較強的完成願望的人員要採取命令式的跟進方法。因為這些人員普遍技術能力不強，但對工作又不主動，不能按時完成上級交給的任務要求，就必須要採取強制性的態度。
2針對一些有較強工作熱情但完成的能力比較低的人員要採取說明的管理方式。因為這些人員很可能是新人，加入到一個新的環境或工種中，由於之前沒有設計，欠缺一定的技術經驗，但其自身的工作熱情又較高，具有完成任務的決心和信心，針對這類人我們就要有足夠的耐心來逐漸引導，併為其提供相關的理論經驗，命令下達時要詳盡，不能有所遺漏，一旦完成相應任務時還要給予相應的支援和鼓勵，提高其自信心。
3針對一些能力較強但任務完成的願望較低的人員要採取說明式的跟進方式。因為這些人員普遍都是技術組中的老員工，具有一定的技術和驚訝。完全有能力來完成上級交給的各項任務。但由於其自身的原因，往往存在工作熱情不高，完成任務的願望不夠主動。所以就需要我們隨時瞭解其想法，多進行溝通和交流，給予其一定的空間和時間，讓其自由發揮，不應過分約束。
4針對一些能力較高而完成任務的意願也較高的人員應採用授權式的跟進方式，專案的管理人員要適當給予其一定的決策權和管理權，在一些重要的環節上給予監督。
三、軟體專案管理中的進度計劃的控制
軟體專案的進度控制最終實現的目標就是軟體需求。在需求不明確的情況下，軟體工作的開展是不能夠進行的，所以軟體專案的管理第一個要求就是有可靠的需求。軟體的進度控制不但要取得相關人員的高度認同，還要具有明確性和可操作性，進度控制按常態可大致分為以下幾點：計劃PLAN、執行DO、審查CHECK和行動ACTION，簡稱PDCA。相關技術人員應對進度控制中出現的各項差異進行正確的調整，一旦出現偏差時，要及時對其產生的後果進行預計，及時調整計劃方案，儘可能的降低其執行風險，正確分析專案中出現偏差，最好利用網路中的總時差和自由時差來進行正確的判斷和規劃。
範文二：軟體專案管理的有效模式研討
每天早上前10至15分鐘，大家一起站到任務看板前進行立會。立會中，每人發言。發言的內容主要有三個方面：總結前一日的工作;反映前一日工作中遇到的問題，必要時，TeamLeader需要安排人協助;承諾今日的工作內容。承諾很重要，它會給開發者帶來“必須完成”的壓力。
任務看板上主要分為兩塊：左側用於張貼任務條，分為計劃中的任務、進行中的任務以及已完成的任務;右側繪製燃盡圖，反映進度情況。所有的工作項都寫在紙片上並貼到任務看板上，每日立會時需要對首任務看板講解，同時任務看板上能夠一目瞭然的反映出各項工作的進展。見圖3。所有的工作項，都應該在TFS中立項。這樣便於工作的跟進，以及開發人員之間的協作，另外，也有利於工作量的統計。
控制與糾偏
1TFS持續整合。我們將TFS的整合模式設定為持續整合，生成的結果將會立即返回給提交者，以保證伺服器上的程式碼是最新的、可用的。
2工作項細分。每項工作要細分為2～16h。較小的工作項，便於跟蹤並及時精準的調整進度。實踐經驗證明，工作項細分之後，相比寵統的工作項，更能夠有效的保證進度。
3每工作項時間點檢查。每工作項進行到預估時間一半的時候，TeamLeader應檢查執行情況。如果此項工作進展不順利，要分析原因，或安排人員協助，或改變技術方案，及時調整進度。
4經常性的演示，及時發現問題。安排儘可能多的演示，目的有二：第一，讓使用者、領域專家參與到開發過程中，避免開發人員迷失在程式碼叢林中;第二，誰做的工作誰演示，這會緞帶演示者“演示成功”的壓力，從而做好做細工作。
5推行程式碼稽核制度每天工作快結束時，留下約15分鐘的時間，相互之間進行程式碼稽核。建議不要固定某兩位互審，而採用交叉迴圈的方式。
6最有效的溝通方式：面對面+白板。技術討論或工作安排時，把相關人員一起叫到白板前，邊解說，邊繪製草圖，這種方式是十分有效的。不建議大家採用文件的方式進行溝通。
7技術總結文件十分重要。把個人的經驗總結寫成文件，可以供團隊其它成員，以及後來的成員學習，從而讓大家都掌握。另外，有些問題的解決過程比較複雜，如果能夠把其形成文件，可以依照此文件即可解決相同的問題，這樣可提供工作的效率。
團隊建設
1不定期的培訓。條件許可時，可以參加培訓機構舉辦的培訓，或者邀請培訓老師到公司來進行培訓。即使條件不允許，我們也可以進行內部培訓。TeamLeader可以組織開發類、專業類及測試類的專題講座，也可以請團隊成員各自講授自己所善長的技術。
2經常鼓勵團隊成員。當團隊中某成員工作上取得了突破，或攻克難題時，大家都給他她祝賀，不一定非得物質上的獎勵，其實，即使發個郵件、拍拍肩膀等方式，也可以取得很好的效果。
3優先考慮團隊總體進度。對於新工作的成員，往往只想到把自己的工作及時完成了，保證了自己的進度就好了。其實這是不夠的，團隊的進度才是第一位的。團隊總體進度，往往卡在進度最慢的成員那裡。所以大家要及時協助遇到困難的同事，這一點上，TeamLeader尤其要有表率作用。
4雙向溝通優於單向溝通。交待工作時，最好採用協商討論的方式進行，讓接收者也儘可能發表自己的看法，不要強制性分派工作。