只显示主题贴
偶主贴里可能说得不够清晰，客户不可能事先告诉我到几号之前要下发哪几个需求，他们的流程就是一个需求一个需求地走。走完流程的就下发，象2楼说的，AB如果在同一个分支开发，那到时如果客户决定我只下发B不下发A那不就惨了。所以也没法象三楼说的按时间来打基线，客户没有阶段性版本的概念，各个部门都提自己的需求，没有个统一的需求打包版本，这只能从流程上对他们进行引导，如果能做到这样偶就不用这么烦恼了。
偶现在能想到的只能是一个需求一个分支（这对SVN和CVS这种COPY分支的来说要耗费太多的空间了:(）开发测试。然后确认好哪些需求要下发的时候再并入主线再叫他们业务测试一遍然后下发生产系统。这样的缺点就是一要 ...
- 进入论坛 软件开发和项目管理 版
我觉得WIKI有它好的一面也有相当不便的地方,比如说各种格式文档的生成和转换.象你说的原有的word/excel/ppt想转进WIKI是相当麻烦的,只能当附件存放的话又没法达到WIKI的协同工作和全文检索版本管理等好处.
- 进入论坛 软件开发和项目管理 版
公司一个项目，处于长期性的应用维护阶段，即甲方有需求（或BUG）报过来就开发。用户需求是多个部门都可能提交，每个需求经过设计、开发、测试后就下发生产系统，甲方由于内部原因目前没有阶段性版本的概念，基本上是每个需求都走这个流程（因为谁都觉得自己的需求很重要不能等别人，但最后往往都拖着不测，哎，这就叫甲方……）。
这就使得我们的版本管理很混乱，再加上系统很庞大，以前也一直没有很好的回归测试方法，没法控制每个需求的代码改动对其它需求的影响度。比如先来了个需求A，于是可以开一个分支A进行开发，再来了个需求B再开个分支B，然后分支B在先测试完成后merge到主线然后下发，到这都没问题。然后分支A在测试完 ...
- 进入论坛 软件开发和项目管理 版
评论排行榜