NO IMAGE

      在從事開發時,往往思考的是具體開發問題,如何提高程式碼質量,如何加快開發過程,將採用什麼新技術等等,偶爾也會以開發的角度思考專案管理中該如何如何;等到從事專案管理時,考慮的主要問題是如何按工期、高質量、快捷、低風險的完成專案開發,圍繞此主題,結合專案情況和以前的經驗,制訂出各種專案管理的策略和計劃;下面,結合專案開發談談體會。

 

籌備階段

1.        召開專案誓師大會,討論形成一致共識;

在下達專案開發任務後,組織團隊成員召開討論會;通過介紹專案任務,引導大家一起討論專案改如何進行,暢所欲言,傾聽意見和建議,最終形成一致共識;這樣做的目的:一是讓團隊提前進入專案狀態;二是調動團隊對專案的積極性;三是達成專案過程中一些基本原則,比如嚴格服從開發管理、所有問題都是團隊的問題等等。

 

2.        對團隊成員的性格有個基本瞭解;

對成員性格瞭解後,有利於彼此交流,有利於開展工作,可減少交流中的衝突點。

 

3.        專案經理要向團隊闡述自己的做事方式方法;

比如,開發中遇到重大問題,要提出來大家一起商量解決。

 

4.        對團隊成員的技術水平有個基本的把握;

這點非常重要,專案開發過程中採用技術含量高低,就來源於這裡,比如Hibernate技術,如果團隊成員有1/2熟練運用,且專案經理包括在內,就完全可以採用此技術;另外,通過對技術水平的瞭解,在專案開發時可以有個側重點,對技術水平低的多些關注,技術高的也可以幫助解決問題。

 

5.        明確要求的事必須不折不扣的執行;

在專案開發過程中,會要求團隊執行各種標準、開發要求等,這些都必須得到徹底執行,才能最大限度提高軟體的質量。

 

需求階段

6.        開會整體介紹、討論需求,分配開發模組;

 

7.        各自閱讀需求文件,列出疑問點;開會討論,列出剩餘疑問,提交業主或需求人員;

以上是本人理解需求的基本思路,屢試不爽。

 

8.        此階段測試人員必須介入;

測試人員提前理解需求,對測試工作非常有幫助,儘快制訂測試用例,編寫測試計劃,提高測試質量;另外,如果現在不介入,等到提交功能測試時,再理解需求,就影響專案進度,而且費時費力。

 

9.        需求階段必須實現對需求至少60%的理解度;

通過6、7兩種方式,實現這個目標問題不大。

 

設計階段

10. 要求開發人員書寫部分詳細設計文件,包括程式結構圖、IPO圖(輸入、處理、輸出)、演算法、資料流程圖、操作流程圖、系統頁面設計等等;

這樣可以進一步加深對業務的理解,需求理解度達到80%以上;從開發的角度,思考軟體的實現方式,明確業務流程等等,這樣在開發階段就可以專著於具體程式碼書寫。

 

11.    整理準備所有的Cell報表,要求加入輸入限制、公式等;

 

12.    要用陌生技術的開發人員,要及時閱讀相關資料,做好技術準備;

開發過程中,有時需要用到陌生技術,這時要給予相關人員一定時間來閱讀學習。

 

13.    原則上統一設計資料庫模型;

這樣做目的是規範資料庫的設計,統一標準,統一模型,統一部署;如果資料庫設計量較大,可以允許開發人員單獨設計,但要嚴格遵循設計規範,設計完交資料庫工程師(或專案經理),確認方可部署到庫裡;經驗證明這樣做可以避免很多問題,比如資料庫設計混亂,資料庫版本混亂。

 

14.    此階段需要開發人員做許多工作,要加強監督檢查,以保質保量的完成工作;

對於工作內容安排,開發人員必須絕對的支援和執行,不能打折扣或者跳躍工作內容,讓做這個他做那個。

 

開發/測試階段

15.    在開發前期統一開發工具;

開發工具統一非常重要,可避免很多潛在的問題,比如由於JDK版本不同,導致整合版本後無法正常執行,Tomcat版本不同也會如此;開發工具統一如下“JDK1.4 Eclipse3.1 MyEclipse4.1 Tomcat5.0 SQL Server2000”。

 

