dissip
BigCat
发贴: 240
积分: 60
|
于 2005-10-14 09:38
Thanks for your reply. that's why i post the question in your column.
floater wrote: should avoid this kind of behavior, through a better planning. Fool me once, it's your fault; fool me twice, it's my fault, .
I thinkd this kind of thing is unavoidable. it's because user acceptence test mainly depends on the users. suppose project 1 has a relatively fundamental change to a function. and we need time to train a lot of users to get used to it before production and verify whether it meets the majority of the user's needs. e.g. it tooks 2 weeks to finished the job. another project 2 is a simple enhancement that change a report layout, only a few user use it. it takes only a few days for users to test it. so if project 2 release to uat just after project 1, 2 will request to release earlier than 1. if these 2 projects are the only projects, i think we can arrange the test to avoid such colission. but there are several concurrent projects and it's really hard to avoid all of them.
floater wrote: create different branches after integration and before uat so that you can selectively merge anything version.
by integration, we mean to eliminate all technical defects. by uat, we mean to get user's approval to release to production. use the former example, if p1 and p2 have dependency, there will definitely be a plan about the 2 project's release time. if the 2 projects don't have dependency, i don't understand what you mean by 'create different branches after integration'. would u please explain it?
To live is to fight.
|