在一些大的軟體研發團隊中，普遍會採用cmmi、rup等流程模型來管理研發過程。這些流程普遍需要比較大的管理開銷，在大型研發團隊中，可以設定專人來 負責相關的工作。但對於一些小型的研發團隊來講，不可能抽出時間和人力應對如此大的管理開銷。對於小團隊來講，生存壓力更大，軟體質量更為重要，從某種意 義上來講更需要一些有效的管理方法來保證軟體質量。象xp、scrum等敏捷方法正是給出了一些有效的實踐方法建議。在這裡，筆者結合多年的開發經驗，給 出一些經實踐驗證的，適用於小型開發團隊的開發管理實踐。
1. 使用具有web介面的版本控制工具
版本控制（version control）工具可以說是軟體開發團隊的必備工具之一。使用版本控制工具，能夠有效的協調程式設計師之間的**共享和協同工作。使用具有web介面的版本 控制工具，更可以方便的進行code review。版本控制工具在具有web介面的基礎之上，一定要支援專案歷史的記錄和檢視。因為，在乙個真實的開發團隊中，僅僅關心某個檔案的版本和歷史，其意義是不大的，無論是專案管理者和團隊內的成員，都會關心專案的發展和演進歷史。在版本控制工具中，專案歷史一般是以"changeset（變更集）"的方式出現的，乙個變更集一般代表一次提交歷史記錄，可以包含多個檔案的版本變更。
支援web介面，並具有專案歷史管理能力的工具有：
fisheye: http://www.atlassian.com/software/fisheye/default.jsp 可以檢視svn、cvs的儲存庫。
viewvc: http://viewvc.tigris.org/ 可以檢視svn、cvs儲存庫。sourceforge.net就用它。
2. defect tracking
配置並維護乙個簡單的defect tracking系統對於開發團隊來說是非常必要的。測試員和程式設計師可以通過defect tracking工具很好的進行互動。測試過程中發現的bug不會被輕易遺漏，更改之後的bug會得到及時的檢驗；並且，專案管理者可以通過該工具得到有意義的軟體質量指標資料。
同時，defect tracking工具一般都具有簡單的任務管理功能，可以使用defect tracking工具進行簡單的任務管理，做到未完成任務的提醒。（如果有其他工具，可以把任務管理置於其他工具中。）
推薦：http://www.bugzilla.org/
3. 輕量級的需求和設計
建議使用scrum中的「專案」-「迭代」- 「user story」- 「任務」這一管理方式，xplanner 能夠很好的支援這一模型。
對於一般的資訊系統來講，開發過程是基於乙個已經存在的整體架構之上（j2ee、spring、struts等等，或是團隊內部的一套架構體系）。這樣，對於一般的功能來講，從需求開始直接進行編碼即可。對於一些關鍵模組的演算法和實現方法，可以在編碼之前，寫乙個簡單的設計文件，說明問題即可，同時有助於理清程式設計思路。
4. 保證穩定的build過程
每日構建也就是大家平時所說的daily build，nightly build。xp中的持續整合（continuous integration）也是這個宗旨。經常的執行構建，能夠有效的發現**間的問題，不會到專案後期被大量的整合問題搞得不知所措。程式設計師經常不更新本 地**，就直接修改程式，然後提交；經常還會把新新增的源程式檔案、第三方庫檔案忘記新增的版本控制中。諸如此類的問題，都可以通過每日構建和持續整合及 時發現並解決。
6. 在專案後期嚴格控制變更
到專案後期，專案經理和技術負責人要對每天提交到源**庫中的**進行嚴格的**審查（這時就能體會到版本控制工具支援專案歷史的好處了）。同時，對於要修改哪個bug，也好進行仔細的影響度分析。得到乙份穩定的**非常不易，任何乙個隨意的修改都有可能導致蝴蝶效應。
7. 專案組中的及時溝通
scrum的sprint planning meeting, sprint retrospective meeting, 和daily standup meeting是很好的交流方式，尤其倡議在專案中堅持使用daily standup meeting。但是交流不應僅侷限於會議，如果遇到需要交流的問題，隨時隨地進行面對面的交流。人和人之間面對面的交流，是im工具、email等交流方式所不能替代的。
8. 選擇合適的開發工具
「欲善其事、先利其器」。軟體開發團隊一定要選擇高效的編輯器及配套工具。編輯器要能支援自動匹配（auto complete），具有豐富的快捷鍵操作方式，具有足夠大的**可視面積。
9. 一定要有專門測試
無論專案多小，都要有專門的測試人員。程式設計師的單元測試是不可靠的。:-) 從理論上來說，程式設計師是要構築乙個系統，而測試員是要想方設法的摧毀這個系統，二者的思維方式、出發點是完全不同的，不能混為一談。如果是開發伺服器端程式，一定要做嚴格的壓力測試，切記；並給出單台伺服器能夠承受的併發訪問數量。
小團隊軟體開發
軟體開發是自己的本行,這裡談談對乙個小團隊開發軟體的幾點思考 1 每個開發人員要對所要開發的東西在開發之前就要有一定的了解,最好是在開始的時候就把需求問的詳細一些,不要對著乙個全是文字的東西談需求,最好用圖形來互動,做軟體的都有個體會,往往到自己把介面做的差不多了,給使用者一看,使用者馬上就補充了一...
git團隊使用實踐
git即版本倉庫。分為遠端倉庫和本地倉庫，將某個遠端倉庫分支想象為1，則所有同事開發的本地倉庫為n，那麼，遠端倉庫和本地倉庫為一對多的情況。git的命令基本都是給本地倉庫使用的，給遠端倉庫使用的命令，常用的就是，關聯遠端倉庫 刪除遠端倉庫 拉取遠端倉庫 推送到遠端倉庫。遠端倉庫需要保證問題，所以，不...
WEB類開發小團隊構建篇（一）
年過30一直都在小企業裡混，時常會覺迷茫30已過，而自己仍舊只是小公司裡混混。每個人的近況不同，所以考慮的東西也大有不同，總的回想自己從業的這幾年，也有些許東西可以拿出來分享，沒有對錯，只是覺得這樣做更好點吧。先說說基本經歷吧，大專畢業後公升本科，算不上流的本科院校畢業，出來後從事.net開發工作，...