項目開發中如何提升團隊的戰力？

前言

曾有1些好友和同事問我： 伴隨著團隊人數的增加，怎樣樣能讓全部團隊的產出是 1+1 >2？ 最少也是 1+1 = 2 。

結合我本身的1些角度和經驗，我給出了我的1些想法和做法。

(這里的角度是從實際開發中合作的角度來斟酌的，提升薪資1般能在很大程度上提升戰力 ^^, 這個不在本篇的討論范圍)

1. 統1團隊的“語言”

之前看過1本書， 書中說了這樣1個寓言-- “巴比倫通天塔”

內容大概是：人類希望能聯合起來建立通往天堂的高塔。為了禁止人類的計劃，上帝讓人類說不同的語言，令人類相互之間不能溝通，計劃因此失敗，人類自此各散東西。

這里的統1的團隊“語言”，只的是環境和編碼上的1些習慣和規定。細部可以是：

1. 統1的規格文檔

項目不管多少人做，規格文檔總是需要的， 只是情勢和標準上會有1些不同。

比較小的項目， 人比較少， 可以斟酌在 Wiki 上來寫規格。情勢也可能比較隨機。 但是對觸及人數比較多， 項目較大的狀態，規范的規格文檔就會比較重要。SA, SD , AP, QA 都需要能看得懂。 規格同樣成為大家交換語言的"教材"。 設計1個好的規格文檔的模板也就相當重要。

2. 統1的集成開發環境。

對 Java 開發者來講，Eclipse 是個還不錯的選擇。 固然你也能夠選擇 IntelliJ IDEA。 但是對開發同1項目的團隊來講，大家1定要選擇同1套。

對各種IDE工具來講，優點應當是各有千秋，選擇1個最合適項目，合適團隊的。這個工作可以在項目進入開發階段時大家1起挑選。

3. 統1的開發環境

開發人員常見的開發方式 1種是在本地建立個人開發環境進行開發， 另外1種是在1臺共用的服務器上建立個人開發環境進行開發， 使用代碼控管工具(P4 or Git)進行代碼的獲得或提交。

不論是哪一種，常常會有以下狀態產生：

1) 新加入member請老員工查看本地開發遇到的問題

2) AP 1 請AP 2 在AP 1 上查看AP 2 寫的Code 的問題

3) 大家1起在某臺機器上會診某個問題

如果每一個開發人員的開發環境相差甚異，必將會浪費1些沒必要要的熟習環境的時間。 所以， 統1大家的開發環境的路徑，開發項目名稱，統1的部署測試腳本也就不無裨益了。

4. 統1的編碼規范

衍生統1的開發環境， 團隊成員使用統1的代碼規范， 像代碼文件路徑，文件命名， 類的命名， 方法命令，變量命令，參數命令都能統1的話， 彼此之間熟習代碼就會比較快，保護和更改也就方便了。

2. 共用功能組件的宣揚，推行

1般項目的設計與開發中， 必不可少的總有共用模組的存在。(如果沒有，就要反思1下了)。

共用方法， 共用類， 共用模塊。 總有1些部份是可以提取出來供團隊來使用的。除方便其他人，加快開發速度。

相對每一個人都寫1套類似的東西，花比較少的時間來提煉，錘煉共用的功能部份，使共用的部份無毛病，高效力，對提示項目的質量也大有好處。

但是，共用組件的提取和宣揚是需要有專門的意識和計劃的， 相對單個開發人員來講， 完成了既定功能的開發，是時間要求很緊的狀態下，他個人是沒有精力也不想花額外的時間去做共用化的，更別說宣揚和推行了。

固然， 即便共用的組件也不能從共用后就不再變化了， 功能完善與升級也是需要相應的途徑的。

簡言之， 以生命周期的方式來管控和保護共用組件。 從計劃，到實行，到銷售，到更新升級，到Release .... .

3. 代碼質量保證

1個團隊要做正確的事，要正確的做事， 在統1"語言"以后，是很有計劃達成 1+1 >2 的效果。 但是1定要確保正確的做事，同理之，如果某個成員制造了1個Bug, 影響的不但是他自己， 毛病一樣也會出現 1+1>2 的狀態。

所以，每一個人代碼質量都要盡可能有保證。

自動代碼Check,  定期的Code Reviewer, 結對編程都不失為1種好的做法， 一樣，選擇合適團隊的狀態的方法就能夠了。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