配置项变更问题？是否违背CMMI规范？

cecilia

按照CMMI3《配置管理》规范，当需变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”），变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。再由CCB审批该申请，安排变更任务，变更的文件再启动技术评审流程，执行人再对流程进行签阅。

制定《项目变更申请流程》的目的也是为了更好地控制配置项，防止配置项被随意修改而导致混乱。但在实际操作过程中还是不太合适，因为对于某些文件在项目的开发过程中变更是在所难免的，如果对于每一个纳入基线的文件都需启动变更流程，开发人员就觉得很烦琐，都觉得多此一举，因为更改后的文件本来就是需要启动技术评审流程的。

现在想简化这样一个操作，但又不致遗漏其它需更改的配置项：项目经理在里程碑点将变更的配置项汇总，统一启动一个《项目变更申请流程》，再交由CCB，重点说明“变更内容”和“变更原因”。这样可简化开发人员在开发过程中启动变更申请流程，现在的问题就是不知道这样做是否是违背CMMI规范？是不是要和SG、GG、SP、GP对应？


上一篇：如何更好的设置配置管理部门？
下一篇：配置管理的岗位说明（转载）

cecilia

有没有谁知道的呢？
对于配置项变更控制你们又是怎么来做的呢？

lily_014

没参与过过级，对于它是否会与cmmi的规范相违背不敢狂言。
我们公司的配置管理这块做得不是特别严格。
你所描述的问题，有一个疑问：
你所说已被纳入基线相关工作产品启动变更流程是什么驱动的？是配置项变更导致的（转1），还是其它的因素，比方说需求（转2）等等。
我认为：
1.配置项的规约在项目启动后，也就是说制定配置管理计划的阶段就约定好了的，不知道你们是什么情况。
2.如果是需求变更，那么对于需求管理流程需要执行影响分析等变更流程，对于配置管理来说，在执行变更完后，可以形成新的基线版本，然后发布即可。
个人意见，欢迎纠正。。。

iamredeye

很简单呀，baseline之后得文档如果有变更，当然要走流程。但如果变更很小且频繁，不妨先在WIP得状态下更新，当累积的变化足够大且重要，在走流程重新baseline。

这个方法可行吗？:loveliness:

rebeccazxy

原帖由 iamredeye 于 2008-6-4 11:18 发表
很简单呀，baseline之后得文档如果有变更，当然要走流程。但如果变更很小且频繁，不妨先在WIP得状态下更新，当累积的变化足够大且重要，在走流程重新baseline。

这个方法可行吗？:loveliness:

同意。
我们在做CMMI3的时候也曾思考过楼主的问题，最后采取的方法跟iamredeye类似：有小且频繁的变更时，变更人员（一般是文档负责人）填写变更申请单并记录变更原因和内容，但是此时并不提交变更申请单。待频繁变更的这阶段过去之后，再统一提交变更申请单，此时相应的审批人对变更内容进行审批，一般来说都批准了，若有不批准的，找到相应的内容直接恢复就行，再不济直接恢复到变更前的版本，呵呵！这个并不违背CMMI的要求的。

cecilia

这样看来，其实我之前写的方法也和iamredeye 的类似了，只是我们是在每个里程碑点来统计，这样不致于文档有更改了，而相关的没有更改。当然记录肯定是需要的，有些只是文字或界面型的也就没必要启动一个变更申请了，太麻烦。
对于一些文档可能没有大的改动，但是基于公司性质，在开发过程中需要制板，这就关系到原理图、PCB板图等相关文件的更改，现在是希望这些无须启动变更申请流程，只启动技术评审流程即可。

iamredeye

需要技术评审说明还是存在风险的，对吧？否则小的变更无需再次评审了。变更流程其实就是应对这种风险的一个工具。

如果这个变更流程很烦，大家都想bypass它，那么最好考虑简化这个流程，让它更实用。我说的“如果变更很小且频繁，不妨先在WIP得状态下更新，当累积的变化足够大且重要，在走流程重新baseline”并不是bypass这个变更流程，而是在风险可承受的情况下fast tracking。

我感觉很多情况下大家都在被动的遵守这个变更流程（也许我感觉错了），其实这个流程的价值在于主动去管理变更，降低风险。

如果流程真的不适用，就调整它吧。

xixiaojing666

原帖由 cecilia 于 2008-6-4 08:41 发表
有没有谁知道的呢？
对于配置项变更控制你们又是怎么来做的呢？

http://www.step365.com/bbs/thread-618-1-1.html

xixiaojing666

原帖由 iamredeye 于 2008-6-4 11:18 发表
很简单呀，baseline之后得文档如果有变更，当然要走流程。但如果变更很小且频繁，不妨先在WIP得状态下更新，当累积的变化足够大且重要，在走流程重新baseline。

这个方法可行吗？:loveliness:

赞同
我觉得变更流程可以分大变更和小变更处理的，如果是小变更可以走简易流程，比如只要和PM打声招呼，自己作好变更记录就好了。但是大变更要走严格的流程比较好，这样可以减低项目风险等。
至于大小变更的设置，看自己公司情况了。

xixiaojing666

原帖由 cecilia 于 2008-6-3 16:40 发表
现在想简化这样一个操作，但又不致遗漏其它需更改的配置项：项目经理在里程碑点将变更的配置项汇总，统一启动一个《项目变更申请流程》，再交由CCB，重点说明“变更内容”和“变更原因”。这样可简化开发人员在开发过程中启动变更申请流程，现在的问题就是不知道这样做是否是违背CMMI规范？是不是要和SG、GG、SP、GP对应？

先不说是否违背CMMI的规范，我觉得你所说的在里程碑点统一启动一个变更流程的想法是错误的，变更怎么能统一启动？而且还在事后呢？SCCB的主要职责是批准和分析变更的风险、工作量、成本等项目参数的，如果在事后就没有什么意义了。
如果是做汇总分析是可以的，里程碑处可以对CM过程的重要事件进行汇总分析。

iamredeye

原帖由 xixiaojing666 于 2008-6-5 13:58 发表


先不说是否违背CMMI的规范，我觉得你所说的在里程碑点统一启动一个变更流程的想法是错误的，变更怎么能统一启动？而且还在事后呢？SCCB的主要职责是批准和分析变更的风险、工作量、成本等项目参数的，如果在事后 ...

是啊，这种做法本质上就是想bypass变更流程

森末i

很有借鉴意义，先收藏了，谢谢楼主。

落雪听梅

支持，赞一个

ruggle

very good.

后来呢i

没人回帖。。。我来个吧！