高效組織的配置管理計劃

根據ieee 828和cmm/cmmi，配置管理計劃常常被認為是一份文檔，确實的，對于一個大項目而言，往往需要制定項目自身的配置管理計劃。

　　但不是所有的組織都是軟體外包組織，不是每個項目針對的是不同的客戶。

　　在非軟體外包的高效軟體開發組織中，推薦的配置管理計劃應有三個層面。

　　首先是組織層面，一般，提供統一的配置管理服務，不會允許每個團隊自己搭建配置管理伺服器。是以對于組織級的配置管理服務要有所約定，約定的主要内容有：

　　如何建立項目文檔目錄？

　　如何建立産品級目錄？

　　如何建立代碼目錄？

　　配置項如何命名？

　　配置庫的備份和恢複如何進行？誰來進行？

　　什麼情況下拉分支？什麼情況下合并到主幹？ 關于分支主幹要提供多種模式，或者放開限制，讓産品線或者項目組選擇。

　　如何進行變更？ 一般應當在組織級進行定義和釋出。如果放到項目層面，變更流程的制定太費功夫；當然有些大項目是有足夠的預算和特殊情況需要專門定義項目級的變更。

　　對産品線和項目如何開展配置審計？

　　有什麼推薦的配置管理實踐？

　　組織級配置管理規程或者指南的更新頻率在每年一次左右。

　　其次是産品線層面。對于特定産品線，已經存在大量的源代碼和文檔，那麼結合實際，這個産品線在配置管理存儲時有哪些約定？

　　比如對代碼配置項和非配置項有所說明，不要假設每個團隊新人都是代碼配置管理達人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以删除，但發現再删除，其本身就是成本。

　　比如哪些依賴項值得存儲？

　　比如哪些區域是機密，權限另外管理

　　比如那些代碼是核心代碼，如果改動需要資深人員複核。

　　本産品線的主幹和分支政策是什麼？ 守護主幹？還是先鋒主幹？無分支？還是單分支？還是多分支？

　　比如約定團隊統一一緻的工作環境：都把java裝在c:/java，把eclipse裝在d:/eclipse

　　最後是項目層面。在有了上述組織級和産品線級的配置管理約定後，項目層面的配置管理計劃中最關鍵的是需要明确人員、基線和項目特殊配置項。其中基線的安排必須與項目本身生命周期的選擇相比對，最重要而言，必須比對于裡程碑。

　　在這樣的三層結構下，為項目高效計，不需要單獨寫項目的配置管理計劃，隻需把項目級的配置管理約定寫入項目計劃即可，一般的篇幅不超過1頁。