團隊軟件開發管理

團隊軟件開發管理

摘自www.dbwin.com論壇中的發言

前幾天在互聯網上看到關于印度軟件開發的一個連續報道(中國軟件業的劣根性)，對印度和我國的軟件行業進行了全方位的對比。作為專業軟件開發人員，對我們目前團體軟件開發的現狀也有很多感觸，于是就形成了這篇文章，以下是筆者的管見，文章內容僅代表個人觀點，不適之處歡迎討論，以此促進中國軟件開發的發展。

一.開發隊伍與龍蟲問題有關嗎？

看看目前團體軟件開發的現狀，大家自然想到一個中國人是條龍，三個中國人是條蟲的說法，我認為大家只看到了軟件開發人員的協作程度不夠，而沒有看到開發隊伍的綜合素質?？梢灾赋龅氖?，在中國現有的程序開發環境下，大家看到的只是程序員之間誰也不服誰，難道就沒有人看到，因為這樣一種情況，每個人的基礎都很扎實嗎？中國需要發展符合自己國情的東西，包括程序開發環境。在這樣的環境下，我相信一定會有能夠河納百川的人物出現。

一個出色的中國人才是一條龍(僅從軟件開發角度，指能單獨開發出一個與眾不同的軟件產品)，而只有龍與龍合作才有可能不是條蟲。畢竟優秀的軟件開發人員是進行團體軟件開發的基礎，相信大家所處的軟件開發團體的開發人員有良莠不齊的現象，結果軟件的質量如何呢？不用問，很難達到預期的設計目標。開發人員除了有良好的技術素質以外，還要有團隊精神，多為總體著想，有不同的想法及時和負責人或其他人溝通，盡量避免開發思想不統一，開發步調不一致。

印度直接照班西方的模式，從來沒問為什么。這種方式確實在短時期內在商業利潤上帶來相當大的增長。除了這個以外，還有一些什么價值存在？印度因為發展晚，所以老老實實的先照辦西方的方法，難道中國也要這樣做嗎？請看看日本，學習西方的新技術新科技，確實也發展的比西方好，但是日本有過自己的創新嗎？沒有?。。?！

我覺得我們的（軟件開發水平的）發展是不足，但是不要因為這個就先自卑起來了。和印度想比，我覺得我們的劣勢是，大家的想法很多很雜亂，沒有一個統一的規劃。

我們的優勢是，我們嘗試了很多種不同的方法，就象是春秋戰國時期，諸子百家。在統一了思想以后所爆發出來的力量是將會是無比強大的。中國國內好的優秀的管理人才有幾個？軟件開發水平低和程序員又有什么相關呢？

二.開發規范 無規矩不成方圓

軟件開發要有軟件開發的規范，目前的情況是，開發前大家信誓旦旦，要按照軟件開發規范來做，實際開發過程中可能就有很多人開小差了，我行我素，置開發規范于不顧。開發規范包括文件對象的命名規范，菜單圖片的大小，變量定義的規則，代碼的書寫風格，總之要使軟件從外到內要有統一的風格，界面的一致性給用戶的是感覺是你的軟件上手快，讓用戶在不同的程序模塊中適應不同的操作風格，恐怕他們要叫苦連天；而代碼風格的一致性，則給項目組長或其他人員閱讀修改方便，當然注釋寫的要盡量詳細。這樣，起碼不會一個人員跳槽，此人負責的部分要重新寫的尷尬局面。還有大家要注意軟件和程序的區別，程序就是代碼，可以運行并完成既定的功能，而軟件還要有詳細的文檔說明。

程序員在這個方面缺乏自覺性，管理的水平方法也都不是很好。前面所說的開發規范其實是大家都應該知道的，我覺得問題出在對做這些事認識不足上，甚至有些公司上下都因為是軟件公司而自覺高人一等，從來都沒有從用戶和公司本身發展的角度去考慮

三.開發工具  工欲善其事，必先利其器

