高效組織的組態管理計劃

標籤：http   java   代碼   html   工作   c   ef   管理   htm   

根據IEEE 828和CMM/CMMI，組態管理計劃常常被認為是一份文檔，確實的，對於一個大項目而言，往往需要制定項目自身的組態管理計劃。
　　但不是所有的組織都是軟體外包組織，不是每個項目針對的是不同的客戶。
　　在非軟體外包的高效軟體開發組織中，推薦的組態管理計劃應有三個層面。
　　首先是組織層面，一般，提供統一的組態管理服務，不會允許每個團隊自己搭建組態管理伺服器。所以對於組織級的組態管理服務要有所約定，約定的主要內容有：
　　如何建立項目文檔目錄？
　　如何建立產品級目錄？
　　如何建立代碼目錄？
　　配置項如何命名？
　　配置庫的備份和恢複如何進行？誰來進行？
　　什麼情況下拉分支？什麼情況下合并到主幹？ 關於分支主幹要提供多種模式，或者放開限制，讓產品線或者項目組選擇。
　　如何進行變更？ 一般應當在組織級進行定義和發布。如果放到項目層面，變更流程的制定太費功夫；當然有些大項目是有足夠的預算和特殊情況需要專門定義項目級的變更。
　　對產品線和項目如何開展配置審計？
　　有什麼推薦的組態管理實踐？
　　組織級組態管理規程或者指南的更新頻率在每年一次左右。
　　其次是產品線層面。對於特定產品線，已經存在大量的原始碼和文檔，那麼結合實際，這個產品線在組態管理儲存時有哪些約定？
　　比如對代碼配置項和非配置項有所說明，不要假設每個團隊新人都是代碼組態管理達人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以刪除，但發現再刪除，其本身就是成本。
　　比如哪些依賴項值得儲存？
　　比如哪些地區是機密，許可權另外管理
　　比如那些代碼是核心代碼，如果改動需要資深人員複核。
　　本產品線的主乾和分支策略是什嗎？ 守護主幹？還是先鋒主幹？無分支？還是單分支？還是多分支？
　　比如約定團隊統一一致的工作環境：都把Java裝在C:/java，把eclipse裝在D:/eclipse
　　最後是項目層面。在有了上述組織級和產品線級的組態管理約定後，項目層面的組態管理計劃中最關鍵的是需要明確人員、基準和項目特殊配置項。其中基準的安排必須與項目本身生命週期的選擇相匹配，最重要而言，必須匹配於裡程碑。
　　在這樣的三層結構下，為項目高效計，不需要單獨寫項目的組態管理計劃，只需把項目級的組態管理約定寫入專案計劃即可，一般的篇幅不超過1頁。
原文連結：http://www.51testing.com/html/89/n-866189.html

高效組織的組態管理計劃