- 论坛徽章:
- 0
|
出自：bbs.scmroad.com 作者：laofo
在公司常常会遇到这种情况：
以前因为种种原因，项目没有专职的CM,但是有了自己的SCM系统，可能有开发人员暂时兼管着，而你这时临危受命。当你刚开始介入项目的时候，应该怎么展开呢？
我个人觉得先从了解项目开始：
1. 参加项目例会(project meeting)
认识认识人，哪个是PM，哪个是QA，哪些是Tester。。。这个时候可能需要你的经理或者PM把你介绍给大家。看看美女帅哥，这就是你第一次参加项目理会的重点。
开完第一次项目例会之后，一定要去看看project plan，对这个项目周期，人员等等都要有个大概的认识。第二次参加会议的时候，就有一个CM发言的时间了，这个时候就是你的时间，记得把平时工作中发现的关于CM的问题提出来，和PM，QA等一起商量如何解决。而有的事情（比如违反公司开发流程的事情）更要坚定不移的提出来，如果PM觉得有充足的理由不遵守公司的流程，记得记下为什么作出的这个决定，也许Email，Document更能帮助你回忆，所以一定要保留下相关的信息。当然这些东西并不是让你第二次开会的时候就能都找出来，可能刚开始的 一段时间，了解项目进度才是你最主要的工作。
注：有的公司可能Team Leader（TL）管这些事情，而PM只管进度。那么你多数情况下联系的就是TL了。
2. 主动加入到项目的maillist当中去
你可以自己要求，也可以向PM提出。这样项目一有事情，你也能得到通知了。
3. 要有SCM系统的授权
因为项目已经有自己的SCM系统，你也就省去了一些搭建的时间。这个时候你需要向PM提出权限申请。
CM一定要有SCM系统的full control previleges。
CM不一定会改变些SCM系统什么东西（如果有需要，CM肯定会改变的），但是CM一定要有SCM系统的全部控制权限，虽然有的时候你可能还接手不了整个项目，因为你毕竟是项目中间加进来的一个人，但是一定要有这个权限。CM这个时候可以和开发人员一起管理SCM系统。事实上，最开始的阶段是你向开发人员在学习这个系统。
4. 理解构建过程
有的构建是通过makefile，有的是通过nat，或者nant，。。。那么这个时候你就要下点功夫去理解这些构建的脚本了。
CM不一定控制和负责所有构建脚本的编写和维护。因为有的系统很大，目录要分很多的层，开发人员对最底层的构建肯定要比CM熟悉的多，而这些最底层的脚本也变化的很频繁，CM不必也没有那么多精力去维护这么多构建脚本。所以建议CM一般只要控制和维护最顶上的1到3层之间的构建脚本就可以了。
注：如果项目还没有通过脚本来构建项目，那现在你就来完成它吧。
5. CM plan
无论什么时候，CM plan都是你始终应该关注的重点。这里规定了你该做什么，怎么做，什么时候做等等问题。
如果项目还没有CM plan，或者还没有正式的CM plan，请撰写并且完善它。完成之后记得发给PM，QA，你的直接领导等等人士去review，没有问题了就发布出来。这是考核你工作的标准，事无巨细，觉得对以后CM工作有帮助的，就要在project meeting上提出来，然后更新到CM plan中去。
记得把CM plan放到SCM系统中去，同时让所有的人有权限访问。
公司有什么编码规范啊，流程的规定啊，都可以作为CM plan的参考文献附在后边，哪怕给个链接地址也好。
实际工作中遇到不明白的或者不清楚的时候，请记得参考CM plan，看看CM plan中是怎么规定的。
注：如果公司有CM plan的模版，或者其它项目有CM plan，那么你不妨拿来参考一下。闭门造车的行为我不推荐，从前人的文档中，结合自己的经验，挑挑拣拣找出适合这个项目的，就是最好的。
6. 关于CCB
因为以前更本没有CM，所以CCB这块也是缺失的，而有的公司的流程把这一块弥补了。
7. 关于SCM系统的使用
如果你以前没使用过，那么自己平时就要去学习。多向知道的人请教。先把最基本的，经常用的知识学到。80％的东西都可以放到以后去学习。
。。。。
通过以上几点，你都可以慢慢的融入到项目中去。而后续的工作，比如完善流程，SCM系统等等都是后话了。
以上只是我自己的一些经历，欢迎大家提出意见和建议，同时更欢迎大家把自己的亲身精力写出来，与到家分享。
http://bbs.scmroad.com/viewthrea ... e%3D1&frombbs=1 |
|
免费注册
发表于 2008-08-26 14:21
学习学习