16.    商討將要運用那些開發技術(Struts、Ajax、Hibernate、Spring等);

採用技術的原則是團隊必須1/2成員會用。

 

17.    參考行業標準和實際要求,制訂詳細的程式碼書寫規範和程式碼結構要求;

通過規範要求可相對的提高程式碼質量,使專案更接近一個人開發出來的,增強程式碼的可讀性,最重要的是增加程式碼的可維護性,長期來看降低了專案的風險性,從公司發展上看,有利於技術的沉澱積累。

先開發部分程式,然後一起閱讀部分程式碼,檢查程式碼規範執行的情況,包括類和JSP;同時,也看看程式碼的書寫思路是否有問題,特別是書寫的結構是否規範等,現場解釋解決問題,最終完善出一套具體的程式碼書寫規範,以及程式書寫的結構思路規範出來,列如下:

a.類及方法都要有註釋;

b.方法中的變數和程式塊,要有註釋;

c.頁面也要有註釋,比如頁面所屬、JS方法註釋等等;

d.每次頁面動作只能建立一次資料庫連線並用完及時關掉;

e.資料庫連線取得、使用、關閉的程式塊,得按照制訂的模式書寫;

f.對資料庫進行新增、修改、刪除操作時,一定要運用事務機制(系統底層已經封裝,注意呼叫就可以實現);

g. 在構架每次頁面動作的業務類時,要嚴格按照MVC的結構書寫,同時完全運用Struct思想;

h. 對於異常的報出,呼叫公共類,輸出相應”類名、方法、說明”;

i. 頁面上不允許做任何的訪問資料庫或業務操作,只可以顯示、獲取資料;

注意呼叫一些公共類,可以減少工作量,也使程式模組化,比如”專案列表” 、”標段列表” 、”編制範圍”的生成程式等等。

 

18.    與測試組交流,商討專案測試目標,瞭解測試報告和測試用例準備情況;

 

19.    部分模組開發完成,馬上提交同步測試,對測試問題及時進行修改;

 

20.    注意對測試問題的累加、分類,及時進行復測;

 

21.    定期開會一起討論測試問題,找出問題出現的原因,及時調整開發方式,加強工作細心態度,爭取類似的問題不再出現;這樣可有效的降低BUG出現率;

 

22.    積極協調開發進度,協調好開發與測試的關係;

在軟體開發中,開發與測試是最容易產生矛盾的雙方,但是他們協調工作的效果高低,直接影響專案軟體的質量;專案經理要營造一個良好的工作氣氛,當出現矛盾時,及時的協調化解,推動測試進度。

 

23.    開發人員遇到難解問題時,要及時幫助解決,困難的開會商討,千萬不能積壓問題,因為這往往是關鍵點問題,不解決會極大的影響開發進度;

 

24.    每週都要開會了解開發進度情況,及時把握專案進度,做到心中有數;

 

25.    要多協調、多商議、多交流,充分調動大家的積極性;

 

釋出階段

26.    書寫詳細釋出說明文件;

 

團隊建設

27.    考慮問題以成員為出發點,維護他們的基本利益,幫助做好輔助工作;

 

28.    可以不定期的組織茶話會,聊聊天,釋放工作壓力;

 

29.    與成員一起尋找利益的共同點,建立共同的價值觀,才能最大限度的凝聚力量,發揮主觀能動性;

 

30.    對成員要求不能急於求成,要循序漸進,共同進步;在不斷的歷練中,提高團隊的工作效率;

 

31.    採取民主集中的原則,用集體的力量解決問題;

 

以上就是本人在專案過程中一些體會,對於一般公司專案經理往往需要身兼數職,比如構架、設計、管理、協調等,所以專案涉及的方面比較複雜;如果簡單的從專案出發,關注點是如何保質保量、低風險的完成專案任務;但是經過數個專案後,才發現專案不是最重要的,重要的是團隊建設和公司產品技術的積澱,在專案開發過程中形成一支高效的團隊,經過幾個專案的磨合,團隊的開發效率將得到極大的提高,公司產品技術得到有效累積,這時專案只是團隊工作過程中的積澱的產物而已;不過有個問題,往往公司的開發人員是隨機組合的,對此可採取相對穩定團隊,保持團隊的基本構架不變即可。