思步网

标题: 配置项变更问题？是否违背CMMI规范？ [打印本页]

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

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

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

作者: cecilia 时间: 2008-6-4 08:41
有没有谁知道的呢？
对于配置项变更控制你们又是怎么来做的呢？

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

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

这个方法可行吗？:loveliness:

作者: rebeccazxy 时间: 2008-6-4 15:56

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

这个方法可行吗？:loveliness:

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

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

作者: iamredeye 时间: 2008-6-5 11:07
需要技术评审说明还是存在风险的，对吧？否则小的变更无需再次评审了。变更流程其实就是应对这种风险的一个工具。

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

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

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

作者: xixiaojing666 时间: 2008-6-5 13:33

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

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

作者: xixiaojing666 时间: 2008-6-5 13:42

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

这个方法可行吗？:loveliness:

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

作者: xixiaojing666 时间: 2008-6-5 13:58

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

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

作者: iamredeye 时间: 2008-6-6 11:25

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

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

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

作者: 森末i 时间: 2014-7-22 11:35
很有借鉴意义，先收藏了，谢谢楼主。

作者: 落雪听梅 时间: 2014-11-1 16:48
支持，赞一个

作者: ruggle 时间: 2015-3-13 21:24
very good.

作者: 后来呢i 时间: 2015-3-15 15:03
没人回帖。。。我来个吧！

作者: 橘虞初梦 时间: 2015-6-25 20:04
很有借鉴意义，先收藏了，谢谢楼主。

作者: 冷樱花 时间: 2015-7-23 09:20
看起来好像不错的样子

作者: 独心！ 时间: 2015-9-17 14:50
非常好，顶一下占位编辑

作者: 苍天为井而空心i 时间: 2015-10-26 11:56
确实不错，顶先

作者: 丶伴你到地久 时间: 2016-4-12 15:12
以我的经验来看，楼主的想法是可以执行的~

作者: 努力↗才幸福 时间: 2017-10-2 21:20
向楼主学习

作者: 末暧， 时间: 2017-12-9 09:44
看起来好像不错的样子

作者: 森迷@ 时间: 2017-12-15 17:12
看了LZ的帖子，我只想说一句很好很强大！

作者: 若ㄈ此時つ 时间: 2018-1-3 11:40
very good.

作者: 相思风雨中 时间: 2018-2-3 07:24
支持，赞一个

作者: 我词穷 时间: 2018-3-29 22:11
没人回帖。。。我来个吧！

作者: 缘何来 时间: 2018-4-2 09:07
没人回帖。。。我来个吧！

作者: 单身你好啊@ 时间: 2018-5-10 09:23
路过的帮顶

作者: 奔跑的巧克力 时间: 2018-5-12 21:06
有空一起交流一下。

作者: 海拥，鱼溺， 时间: 2018-5-31 12:15
我是个凑数的。。。

欢迎光临思步网 (http://www.step365.com/)