筆者以自身實踐的場景為例，對團隊軟體開發的各個模式（初級，cmmi，敏捷）進行了分析和對比。並對如何提高團隊軟體開發的效率提出了自己理解。
團隊初級開發階段
團隊cmmi開發階段
團隊cmmi+敏捷開發階段
敏捷開發faq
場景1研究生導師王教授接到乙個企業資訊化的專案，是對一家中小型企業做一套產品資料管理的解決方案。
具體的參與人員：高博士，碩士：小馬，小趙，小李，小徐，小萬
馬教授 是行業專家，在企業資訊管理，研發流程優化上比較高造詣。
高博士：是研究企業研發資訊管理的博士，擔當專案經理的職責，主要負責客戶需求的落實和整個專案的計畫和分配，向王教授匯報專案和工作進展
碩士：小馬 負責整個技術框架的實現，並指導其餘研究生進行**編寫工作
小趙：負責 xx1 某模組功能實現
小李：負責 xx2 某模組功能實現
小萬：負責 xx3 某模組功能實現
高博士僅僅和客戶確定大方面的需求實現。
具體需求細節問題，沒有和客戶確認，需要在專案開發的時候和業務人員確認。
五名開發人員前期在客戶那裡辦公，具體把大致的需求制定了一下。因為客戶本身的資訊化經驗也不多，只能講乙個大概，所以待了不幾天就回去，整個專案開始啟動開發。
經過大概5個月的緊張開發和反覆修改，該系統上線，客戶可以基本應用。
客戶在使用專案和專案維護時期暴露出來的問題有以下幾點：
l 每個人的編碼風格不一致，介面風格不一致，異常機制不一致；
l 缺少公共的基礎類收集，很多類似方法重複被不同開發人員多次實現；
l 大家自己負責的那部分業務還比較熟悉，對其他人業務不熟悉，**只能本人維護。
l 團隊不穩定，小徐畢業，小楊接手，小楊看不懂徐的**，遇到客戶問題，只能自己重新編寫。
場景2：
某大公司**商關係管理開發
專案經理：王經理
開發人員：老湯，老李，大萬，大曹，小張，小馬，小陳，小紀
測試：小黃[兼]
dba：小劉[兼]
配置：小沈[兼]
這個團隊新畢業生比較多，新畢業生的特點是技術能力一般，比較容易規範和管理。公司研發流程比較正規，整個軟體專案開發採用cmmi3級標準作為研發指導規範。軟體開發過程中，對軟體開發流程規範，文件規範等要求比較高。
cmmi 規範要求按照崗位從事工作，比如編碼人員只能接受設計人員的工件，按照設計模型定義的方法在生成的**框架上進行編碼工作，不能從事設計工作。
這一點，對於剛剛畢業的新同事 有比較好的指導作用，因為有經驗的人員可以把比較成熟的技術，設計思路通過設計模型和文件傳遞到新同事那裡，避免新同事在初級技術水平下自由發揮。新員工也可以通過這種約束限制，對學習老員工成熟的技術解決方案，設計模型有比較深刻的體會。
另外由於新員工數量較多，採用cmmi的研發流程，對專案的組織和控制比較嚴謹，保證了專案實施的進度。
強調了文件傳遞的重要性，保證了新員工的工作的文件積累性，使專案成員的流失風險降低，使得大家按照文件的文件進行業務理解，保證了程式開發的有章可循。
體會
cmmi是給出所有可能需要考慮的點，如果專案開發團隊在專案管理和業務上，技術上缺乏經驗時，cmmi2級或3級是乙個比較好的管理參照方法，它可以基本保證專案的研發進度，降低了人員變更的風險。
缺點
l 文件太多，流程太多，研發效率有所降低，如果是以市場為導向的專案，可能會面臨成本的壓力。
l 因為關注點太多，**質量的核心地位下降。客戶要求業務需求快速變更和高質量的實現。但cmmi僅對流程可控和文件齊套***作用，它本身並不能提公升**的質量。**質量和效率提公升需要用別的手段進行保證。
場景3：還是上面那種場景，場景未變
z公司的待遇較好，兩年過去了，當初的新從學校畢業出來的學生都成了技術骨幹。原來老人帶新人的階梯式團隊，變成了技術水平差不多的平行式團隊。團隊技術差不多，且均為熟手，對當前系統的開發流程，編碼規範和架構設計比較熟練。並且在專案開發過程中可以與業務代表（業務人員）面對面溝通。
採取措施：
1. 交叉檢查。兩塊功能兩個負責人，每個人對各自編碼功能實現負責，同時對另外乙個人的功能點負責，交叉測試。
系統測試或正式上線出現問題後，兩人負連帶責任。這樣強制措施保證同一模組有兩人以上熟悉，避免人員流動對專案造成的影響。
2.功能內部的實現修改，開發人員自己作主。
當開發人員具有一定技術水平，被信任程度和責任心時，系統內部簡單功能的實現修改，開發人員可以直接與業務代表溝通，獨立完成，不需要別的人員參與，這樣可以保證專案開發的效率。
3. 強調技術積累和最佳實踐。
總結設計復用，**復用，**模版最佳實踐。大家共享知識，對新員工能力提公升有良好的幫助作用。
4. 增強關鍵文件
增加重要文件的審核和理解力度，比如軟體需求講解，概要設計講解，關注資料庫設計，主要類設計，對內對外介面設計，主要實現方式的講解。而類內部的具體實現可以交給開發人員自己作主。
5. 削減和裁減不必要的文件
削減和裁減不必要的文件，比如不必要的計畫文件，不必要的設計文件，不必要部署文件，減少重複的設計，減少無變化文件的版本公升級，對重複的設計可以自動生成模型等。
6. 關注和加強變化的文件，比如新架構的引入，新控制項的推廣等引起的文件變更。
敏捷開發人員並非不按規則或限制編寫**的特立獨行者。「牛仔編碼」是缺乏規則和管理糟糕的跡象，並且很不專業。顯然團隊專案開發的第一階段，所產生的問題，正是這種不規範釀成的苦果。
對於初級的團隊開發環境，強有力的規範化是很有好處的。因為很多初級開發者在接觸很多文件時，會很有牴觸心理。強迫按照一定的流程文件規範（初期流程和文件不能太多），堅持一段時間效果將逐漸顯現。
當團隊規模擴大時，初級的流程文件規範感覺不夠用的話，則進一步提公升cmmi的等級。
當員工個人技能提公升，專案趨於穩定，可以把大團隊分解為小團隊模式（不超過15人），進行區域性的敏捷推廣。如果效果不錯，則可進行大範圍推廣。
小團隊軟體開發
軟體開發是自己的本行,這裡談談對乙個小團隊開發軟體的幾點思考 1 每個開發人員要對所要開發的東西在開發之前就要有一定的了解,最好是在開始的時候就把需求問的詳細一些,不要對著乙個全是文字的東西談需求,最好用圖形來互動,做軟體的都有個體會,往往到自己把介面做的差不多了,給使用者一看,使用者馬上就補充了一...
高效軟體開發團隊
高效的軟體開發團隊是建立在合理的開發流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰 有效的計畫 協調和管理各自的工作以至完成明確的目標，高效的開發團隊具有如下特徵 1 具有明確且有挑戰性的共同目標 乙個具有明確的而且有挑戰性目標的團隊比目標不明確或不具有很大的挑戰性目標的團隊效率高得多，通...
軟體開發團隊階段
第1階段 家庭作坊 團隊成長之初，2 4名開發者在一處非商 用的場所工作。溝通和協調非常簡單，幾乎不需要管理。每個人都是全能的通 才。每個人的腦子裡也都裝得下整個公 司和產品的全部狀態資訊。這一階段，你是在建立並摸索一款具有 最低可靠程度的產品，或者說摸索自己 到底要做什麼。這時任何組織結構或過 程...