ericzhangali：

　　两位可能不太了解我的情况，我口才有限，觉得有些表达不清楚。呵呵。

　　我觉得可以理解成原型法的一个挖掘需求阶段，但又不完全是挖掘需求。

　　大致的过程是：

　　当接到一个新的客户时，我们按照他们要求的功能和UI大致做一个实现，砍到我们认为我们的solution暂时做不到的，或行为和我们的solution差别比较大的就劝说按我们的方式做。得到这个实现后，客户就不断地测试，递交bug list和需要修改的需求，我们就不断地给他新版本。

　　这个过程可能超过一个月，频率可能一两天或两三天就发出一个新版。同时我们自己的测试部门也做测试，发现的问题，优先处理严重的。直到客户觉得基本达到其要求，他才会量产、小批的给他的客户试用。然后反馈试用出的问题和需求，我们再做修改。这个频率一般不高。再然后，他才正式量产。

　　我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？

　　AlexLJM：

　　我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？

　　当然不算正式发布，顶多算个验收测试。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期。

　　鹿鸣：

　　现在规模软件开发，重视的是开发流程，努力找到一种适普和容易控制的开发方法。但理论和实践是有差别的，所以才有一个不断调整的过程。这样，根据不同的实际情况，可以对软件开发流程有自己的理解和方法。

　　现在流行的剪裁rup就是为了适应各种不同的情况而实施的。所以很难说哪个好或不好。但通常情况下，流行的方法都是经过理论和大量实践，所以一般都适合于各种情况。

　　至于你们公司，是否有修改的可能和必要？如果没有，那么当前这种开发情况就是最合适的。否则可以找咨询公司，为你们公司的实际情况设计一套开发方案，这涉及大量的细节，这里简略的讨论实在不是很合适。

　　ericzhangali：

　　呵呵。质量流程部门坚持要每次release前都送测，他们好象不在乎送测的意义有多少。看你说的情况，严格按照流程管理只会增加管理成本，导致项目延期，说服不了测试部门。

　　我觉得对release的定义模糊。

　　客户工程师一个电话打来说改一个bug，马上发个新版，是不是一次release。

　　如果只要有送出就要经过测试的话，我觉得还是由测试部门和客户打交道吧，接收需求，研发修改，提交测试，再送出。至于时间，由测试部门去和客户协调。

　　wbsndts：

　　按照这样的现实情况，谈需求的窗口不应该是研发部门了。

　　ericzhangali：

　　唉，规则都是人制定的，也都是人执行的，混吧。

　　由于测试的人远离客户，他们不清楚客户的需求的关注的权重，往往他们报来的bug和客户提出的bug相差很远。我们只能优先考虑客户的bug，而渐渐疏远公司流程中测试活动的产物。

　　这日子只能先这样过了。。。