查看完整版本: 我走的路------错了么？

我走的路------错了么？

我做CME才两年，虽然当初选择这个行业很巧和，但是我对此的兴趣仍然是我决定投出简历那刻最大的动力。

   刚开始做的2--3个月，也许和大家一样，刚毕业出来试着容入一家公司，学习前辈们留下来的财产，学习公司的流程。可以说这段时间是很按部就班的过程，虽然在学校实习的时候就是做的CME（也就是靠着那时的那点知识通过了面试），真正接触一个项目，接触到CMMI的知识从这个时候开始，学校实习的时候可能就看中一个工具吧。我想下，那个时候我关注的基本上是以下几点：
1、配置项的识别。
2、基线的发布。
3、配置审计，状态统计。
4、变更的记录。
。。。。。。

    等过了一段时间后，熟悉配置管理的这些基本工作，然后开始真正，也可能是大家经常遇到的一种情况：总觉得，我们的做法，我们的过程总不能合适我们的项目，我们的开发人员在发牢骚，我们的项目经理在发疯。。。是我们的错么？这是我经常思考的问题，也许一个项目失败或者有比较严重的延期了，可能是产品规划本身的问题，可能是技术能力的问题，也可能是风险识别不及时导致的，等等。。。可能都不是我们可以决定的事情，但是我总会不安。
   接下来，我开始熟悉除了配置管理之外的流程，需求开发，产品规划，风险识别，项目进度如何制定，测试的流程如何，现在看起来那个时候很有干劲，总想学习很多东西，思考着如何才能让配置管理结合项目，这个时候我关注的重点就是（说实话，有些问题到现在我还没有理解透彻）：
1、配置项的识别，发布的时机，对相关人士的周知的重要性。
2、基线的定义，定义什么样的基线才能对你的项目最有帮助，关注项目重点是什么。
3、变更的安排，变更周到的重要性，也可以说如何协调变更，如何识别潜在的变更，变更的总结分析。
4、配置审计，状态统计的意义是什么？如何在项目中实现？很通俗的说，如何才能让大家看你的状态统计，让他们觉得这些对他是由帮助的。
。。。。。。
    也许，按照我老大的看法，我在这个时候开始模糊自己的职责问题了，我很反对。我可以不管他的看法，但是我不是那种人，我总是很在意别人对我的看法。

    这样做了一段时间，我渐渐开始学习所谓方法论的东西了，项目迭代周期的安排等，还有XP，还有构建，持续集成，CMMI等等的理论知识。这段时间看起来很混乱，因为受了工作中某些事情的刺激，不说也罢。
    过了那段郁闷的无法倾诉，也无人可以倾诉（这也许是现在上班族的悲哀，至少是我的悲哀）的时间后，斗志慢慢的回来了，重点关注的是工作空间的问题，也就是我们所说的日常工作区，受控库，基线库，因为公司的财产出现了泄漏的问题，虽然事后查出来，不关乎配置的事情，但是这样的事情发生还是给我很大的压力，感觉到我们以前的安全措施并不perfect，开始改造个人工作区，权限的分配，开始培训，推荐分支的使用，也开始感觉到自己知识的不够。这个时候我就重点关注工程类的过程了，从编码到测试这个阶段工作产品的产出过程，这些工作产品的进度，各个工作产品的协调，那个时候我总是很喜欢用CMMI中的“需求跟踪”的理论去指导各个工作产品之间的联系与关系。说实话，那段时间是我自己觉得我在成长的阶段。
     1、我关注的流程：1、个人工作空间中代码的权限分配，目的达到：越少的人能够有一套完整的代码。这点很难，不是在于实现这个很难，而是在于如何实现这个目的，同时保证开发工作，协调工作的进行。当然从配置库的结构角度去考虑；
                      2、代码的验证集成工作，中间我也集合了构建，持续集成的方法，后来我放弃了。因为这个就是我很鄙视方法论的地方，就好像我说的，同一样东西换个说法就能够让人疯狂，这样的事情不要学。持续集成的方法很好，XP的方法也不错，但是重点在于什么，TTD的开发，可是，什么叫TTD，测试驱动，说的明白点，也就是我们最原始说的单元测试脚本，当我看到这个问题所在的时候。我觉得当务之急是应该在公司内加强开发人员开发习惯，提高开发素质的工作上。
                      3、需求变更同代码之间的变更关系，以前没有关注到代码这个层次，是失败。但是这方面很难，我总是力不从心。
                     
     2、配置管理的关注：1、也许就是我前面说的工作空间的管理，你可以根据每个项目实现为了便于查找的细化，你可以实现为了代码安全的细化，根据项目情况增加文档的临时工作区域，主要为了便于集成。
                        2、分支功能，使用的培训，其实我作的应该是代码分支策略的培训，跟踪，甚至为一些项目提出必须要使用分支的方案。这个是很累人的工作，我要去了解很多，从功能需求，架构设计，还有产品规划，然后才敢对项目经理或者高级经理提出要实施分支的建议。我做了很久，才成功了2次，其他的要么就是分析不到位，要么就是理解不透彻，被否决或者敷衍过去了。
                        3、基线变更，这个是我以前在这个论坛也提出过的问题，因为项目组中碰到了迭代的情况，这个问题变的如此不可理解。。。现在也没有搞懂怎么做是最好的，甚至我对基线变更的定义都开始混淆了。
                        。。。。。。
                        
      很伤心的，我的学长走了，我开始接手组织级别的东西。那个时候很激动，毕竟我认为我的老大信任我，中国人那种远古的“士为知己者死”的高尚情操在我的血脉中澎湃。。。（是不是有点恶心，不过是真的）
      所谓的组织级别可能涉及比较多的，产品发布，产品管理，过程类的改进等工作。这几个月来一直在作这些，也很努力的思考着。。。现在突然觉得心灰意冷。
      不说丧气话了，不过这个方面的工作我还真的不知道怎么去总结，现在还在进行中，可能和我的心情有关吧。
      这么说吧，让我去建立一套配置管理体系，我要做的是什么？让我去制定一套流程，我考虑的够了么？

      前几天，我突然发觉我以前做的一切都否决了，我的老大认为我以前的做法不是我该考虑的，我迷茫了，甚至心灰意冷了，总之我不能接受的。一直没有想通。。。
      
      我给自己的做法起了很土的名字，基于配置管理的项目管理，因为我是CME，我完全按照配置库的东西去理解项目，去与开发人员沟通项目开发情况，去分析项目进度的偏差，如何采取措施，去了解产品规划是为了产品发布。。。。。。
  
      这几天，很伤心，幸好，天气也在下雨

