配置管理員(CM)如何接手一個正在進展中的專案？

 出自：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系統等等都是後話了。

以上只是我自己的一些經歷，歡迎大家提出意見和建議，同時更歡迎大家把自己的親身精力寫出來，與到家分享。配置管理員(CM)如何接手一個正在進展中的專案？

 

http://bbs.scmroad.com/viewthread.php?tid=676&extra=page%3D1