提高小團隊軟體品質的一點想法

聽了北京INTETA第三次活動的講座以後，最近對一些開發過程中的品質控制相關的東西感興趣，找了NUnit、NAnt、Draco等等相關的資料看了看，雖然都沒有深入瞭解，不過對於目前公司的開發流程的改進有了一些新的想法。

按照我的想法，對於我們目前的團隊規模（項目都很小，一般就是2、3個人，最多的時候是5個人），開發流程可以這樣做：

1. 需求調研：是一個重點，雖然不至於要搞得非常清楚，但是對於要實現的商務程序、客戶的具體需求是一定要搞清楚的；目前的幾個項目都在這上面吃了大虧，甚至於由於設計無法修改而推翻重來，成本極高。
2. 設計：鑒於團隊的規模，不可能有專門的系統分析人員來做這項工作，因此需要大家協商進行系統的初步設計——沒有諸葛亮就只好多上幾個臭皮匠；設計過程中可以使用一些UML工具，也可以就用最原始的白紙加鉛筆；設計過程除非非常明確，否則不用優先考慮改採取什麼樣的模式，可以在以後以重構的方式來改進；設計不需要細分到拿過來就可以寫代碼的程度，但是對一些主要的業務類要能夠確定下來；
3. 編碼：編碼應該以測試驅動的方式進行，以方便在修改過程中確保程式的正確，並且修改不會引入新的Bug；原始碼需要進行組態管理，SCM工具可以使用VSS，但是建議使用CVS，因為CVS允許並行開發；每天都要進行系統構建和單元測試（使用NAnt、NUnit等工具自動完成）；要求只有完成的代碼才能提交到SCM中，以保證組態管理系統中總是保持一份可以成功編譯通過的代碼。
4. 測試：在開發過程中引入測試驅動開發，因此單元測試基本上可以分散在開發過程中完成，並且對以後的修改提供了保護；整合測試和功能測試仍然需要安排專門的人員和專門的時間進行，具體怎麼做比較好還沒有好的想法。

暫時就想到這些，以後再補充。

最近還在忙PB，上面的這些東西感覺對於PB來說都不適用，這些流程好像都是給其他工具準備的，對於PB這種封閉的傢伙一點都用不上，該死的PB！