　　關于開發工具的討論經常見于各程序員論壇，結果針鋒相對，爭論不休，可見大家對開發工具的選擇還是比較迷惘，我的個人觀點是，其實語言只是實現特定功能的工具，選擇哪種語言要根據實際需要和個人的熟練程度而定，并沒有說哪種語言一定比另外一種語言好，正如，錘子就是比斧子好用，你聽著是不是很荒唐。有人說“VB只是幫助你入門的，還是學VC吧”，這觀點顯然過于偏激。由于各種開發工具采用的數據庫引擎不同，對某種數據庫的存取效率也有差別，有時甚至比較明顯，可以給大家舉個這方面的一點經驗，例如一個省的參加醫療保險人員的數據信息量很大，而且數據還要實時傳輸，應該算一個大型的MIS系統，我們選的是Sybase數據庫，假設時間很緊。如果用VB做開發工具，可能性能會差一些，顯然用PB做前臺開發可以體現速度上的優勢，而實時傳輸數據的部分可以用DELPHI來完成比較合適。做一些中小型的MIS系統呢，例如餐飲店的管理，采取VB,DELPHI等開發工具都是可以的，尤其是VB和DELPHI現在采用的ADO引擎，提高了數據庫訪問的速度，加上界面和其他功能上的優勢，做MIS程序也越來越方便了。歸根到底，預計模塊對數據庫的要求而定義出用什么語言最合適。

四.開發步驟

關于MIS軟件開發的步驟我認為比較合理的是(其他團體開發軟件的工程類似)：

1.初期業務調研

　　主要了解業務內容和業務流程，主要為做投標方案和無數據演示版軟件打基礎，這也是與開發產品軟件不同的地方，產品軟件往往僅實現特定功能，只需要很少的調研或根本不需要調研。

2.研究同類軟件

　　畢竟個人的思路是有限的，要集思廣益，可以相互討論，但找一些同類軟件來拓寬自己的開發思路是很重要的，當然，也不能局限于別人的軟件的界面和思路，跳不出別人的圈子。

3.做投標方案和無數據演示版

　　因為很快可能要參與投標，不妨把參與投標比喻成招親，你的演示界面好比人員的外包裝，界面漂亮，人家對你的第一印象就好，相信大家做菜單和窗口這些界面是很內行的，可以加一些圖片和小動畫，給人以清爽的感覺，無疑，花點時間做軟件的演示會給自己在競爭的實力上加個砝碼，而你的標書相當于你的談吐，是實力和能力的體現。

　　如果中標，無數據演示版軟件還有另外一個作用，就是讓一些領導視察提意見建議時給領導演示，因為是無數據演示，一般不會出現程序的錯誤。

4.詳細業務調研

　　這不同于初期業務調研的是要和用戶進行共同研究業務流程，寫出需求分析說明，一方面讓開發人員有個分析問題的過程，另一方面可以讓用戶確認需要那些功能，以免等開發出來后，用戶說哪些功能應該有，怎么沒有，到底用戶當時有沒有提出此要求，口說無憑，拿給他需求分析說明書看就行了。

5.總體設計

　　這當然是重中之重，直接關系到軟件的開發周期，開發效率和開發質量，所以要多花些時間，最好大家一起參與，仁者見仁，智者見智，以防疏一漏百，到時候再改，大家肯定都有類似教訓，總體設計做不好，結果數據結構重新調整時，大家很多汗水就白流了。行成統一的開發字典，人手一份，有改動時同時通知每個開發成員。另外要有一個盡量詳細的開發計劃，做到軟件開發有條不紊的進行。確定開發工具，詳細設計數據庫，文檔當然必不可少了。

6.系統開發

　　進行系統開發時，應該注意符合軟件的開發規范，鑒于文檔的重要性，寫程序同時應該把幫助文件的內容一起寫出來，因為此時考慮到很多處理方法，考慮的比較詳細，不要等軟件完成以后，再想如何寫幫助文件，茫然不知幫助該寫些什么，另外寫一些詳細的文檔可以防止自己以后看自己寫的程序時，自己都搞不清如何處理的，哪些地方該做修改的尷尬局面。寫的過程中要主要功能調試，不要以為我這樣寫代碼應該沒有問題，程序的隱患往往在不經意間發生。寫程序的過程中可根據實際情況，對開發計劃和系統設計做一些調整。

7.有數據測試并試運行

　　在拿給用戶之前，一定要進行系統的全面測試，可以到某相關單位進行測試，出現問題及時修正。保證拿給用戶的是確實能用的軟件，就一切OK了（后期維護的路其實還很長的:) ）。

　　行勝于言，團體軟件開發的成功會給我們帶來愉悅和幫助我們提高開發水平，這樣我國整體的軟件開發水平才能逐步提高，反之，留給我們的永遠是遺憾。

原文轉自：http://www.anti-gravitydesign.com