变更控制中 ，配置项的提取是不是应该进行出入库的控制，从受控库中而不是直接从开发库中提取？

问题已经解决 [打开主题]

本主题的最佳答案为 [ 10 楼].

变更是针对基线而言的，若你的受控库存放的都是发布的基线，则需对受控库进行出入库控制。
若是对开发库进行变更，则会影响开发过程的流畅，造成关键路径上的瓶颈，也无谓的增加管理成本的消耗

变更应该是对基线的变更吧。
开发过程中的配置项本身就是处于变化中的。

变更肯定要进行出入库的控制，需要有流程来控制，

保证变更的正确执行，变更的内容正确，基线得到了升级，相关人都知道了变更。

我认为，这是一个变更管理粒度的问题。
主要是根据项目真正需要控制的阶段来加以控制。
例如，co，ci需要严谨控制，那么代码库的变更也是需要受控的。
如果转测试、正式发布需要控制，那就基线库、产品库的内容需要严格控制。

如果变更的是已经基线化的工作产品，那么开发库和受控库的版本就应该是一样的。从那个库提取配置项就看你们的规定了，最好是从受控库，^_^

引用:

原帖由 qingqing 于 2006-12-4 18:53 发表
变更应该是对基线的变更吧。
开发过程中的配置项本身就是处于变化中的。

变更肯定要进行出入库的控制，需要有流程来控制，

保证变更的正确执行，变更的内容正确，基线得到了升级，相关人都知道了变更。

错，变更不一定是针对基线

dellxps的见解很独特，不知能够详解一下

我认为这个问题和企业的开发策略的选择有关，是基于RUP，还是敏捷开发。

对于RUP，一般来说，变更是基于基线。
对于敏捷开发，不一定会有基线，变更不一定基于基线。

变更的种类？BUG，需求的变化，市场的变化，设计的变化等

变更管理的目的：1，翔实记录和跟踪变更的发生，保证项目的质量和进度。设计的可回溯和可维护性。
                2。识别变更，认清变更发生的原因，进行改进，流程优化，消除和减少变更的发生。

感觉大家说得都有道理。
这个讨论应该有一定的条件吧？

变，总是相对的一个参考点的。个人认为没有参考点的，就不能称其为变，因为没有比较如何知道是变了呢？就像高矮、胖瘦、黑白。

变更是否是基于基线的变化，关键不在于变更的类型或什么样的研发过程，而在于大家是否把变化的参考点视为“基线”。

但并不是每个参考点都值得我们视为“基线”去对待。只有那些对最终产品有意义的参考点，才值得我们投入适当的成本来管理对这个参考点的变化，这样的参考点就是我以为的基线。

不知道大家是否赞同？

最佳答案

该回答被楼主/管理员列为正解!