但是当我们费了九牛二虎之力终于出了一个系统软件版本的时候。有些开发人员跑过来跟我说：在你出版本的这段时间我们又增加了不少新的功能，你现在的版本是旧了，必须要把我们新加的功能加到这个版本中去。我当时就有些火了：“不是说好了在出版本的这段时期内除了修改测试发现的问题外不能再做其他的修改了，尤其不能再增加新的功能了，你们这样搞那我这个版本不是白出了吗？”。他们听我说完白眼一翻：“有意见找我们领导去，是他让我们加的。”，说完就走了。我去找负责该项目的经理，他却说没办法任务太紧张了，不可能停止开发的。
我又跑去找老总：“能不能先把做好的这个版本交给客户先用到，有些功能下个版本再说”。他说：“不行啊，有些功能客户指明要的，你再重新出个版本吧”。我说：“出版本是要花时间的，就算我重新出一套版本，开发人员在我出版本的这段时间同时在开发，那我的版本怎么出啊？能不能等开发完了再出啊 ？”。老总说：“那不行，时间太紧了，我是想你们同步在做，你出版本的同时他们在开发，等开发一结束你的版本马上就出来了”。我说：“同步做可以，建两个分支，一条分支开发，一条分支查错。但是两个分支合并也不是那么容易的事，即使合并了也不代表这个版本就出来了，还是要进行代码收集、系统构建、安装、测试这样的基本操作的”。老总说：“不要给我讲什么术语，我不关心，总之你给我想办法，现在任务那么紧张，你要即不影响进度又要保证软件质量，做不到就扣你奖金”。说完就走了，只留下呆呆的我。
当天晚上我来加班，抽了整整一包香烟。我不停的问自己：到底是我水平太低，还是领导的水平太低......？？？
ozzzzzz：
配置管理员是不是管理人员，这个是一个问题。究竟什么人可以做配置管理员，这个也是一个问题。需要不需要一个专职的配置管理人员这还是一个问题。这三个问题构成的基础的企业配置管理策略，其他的任何手段都是受这三个基础原则约束的。就目前情况看，国内大多数运转良好的方式是这样的——配置管理员是技术人员，他主要负责配置管理系统工具的维护，提供配置管理系统的运行支持。配置管理人员一般都会选择经过培训的专职人员担任，其性质其实和网管类似。而项目内有自己的配置管理人员负责自己项目的配置管理工作，这个人绝大多数情况下是兼职的，多数情况是有技术负责人担负。
针对本贴的具体情况我认为，很多问题是制度上的，当然也有人的素质上的。首先我坚持每日构建是最低线，而这个帖子中说的情况看是没有做到的。
其次他们老总明确的说出一个xx项目成熟版本，那么究竟什么是成熟这个标准是谁制定的。按照这个帖子的情况看，貌似是配置管理员制定的。这是一个巨大的错误——任何版本的都需要经过开发者和质量管理者会同管理者共同评估，以制定究竟这个版本不是成熟的，还是需要测试的，还是可发布的，还是提供适用的。而当真正需要输出这个版本的时候，所需要做的仅仅就是一个make而已。
任何时候都不可能停止开发，除非这个项目要终结了。调节功能，添加或者修改以至于删除都是很正常的。关键在于用户的需要必须与之对应。因此对照上面的情况，除非是管理层经过同开发和QC会商之后已经确定某个版本将被冻结，并以此为基础构建一个发布版本，否则在此基础上的开发不会被终止。而一旦确定冻结，则需要有专门的开发人员负责维护此版本，以达到最终发布的标准。
持续集成，可以解决开发和除错的不同步问题，关键在于企业是否能够真心实意的采用这个敏捷的做法，而抛弃旧有的迟缓和不协同。
文章来源于领测软件测试网 https://www.ltesting.net/