我也是做了时间不长.一堆迷茫.
楼主真伟大,写出了自己的真实感受.我都不知道从何写起...

首先，我想对Shuku说的是，你的路没有走错，错的是你太在意你老大的感受。不能因为你大佬的一句话，就把你的努力给化成风。
其次，我觉得你不必心灰意冷，你所关注的，所从事的，正是对项目，对这个企业最紧要的东西。一天看不到，两天看不到，时间稍微长一些，就可以看到它对这个企业所造成的影响。

再者，你现在除了自己学习外，还要与大家多沟通，对你的困惑，一个个都提出来，把问题具体化，然后再逐个消灭。你可以多来论坛与大家交流，也可以找业内的朋友来交流。你这个阶段，交流最重要。

最后，我希望shuku能坚持自己的理想，坚定不移地走下去。不要轻易被别人所左右。

呃……我非常佩服楼主的所做出的探索和努力，但我还是赞同你们老大的观点

当你们公司整体的开发流程还没有完善起来的时候，用配置管理的通用实践去要求具体项目的实施，不太合适

我个人也觉得，公司级别的开发流程问题不在我们考虑的范畴之内，事实上，我们只需要看菜吃饭就可以了

所谓的配置管理标准或者思想定义了很多的词汇，但这些词汇在不同的公司有着不一样的含义

比如说，配置审计在我们这里是没有意义的，最多在PM明确要求的时候才会出一份技术性的统计报告

没有必要每看到一个新的方法论或者最佳实践名词就马上在自己的项目中去实现它

举一个我自己的例子吧，以前写代码的时候被设计模式困惑了很久，总想着在怎么样在代码里实际应用起来

这样一来，一到OO的设计和实现的时候自己就开始糊涂，写出来的东西也不伦不类

其实，Factory、Singleton、Adapter和基线、审计、变更等学术性词汇一样，只有项目真正需要的时候才有意义

最后，祝楼主心情愉快，重装上阵。

当你们公司整体的开发流程还没有完善起来的时候，用配置管理的通用实践去要求具体项目的实施，不太合适
我个人也觉得，公司级别的开发流程问题不在我们考虑的范畴之内，事实上，我们只需要看菜吃饭就可以了


我们公司的流程貌似建立起来，（也许我还没有理解的原因吧）

我只是在考虑一些实际发生的问题罢了

谢谢你们的鼓励

楼主遇到的困惑和我一样，我一样的无所适从，但是有一点区别，我们老大却放手让我去考虑，我是考虑了，形成了开发方案，也在开发团队中讨论，得到大家的共识，但依然无法实施。这就是问题的关键，我也在想办法处理。

迷茫和困惑是啃定会有的，因为我们的工作是改变习惯，确立新规则的工作，当然不如开发那样容易处理，让我们一起努力吧。

多沟通，看看老大想要什么

顶楼主的原创!

我觉得你的方向没错,除了按部就班的执行，还需要多关注工作中的一些问题，多学习，多想想，这样自己的进步很大。也可能你做的改善的努力，能够有些效果。
配置工作本来就是整个软件过程中重要的一环，与各个环节都有密切的关系。

