軟體配置管理中的10個常見錯誤

什麼是配置管理？配置管理是通過技術或其他手段對軟體産品及其開發過程和生命周期進行控制、規範的一系列措施。

配置管理的主要目的是進行工作産品管理，為了見證産品的演化過程，確定産品開發在軟體生命周期中的各個階段都能得到良好的産品配置。其中包括：各類文檔、源代碼、規範、bug等等。配置管理的主要活動包括：制定配置管理計劃、配置項識别、建立基線、建立配置管理系統、版本管理、變更管理、配置狀态報告和配置審計等等。

從上面的描述，我們可以看到配置管理在日常工作中的重要性，它貫穿了整個項目的實施周期，也涉及大量的組織幹系人。配置管理的成功使用，可以大量降低研發因為代碼或檔案版本問題造成的溝通成本。

配置管理能夠完整覆寫整個軟體生命周期，以及所有重要的工作産出，可見配置管理并不是配置管理者一個人的事，而是與所有項目成員息息相關。它通過工作産出，将過程管理與人員管理關聯起來。

不同的組織在實施配置管理活動中常常會産生一些錯誤認知或錯誤的行為，今天我們主要就來看一看這些問題：

01、項目經理兼職配置管理者

很多公司存在這樣的情況，為了節約成本，多人兼職，甚至讓項目經理兼職配置管理的工作，其實這是得不償失的。配置管理工作中除了一些事務類工作外，也有一些周期性的工作，這要求對配置管理工具要熟悉。

項目經理的時間本身也被各事務分攤，需要集中主要力量解決項目的主要工作，例如，對接客戶需求，執行項目計劃，保證項目品質等，如果太多配置管理繁雜的事情讓項目經理來處理，會得不償失，精力也很難顧及，最終影響項目的傳遞程序。

02、配置管理方案不完善

很多組織認為有了配置管理者，有了一套配置管理系統，就可以開展配置管理工作了，實際上這遠遠不夠。配置管理需要一整套完善的方案，包括執行計劃，權限設定，配置審計，基線建立，變更管控，備份機制、主幹分支方案、建構方案等。這些方案都需要被完善的定義，并且被真正地執行，同時所有的執行都需要有完備的記錄和檢查機制。

03、配置管理版本管理混亂

規模較大、周期較長的項目，可能存在配置管理版本混亂的問題，甚至由于文檔缺失、人員更替而連代碼的曆史版本也不清楚，這會直接加大變更分析及确定變更後版本管理的難度。從根本上解決結構混亂問題，需要整理配管理結構，清晰定義多版本、多分支的配置管理，定義清楚編碼與測試d等人員的角色職責、工作流程等。

04、項目無基線，前後端無法對應

基線是下一階段的工作指南和重要參考，沒有基線就沒有比較。例如，每次更新進度計劃表或版本計劃的時候，就要與之前的版本進行逐一比較，檢視存在的差異，分析為什麼會出現差異并将問題記錄下來，下次再出現類似的情況就會把這個差異考慮進去。

再如，每疊代一次的代碼，通常也會建立不同的基線和分支，其目的是不僅厘清不同階段的代碼。基線可以幫助項目經理管理好需求、代碼版本等，達到進行整體監測和控制的目的。

是以，當重大計劃更改時，項目經理需要儲存新的基線。建立變更控制管理流程，一旦出現變更，需要對原來的基線進行備注說明，例如變更内容，影響等。

05、基線變更流程未做嚴格控制

基線一旦建立，一般情況下我們不随意進行變更，如果基線需要變更，需要對變更進行詳細的影響分析和判斷，不能僅僅評某個項目組成員或者項目意願就進行變更， 需要組織CCB進行綜合評估，充分判斷其變更原因，做好影響分析及後續的影響評估，一旦确定基線需要變更，同步通告相關幹系人。當然變更的流程應該制定的更加便捷快捷，同時又能確定變更流程的科學性和合理性，以響應需求的變化。

06、CCB人員配置不合理

CCB即配置控制委員會，在CCB人員定義的時候，重要的是考慮人員覆寫，而不是追求人數。在組織過程改進中，CCB不僅要負責基準建立和變更的審批，還要負責合同、資源、成本、技術等方面的審批，它的作用範圍不是僅局限在配置管理上，而是整個項目，CCB應由來自不同領域的項目利益相關者的代表組成，而且有能力在管理上做出承諾。

CCB一般由部門管理者、商務人員、項目經理、開發負責人、測試負責人、品質保證、配置管理人員等成員組成，不同層次、規模的項目，CCB人員構成也不盡相同。

07、變更控制混亂

配置管理活動中，不管是文檔的開發，還是代碼的編寫，都需要跟蹤執行變更管控流程。在一些組織裡面經常看到“人性化”的一幕，一些系統代碼的修改有時候靠得是“哥倆好”，内部這種傳話式的溝通和工作安排，在沒有嚴格執行變更流程的前提下都是不被認可的，也是不允許的。

有的變更控制，修改哪些，增加哪些，減少哪些，都需要科學執行管控流程，不能因為我們關系好，就可以直接跳過流程，由此産生的所有問題都要被記錄NC，嚴重時需要記錄NC并執行上升機制。

08、文檔與系統不對應

我們經常也看到這樣的場景，系統馬上要傳遞了，但是找不到與之比對的使用者文檔，或者在給客戶教育訓練的時候，發現教育訓練的文檔版本與實際傳遞物存在明顯的差別，這些都是因為文檔與系統對應關系沒有做好。對配置管理熟悉的都知道，系統和文檔通常都是一一對應的。所有系統的變化，與之對應的系列文檔都需要同步進行更新，同時也需要備注修改履曆，其主要目的是能夠在需要的時候進行追溯，保證使用正确的文檔版本。

09、回歸測試入庫無确認

代碼管理是配置管理環節中的重要一環，組織要求所有代碼入庫都需要經過嚴格的測試，需要編寫測試用例，有嚴格的進入退出準則。但是也有很多組織忽視了一個重要環節，那就是回歸測試。一些回歸測試完成的代碼被直接入庫，這裡缺少了重要一環就是與代碼、需求人員的确認，沒有關注回歸測試之後是否産生了關聯問題，忽視了最終回歸測試代碼入庫也需要經過确認這個環節。

10、持續教育訓練不到位

公司配置管理的相關教育訓練不是一勞永逸的，很多組織在實施過程改進初期有很多教育訓練，技術的， 流程的，制度的，工具使用的等，但是到了改進中後期，教育訓練就停滞了。大多數公司裡面一定會有部分人員離職，也會有新人入職，新舊血液的交換，同樣需要我們不間斷地進行這些通用類技能和工具的教育訓練，以保證公司的制度、流程改進是被有效宣貫和持續執行的。

良好的配置管理是項目成功的重要保證。從以往的研發管理咨詢經驗來看：項目中有很多問題是由于配置管理沒有做好導緻的，根本原因是很多人不了解配置管理，不清楚配置管理的意義和作用，配置管理是可以覆寫到整個軟體生命周期的全部重要産出，并且它還能解決很多其他常見問題，最重要的是要規避上述的這些常見錯誤。

更多精彩内容

請關注微信公衆号“賽希咨詢”