作者：張克強??? 作者微博：張克強-敏捷307

在《源代碼管理的新15條建議?》中的第7條建議提到：每個團隊應當對代碼配置項和非配置項有所說明，不要假設每個團隊新人都是代碼配置管理達人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以刪除，但發現再刪除，其本身就是成本。

在《高效組織的配置管理計劃》也提到了產品線層面的配置管理，那么產品開發團隊的配置管理到底應該是什么樣呢？本文試圖來探討下。

首先說明本文探討的產品開發團隊的特征。這里的產品開發是指圍繞某產品或者產品線開發，其產品的生命周期是長于一年以上，為了改進產品，不斷有新的要求得到實現滿足，也會發現產品的缺陷，需要在開發中解決。 這樣的產品開發是不同于短期合同外包項目的，其產品開發團隊將較長期的承擔此產品（線）的運行維護，增強修改，開發建設。應當說，當前大多數團隊是屬于這樣的團隊。

什么是配置管理規則？

配置管理規則這個說法也許過于學術化，講白了其核心就是文件如何存放和版本升級。而規則即是團隊共同遵守的約定。比如在某目錄下存放會議紀要，為了便于查找會議紀要的文件名以會議日期開頭，格式是YYYYMMDD。

為什么需要產品開發團隊的配置管理規則？

1，開發團隊是多人組成，規則能夠讓所有人查詢，有依據，協同提供效率 2，產品開發是長期過程，文件會越來越多，如果沒有一定的規則，將造成文件遺失或者難以查找。

誰來制定團隊的配置管理規則？

團隊負責人應當為團隊長遠的信息資產負責，組織團隊成員來商量團隊自身的配置管理規則。 如果團隊存在配置管理員這樣的角色的話，那么配置管理規則的起草和維護當然首先是配置管理員的事情。

團隊的配置管理規則有哪些內容？

對于軟件開發團隊，顯然首要的，源代碼管理是規則重點覆蓋的內容。對于源代碼管理，要回答如下典型問題： 1，選擇什么樣的源代碼版本控制工具？如果組織已經選定，或者歷史上已經選定，那么需要遵循。這是基礎工具，一般不會經常變化，而變化必須經過慎重的考慮，當然往往的這是組織級考慮的內容。所以這個問題對于絕大多數團隊而言，不是問題，因為已經有選定的工具。 2，對于源代碼，選擇什么樣的主干分支模式？ 這是顯著影響團隊效率的選擇，必須團隊骨干一起來做決定，不同的主干分支模式適用于不同的場景，需要團隊中此方面的達人來提供建議，如果團隊內難以做決定，麻煩組織中的高手來設計本團隊的主干分支模式也是應當的，甚至有組織邀請業界專家來為重要產品線設計主干分支開發模式，并制定規則。 3，對于選定的主干分支模式，有哪些操作注意點，具體而言比如如下問題： 3.1 什么情況下從主干拉出分支？ 3.2 什么情況下合并分支到主干？ 3.3 什么情況下從分支拉出分支？ 3.4 什么情況下從主干合并到分支？ 3.5 什么情況下從分支合并到分支？ 3.6 什么情況下刪除分支？ 3.7 如果選擇主干無分支，那么需要注意什么？有什么配套手段？ 4，源代碼檢入時需要遵循什么規則？ 如何書寫檢入說明？ 是否需要與某個變更或者需求或者缺陷進行關聯? 要先本地進行靜態代碼掃描？ 先進行code review？還是后進行掃描，或者code review 5，哪些區域的代碼是信息安全高等級代碼？ 訪問級別比較高，團隊外圍成員需申請后才能訪問？如何申請？? 6，哪些區域的代碼是核心代碼？ 或者是紅區代碼，但凡此處代碼修改，對應的測試范圍需要擴大，關聯到其它的系統？ 7，為了協同工作，在工程師本地電腦上需要如何設置？ 其次是文檔，文檔就存活時間而言，分為兩類：第一類是其生命周期與產品相同；第二類是其生命周期與特定改進、事務或者項目相當，明顯短于產品生命周期。 第一類文檔可稱為產品級文檔，比如團隊配置管理規則就應當是產品級文檔，值得長期得到遵循并改進，此類文檔典型有： 1，產品白皮書，產品介紹 2，產品功能目錄，使用說明，系統功能樹 3，產品應用架構，組件（系統，子系統、模塊）結構圖，組件（系統，子系統、模塊）接口說明 4，產品性能架構，并發控制，處理高性能要求的架構模式 5，團隊章程，團隊改進建議 6，產品待辦需求列表，原始需求
第二類文檔可稱為項目級文檔，此類文檔是大家最熟悉的文檔，如下： 1，項目計劃 2，項目需求規格說明書 3，項目會議紀要 4，項目測試計劃
對于兩類不同的文檔，對于團隊配置管理規則而言，產品級文檔的處理是焦點，因為這是長期的文檔。

團隊的配置管理規則的好處

往大里說，團隊配置管理規則處理的是產品信息資產，當然是值得精心制定并切實執行的。往小里說，良好統一的協同工作平臺能提升團隊協作效率，讓每個工程師順暢的工作。

總結

以上是生活随笔為你收集整理的谈谈产品开发团队的配置管理规则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。