團隊軟體開發管理

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

　

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

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

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

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

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

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

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

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

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

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

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

四.開發步驟

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

1.初期業務調研

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

2.研究同類軟體

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

3.做投標方案和無資料示範版

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

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

4.詳細業務調研

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

5.總體設計

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

6.系統開發

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

7.有資料測試並試運行

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

　

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