轉給大家一起分享!
如何擺脫配置管理的尷尬局面(摘自《程序員》）
在質量體系的諸多支持活動中，配置管理處在支持活動的中心位置，然而現實的配置管理一直在項目中處於尷尬的地位。如何才能使得配置管理在項目管理和質量管理中成爲“主角”？通過個人的經驗，我認爲配置管理只有深入到項目中，參與到項目管理和質量管理活動中，這樣才能是配置管理做的有聲有色。下面結合工作中的實際經驗來談談怎樣擺脫配置管理的尷尬局面。
匹配項目計劃的配置計劃
在這個標題中很強調兩個字“匹配”，原因是我們的很多配置管理計劃是爲了計劃而計劃，是脫離項目總體而杜撰出來的計劃，例如配置項識別不是依賴任務來識別的，配置項驗收準則和任務完成標準不匹配等等。
對此，我的建議是：第一，配置計劃作爲項目計劃的從屬計劃，必須依賴在項目計劃中有所反映；第二需要明確的是配置計劃是項目經理，非配置管理員；第三，配置任務的相關任務以及屬性需要和項目任務的屬性進行匹配；第四，匹配管理任務的責任人應該是非配置管理員，而是相應任務的責任人，配置管理是任務的“驗證人”和“審覈人”。只有這樣配置計劃和項目計劃同呼吸，配置活動才能活起來。
生命週期映射配置基線
基線的邏輯是來自項目中採用的生命週期以及子生命週期，有些項目經理和配置管理員對基線產生邏輯不清晰，往往把項目的里程碑作爲基線的識別標準，對於一個很瀑布模型的項目來說可能這樣的方式是可以的，但是如果遇到多個生命週期疊加使用，這種基線識別方式可能會造成基線缺失，從而配置管理也就變得無意義，所以我的建議是：
1、配置管理員自身學會看懂和熟悉項目生命週期，從生命週期看項目版本發佈策略；
2、項目組要有正式基線發佈活動，活動責任人應該是項目經理；
3、基線後謹慎看待變更，基線化後的配置項需要執行變更過程，但是不要讓變更成爲基線的瓶頸，抓住變更的關鍵點，簡化變更過程對現有項目工作的影響和衝擊。
變通的變更控制
變更無處不在，現在很多項目中變更過程非常複雜，造成這種情況的一個重要原因就是很多人包括配置管理員對變更過程比了解。對此，我建議：第一，成立虛擬的CCB組織，CCB建議一定要把項目經理/OA需求人員以及項目中部分資深人員納入到組織中，並定義好活動的方式;第二,根據變更引發的原因和涉及的範圍,分級變更過程;第三,注重變更過程的實質,而簡化變更形式.第四,變更記錄建議注重信息本身而非信息載體,例如變更的原因分析,變更的影響記錄以及修改的主要內容需要細緻化,而對需要什麼類型的文檔來記錄就不要太多的關心.
全新的配置審計
很多公司常常把配置管理劃分到質量管理範疇,其一重要原因是配置審計存在,一個充分有效的配置審計可以折射出很多質量管理上的問題,所以可以說配置審計是質量管理非常主要的手段.對於如何做好配置審計可以參考如下建議:
1、加強配置項納入基線庫時的配置審計，重點在於配置項是否符合驗收標準，相關的活動是否到位，信息是否完整；
2、對變更過程的審計，一方面審覈全過程的記錄，另一方面審覈變更評審的有效性上；
3、功能審計，學會把配置想和需求結合起來，通過需求來審覈需求和配置項的一致性；
以上概述瞭如何擺脫尷尬局面的一些建議，另外針對配置管理員還要是建議加強基本理論和概念的自我學習，下面介紹一下配置管理中幾個關鍵概念與大家共勉：
基線
關於基線的概念，IEEE的標準定義是“已經正式通過複審覈批準的某規約或產品，它因此可以做爲進一步開發的基礎，並且只能通過正式的變化控制過程改變”，在實際的項目中如何去理解基線？
配置納入基線必須通過正式的審覈動作，這種審覈可以是正式的評審活動，例如需求規格書納入基線必須通過評審，且評審問題關閉；也可以是正式的郵件批覆，例如某些項目組工作的約定；對於代碼類的配置納入基線可能就需要通過測試纔可以了，所以如何審覈需要根據情況而定，至於如何約定通常是在項目計劃時完成這些約定工作；
那些配置項需要進入基線，首先說對於代碼類的配置項，例如源代碼、執行代碼以及數據庫腳本之類的肯定是需要納入基線的，對於文檔類配置項，我認爲需要從以下幾個角度考慮：
1、配置項是不是某些活動的輸入或是輸出，如果是可以考慮納入基線；
2、配置項是否是第三方的輸入或是輸出，如果是可以考慮納入；
3、配置項在項目生命週期過程中是否會發生變更，而且發生變更後對其他關聯配置項產生影響，如果是可以考慮納入基線；
如果納入基線的配置項發生了變更怎麼辦，照基線的定義來看是需要通過正式評審，但是實際操作也並非全部如此，關鍵是定義好變更過程的觸變條件。
從項目管理上考慮，基線是類似里程碑的概念，不同的是里程碑只是時間軸，基線不僅僅涵蓋時間更包含了配置項集合；理解的基線的定義那麼到底如何確定基線？從時間軸來看，基線時間點的衍化路線是這樣的：項目SOW→項目里程碑→項目生命週期
→基線時間點；從配置角度來看，基線的配置項要看項目的版本發佈策略即項目的生命週期的模型選擇。
變更控制
變更控制的目的並不是控制變更的發生，而是對變更進行管理，確保變更有序進行。對於軟件開發項目來說，發生變更的環節比較多， 因此變更控制顯得格外重要。變更的標準過程無外乎包括以下四個環節： ①變更申請；②變更評估；③變更實施；④變更驗證。但是如何使這個簡單過程成爲有效，可能需要考慮以下幾個方面：
1、變更的原因，變更可以分成兩類：第一類來自客戶的變更引起的變更，例如客戶需求發生變化等，第二類是在項目內部的變更，例如評審或者測試發現的缺陷導致的變更。針對第一次變更，最要防止客戶直接向開發人員提出變更，所以在項目之初必須明確客戶如何提需求，具體負責人是誰，提出的流程是什麼的，具體要求是什麼，對於項目組同樣要設定專門的負責人，統一接受需求；對於第二種變更也制定內部提出和解決的責任人，接口越少出現問題的機會就越小。
2、變更流程的策劃，雖然變更過程只有簡單的四個環節，但是如何把四個環節串起來，不同的項目是不同的，即便在同一個項目中，不同的變更類型可能觸發的流程應該不是一樣的，例如需求變更，如果這個需求超出合同約定，那麼需求就可能向總監甚至商務人員介入，如果這個需求只涉及到一些參數的修改，可能執行變更過程也不需要那麼複雜吧。建議是我們的項目組在項目計劃之時規劃好不同類型的變更走那個類型的變更。
3、崗位與職責，執行這個流程需要設置那些崗位，賦予這個崗位什麼樣的職責。
4、變更控制的核心要素，很多軟件企業的項目組一味照搬配置管理理論，沒有真正理解變更過程，我認爲變更控制關鍵要素是控制其中的幾個關鍵要素就可以：變更過程有記錄；變更的配置項和相關聯配置項要周知相關小組或者個人;對影響和承諾進行要進行評估;確保基線庫中的配置項版本和開發人員使用的版本一致.
只有配置管理員自身活動起來，配置管理自身過程形成體系,項目組的配置管理意識才能有所增強,配置管理過程才能被項目組接受,希望通過這篇文章能給與處於困境中的配置管理員以啓示.
——摘自《程序員》2007年10月
轉載請註明源自www.SCMLife.com,請保留版權. 本貼地址：http://bbs.scmlife.com/viewthread.php?tid=9496