軟件項目管理的有效模式研討

前言：想要寫出一篇引人入勝的文章？我們特意為您整理了軟件項目管理的有效模式研討范文，希望能給你帶來靈感和參考，敬請閱讀。

每天早上前10至15分鐘，大家一起站到任務看板前進行立會。立會中，每人發(fā)言。發(fā)言的內容主要有三個方面：總結前一日的工作；反映前一日工作中遇到的問題，必要時，TeamLeader需要安排人協(xié)助；承諾今日的工作內容。承諾很重要，它會給開發(fā)者帶來“必須完成”的壓力。

任務看板上主要分為兩塊：左側用于張貼任務條，分為計劃中的任務、進行中的任務以及已完成的任務；右側繪制燃盡圖，反映進度情況。所有的工作項都寫在紙片上并貼到任務看板上，每日立會時需要對首任務看板講解，同時任務看板上能夠一目了然的反映出各項工作的進展。見圖3。所有的工作項，都應該在TFS中立項。這樣便于工作的跟進，以及開發(fā)人員之間的協(xié)作，另外，也有利于工作量的統(tǒng)計。

控制與糾偏

（1）TFS持續(xù)集成。我們將TFS的集成模式設置為持續(xù)集成，生成的結果將會立即返回給提交者，以保證服務器上的代碼是最新的、可用的。

（2）工作項細分。每項工作要細分為2～16h。較小的工作項，便于跟蹤并及時精準的調整進度。實踐經(jīng)驗證明，工作項細分之后，相比寵統(tǒng)的工作項，更能夠有效的保證進度。

（3）每工作項時間點檢查。每工作項進行到預估時間一半的時候，TeamLeader應檢查執(zhí)行情況。如果此項工作進展不順利，要分析原因，或安排人員協(xié)助，或改變技術方案，及時調整進度。（

4）經(jīng)常性的演示，及時發(fā)現(xiàn)問題。安排盡可能多的演示，目的有二：第一，讓用戶、領域專家參與到開發(fā)過程中，避免開發(fā)人員迷失在代碼叢林中；第二，誰做的工作誰演示，這會緞帶演示者“演示成功”的壓力，從而做好做細工作。

（5）推行代碼審核制度每天工作快結束時，留下約15分鐘的時間，相互之間進行代碼審核。建議不要固定某兩位互審，而采用交叉循環(huán)的方式。

（6）最有效的溝通方式：面對面+白板。技術討論或工作安排時，把相關人員一起叫到白板前，邊解說，邊繪制草圖，這種方式是十分有效的。不建議大家采用文檔的方式進行溝通。

（7）技術總結文檔十分重要。把個人的經(jīng)驗總結寫成文檔，可以供團隊其它成員，以及后來的成員學習，從而讓大家都掌握。另外，有些問題的解決過程比較復雜，如果能夠把其形成文檔，可以依照此文檔即可解決相同的問題，這樣可提供工作的效率。

團隊建設

（1）不定期的培訓。條件許可時，可以參加培訓機構舉辦的培訓，或者邀請培訓老師到公司來進行培訓。即使條件不允許，我們也可以進行內部培訓。TeamLeader可以組織開發(fā)類、專業(yè)類及測試類的專題講座，也可以請團隊成員各自講授自己所善長的技術。

（2）經(jīng)常鼓勵團隊成員。當團隊中某成員工作上取得了突破，或攻克難題時，大家都給他（她）祝賀，不一定非得物質上的獎勵，其實，即使發(fā)個郵件、拍拍肩膀等方式，也可以取得很好的效果。

（3）優(yōu)先考慮團隊總體進度。對于新工作的成員，往往只想到把自己的工作及時完成了，保證了自己的進度就好了。其實這是不夠的，團隊的進度才是第一位的。團隊總體進度，往往卡在進度最慢的成員那里。所以大家要及時協(xié)助遇到困難的同事，這一點上，TeamLeader尤其要有表率作用。

（4）雙向溝通優(yōu)于單向溝通。交待工作時，最好采用協(xié)商討論的方式進行，讓接收者也盡可能發(fā)表自己的看法，不要強制性分派工作。（本文作者：陸中元 單位：中國建筑科學研究院深圳建研軟件有限公司）