但你所想的得不到老大的支持，这个是个问题。我觉得你可以把本职工作做好的情况下，可以将问题和建议先提出来，最好是与配置工作相关的。
如果能够得到他的支持，再去实践，也许效果会好些。
因为可能你们已经建立了流程，流程虽然是需要不断改进的，但改进的方向和方法需要得到大家的共识。
加油！

配置管理是建立在开发管理基础上的,开发管理得不好,配置管理没办法进行,勉强为之就做成了"仓库管理员",所以配置做起来让人看不到希望,没什么成就感.

配置管理是建立在开发管理基础上的,开发管理得不好,配置管理没办法进行,勉强为之就做成了"仓库管理员",所以配置做起来让人看不到希望,没什么成就感.

我现在的状态就是停留在仓库管理员，开发人员总以为配置管理工具只是为了给他们的东西保留一个备份，这种思想还不知道什么时候能改变过来。流程有，但是执行起来的力度太小了！

[quote]原帖由 [i]shuku[/i] 于 2007-12-10 10:23 发表 [url=http://bbs.scmlife.com/redirect.php?goto=findpost&pid=66525&ptid=9265][img]http://bbs.scmlife.com/images/common/back.gif[/img][/url]
当你们公司整体的开发流程还没有完善起来的时候，用配置管理的通用实践去要求具体项目的实施，不太合适
我个人也觉得，公司级别的开发流程问题不在我们考虑的范畴之内，事实上，我们只需要看菜吃饭就可以了


我 ... [/quote]
你们公司也许是有了流程，但是并没有实际推行起来吧```  有时候是不能急，而且也急不来的，即便我们知道按照正规流程应该这样做，但是项目上不会这样认为，他们会觉得很烦，很耽误时间。你只有慢慢来，先把最基本的让项目上做了，习惯了，然后再不断的加更规范的操作进去。你也不要觉得迷茫，在不成熟的企业都是这样，习惯就好```

顶一下

个人认为，不能为了配置管理而管理，先了解项目组需要什么，我们能够为他们提供什么。在一定的原则下，尽量解决项目组的要求，搞好关系。才能逐步的按照理论去开展工作。

在国内做事情，沟通和人际关系还是非常重要的。

再写点。。。嘿嘿

通常项目开始，我会去了解这个项目组的习惯，能否及时把所有工作产品完整的入库，如果这点做不到，让项目经理去协调，然后，在项目开始时，是否清晰的获知项目的工作产品，如果项目组说，不可能，我要做了才知道会出来什么，这时候最简单，只要他们给什么，我管什么就可以了。

清楚项目所处的阶段，后续的工作才能采取适当的方式开展，不管对于Qa还是CM都需要很漫长的一段时间来磨合。。。

回楼主的帖子！
楼主写了很多自己工作的感受，我在配置管理这个行业已经干了4年半了，一直在使用CC这个工具。公司原来用的是iso9000的文件体系，现在已经过度到CMMI了，在这个过程中我个人认为走的还比较顺利。
其实楼主的想法我当初也有过，总结一下，我们都是热心的人，都想把工作做好，眼里容不得沙子。有得人会说我们多管闲事，有得人说我们是工作积极。其实不管什么事情都会有人说你对或者错得，我觉得只要自己认为对，我们就应该去做。
我觉得你那些做法都是对得，可以从两方面进行说明：
对于公司：对于公司得管理和流程体系，只有不停得提出不同得意见，公司才能向前。
对于个人：完全可以把公司当做自己个人奋斗得试验田，但是要保证质量，呵呵，因为一个人毕竟不会在一个公司待上一辈子，个别人除外。

最后推荐一下楼主看一下 《像青蛙一样思考》 这本书， 这本书好像我们论坛里就有哪个发过，我忘记链接了

忍不住要顶以上两位所言！呵呵。

看了各位同僚的发言，可能是我太固执，有时人想不开就是这样。

如果不在乎那么多也就不会有那么多烦恼。行，就留下；如果实在不行，也就只好走吧。毕竟这个只是工作。你不能奢望太多。毕竟一个团队不是你一个人，毕竟我还不是站在顶端的人啊。

我觉得lz和上面几楼的zz们都很棒！因为你们在思考生活，思考自己目前所面临的问题，这就预示着你将迈上新的一级，破茧成蝶，对吗？因为，只有你思考了，才会有如上见地。很pf你，lz！也从你的发言中学到了不少，感谢！

回复 楼主 的帖子

对了 想问一下 cme具体指什么？他和cmo有什么区别？谢谢！

应该是cm engineer吧。叫法不同，我觉得应该是一样的

没有错哦，坚持 再坚持一下下就好了。我感觉是你们现在的配置制度和实际开发状况有差异造成的。其实要解决这个问题是很困难的，因为罗马不是一日造成的。 现在问题已经出现了，大家都抱怨连连  要改变现状不是你一个人能做到的哦， 这得先做需求分析，然后了解问题的症状所在 才能对症下药。另外，想开展工作必须得得到领导的支持，你做的事情必须要让大家看到好处 工作才容易开展