提高小团队软件质量的一点想法

听了北京INTETA第三次活动的讲座以后，最近对一些开发过程中的质量控制相关的东西感兴趣，找了NUnit、NAnt、Draco等等相关的资料看了看，虽然都没有深入了解，不过对于目前公司的开发流程的改进有了一些新的想法。

按照我的想法，对于我们目前的团队规模（项目都很小，一般就是2、3个人，最多的时候是5个人），开发流程可以这样做：

1. 需求调研：是一个重点，虽然不至于要搞得非常清楚，但是对于要实现的业务流程、客户的具体需求是一定要搞清楚的；目前的几个项目都在这上面吃了大亏，甚至于由于设计无法修改而推翻重来，成本极高。
2. 设计：鉴于团队的规模，不可能有专门的系统分析人员来做这项工作，因此需要大家协商进行系统的初步设计——没有诸葛亮就只好多上几个臭皮匠；设计过程中可以使用一些UML工具，也可以就用最原始的白纸加铅笔；设计过程除非非常明确，否则不用优先考虑改采取什么样的模式，可以在以后以重构的方式来改进；设计不需要细分到拿过来就可以写代码的程度，但是对一些主要的业务类要能够确定下来；
3. 编码：编码应该以测试驱动的方式进行，以方便在修改过程中确保程序的正确，并且修改不会引入新的Bug；源代码需要进行配置管理，SCM工具可以使用VSS，但是建议使用CVS，因为CVS允许并行开发；每天都要进行系统构建和单元测试（使用NAnt、NUnit等工具自动完成）；要求只有完成的代码才能提交到SCM中，以保证配置管理系统中总是保持一份可以成功编译通过的代码。
4. 测试：在开发过程中引入测试驱动开发，因此单元测试基本上可以分散在开发过程中完成，并且对以后的修改提供了保护；集成测试和功能测试仍然需要安排专门的人员和专门的时间进行，具体怎么做比较好还没有好的想法。

暂时就想到这些，以后再补充。

最近还在忙PB，上面的这些东西感觉对于PB来说都不适用，这些流程好像都是给其他工具准备的，对于PB这种封闭的家伙一点都用不上，该死的PB！