查看完整版本: 关于变更控制粒度的一些疑惑

关于变更控制粒度的一些疑惑

引用：审计是在配置项建立前期还不稳定时采取的措施，此时配置项变化过多，频率过高，所以不需要太大力度的控制变更，不用CCB决定。所以只需要记录变更时间，负责人等信息以便于变更的跟踪。到了建立后期，变化少了，频率降低了，项目组确定整个配置项比较稳定的时候，这个时候就利用基线的概念建立对配置项的管理，这里也是图书馆例子没有体现的。在基线管理的时候，如果发生变更了，就走变更控制流程，由CCB进行商议。

转载请注明源自[url]www.SCMLife.com[/url],请保留版权. 本贴地址：[url]http://bbs.scmlife.com/viewthread.php?tid=1389[/url]


看了上面的帖子之后，我对变更管理有一些困惑，想单独开贴跟大家讨论，关于变更控制的粒度：
首先我同意以上作者对变更控制的理解，达到基线后的变更应该CCB审核控制。可我们这似乎就没有稳定的时候，不停的修修改改，尽管形成基线了，可还是在频繁的改，所以变更控制也就变成一种形式了：（
所以我在想，基线无外乎也是由一组配置项组成，这样的话是不是对所属基线的配置项应该严格筛选，级别很高的才需要做基线控制，级别低的就不纳入基线控制范畴，变更控制也就相应松一些？
我的另外一个问题是，基线的定义，是某些重要阶段需要基线管理还是每个阶段都需要进行基线？

重要阶段需要基线管理－－I think so
对于变更管理，偶也觉得，相当地形式化，没有发挥出理论上的作用。。。

我想，在做基线之前，或者说做配置管理之前第一件事情是识别配置项，先要知道会有哪些配置项，然后再看基线如何定义。我们目前定义主要是以里程碑来界定，但是在详细设计和代码之间我们没有去定义基线，因为通常情况下，两者的分界并不是十分明显。
我们主要定义了以下的基线：
1） 需求分析的工作产品评审通过；
2） 系统测试设计的工作产品评审通过；
3） 概要设计的工作产品评审通过；
4） 集成测试设计的工作产品评审通过；
5） 测试阶段里程碑会议前；
6） 验收阶段里程碑会议前；

基线内容包括以下两点：
1. 在该时间点所有已通过评审的或通过测试的工作产品。
2. 各个阶段的关键工作产品。例如：需求说明书、项目计划等。
基线中各配置项相互一致。

基线内容变更后，CM需要再次建立基线。

另外在测试阶段还定义了测试标签等。上面的部分内容引自我们自己公司定义的项目配置管理规范。

忘记了说变更了。我们对变更的控制是，在形成基线前，不去做变更控制，因此此时变化可能非常多，不利于变更控制。而一旦形成了基线，就必须走变更控制流程，一般是由申请人提出变更申请，并作影响分析，由CCB来决定是否进行变更或其它处理方式。

[[i] 本帖最后由 shotstar 于 2008-7-17 13:32 编辑 [/i]]

回复 板凳 的帖子

谢谢二位！我这关于基线的定义也是跟shotstar描述的差不多，甚至还可以剪裁，一般是保留需求、设计、测试结束等几个阶段的基线，但我们除此之外，还对很多不是基线产品的配置项也要进行控制（也就是说受控以后的变更要走变更流程）。因此这样一来，需要评审、走变更流程的配置项就很多，而且我个人觉得还有一个严重的问题就是，评审会上都不是针对配置项本身去评审，而是比较宏观的去评价这个项目，或者即使有问题评审人也发现不出来，久而久之，评审就变成了形式：（

下面是《可视化项目管理》中看到的关于配置管理和变更管理的内容，希望对你们有点启发，虽然不能解决变更控制粒度的问题，但是如果弄明白变更的目的和意义，那么如何来划分变更的粒度就可以根据情况进行简单和复杂的变更流程了。其实评审也是一样，也是有简单和复杂之分的。

1.        配置管理通常是项目成功的关键因素，它是最重要的事前控制过程之一。
2.        配置管理是在变更的环境下对不断变化的项目基线进行控制的过程。
3.        配置管理为识别变更、控制变更、对变更进行沟通提供了有效的方法和工具。
4.        必须在项目开始的时候对商务（商业）、预算（成本）、技术进行折中平衡，并且在基线发生变化的时候依然能维持这种平衡。
5.        变更控制的过程可以很简单，也可以很复杂。
6.        没有哪一种变更可以说成是可以忽略的小改动，都需要进行变更控制。
7.        变更控制过程要确保三点：
[indent]a)        所有受影响方都同意变更。
b)        变更协议被记录下来而且得到充分的沟通。
c)        要遵守变更流程。[/indent]