經(jīng)過需求分析、環(huán)境評估、定制、安裝后，配置管理系統(tǒng)終于完成實施工作了。一個多月的辛苦總算沒有白費，在開發(fā)人員的培訓會上，氣氛活躍、反映熱烈，大家都認為配置管理系統(tǒng)會對今后軟件開發(fā)提供巨大的幫助，徹底的解決由軟件版本不匹配帶來的問題。培訓會議上，大家達成一致意見，今后所有的文檔，代碼，數(shù)據(jù)都要使用配置管理軟件進行管理。SPI(軟件流程改進)人員們也覺得很滿足，這一次的工作竟然是出乎意料的順利，也許要把SPI工作的進度稍微加快一些才好。

　　一天過去了，兩天過去了，一周過去了，一個月過去了。怎么回事?配置管理系統(tǒng)好像不是很對勁啊――配置項明顯偏少，有些配置項Check out的時間竟然超過兩個星期，而有的配置項一天竟然被修改了三十多次，而且經(jīng)常發(fā)生舊版本覆蓋新版本的情況。不會吧?不可能吧?這些問題不應該出現(xiàn)的，我們的配置管理模型是很完善的啊?流程也都考慮了所有的分支情況，角色也都分配了啊，而且也進行了所有人員的培訓，不應該出現(xiàn)這些問題啊。太奇怪了。SPI人員覺得有點不能理解，到底發(fā)生了什么事情了?

　　私人交談，會議，郵件，電話，終于，SPI人員聽到了開發(fā)人員心里最真實的聲音：

　　這么做對我有什么好處?

　　我覺得還是我的方法好。

　　我覺得挺懸。

　　這樣做對我有什么好處?

　　每當提到配置管理系統(tǒng)的好處的時候，下面的句子總會被不厭其煩的用到：

　　建立并且管理統(tǒng)一的基線

　　避免因為版本不一致帶來的混亂

　　更好的保存團隊的工作成果

　　……

　　但是開發(fā)人員會這樣反問：“這樣做對我有什么好處?”。開發(fā)人員學習使用新的軟件，每天都要按時Check out，按時Check in，寫煩人的comment，還要被該死的分支，歸并，集成搞得頭暈腦脹。開發(fā)人員付出了大量的勞動，而他們又得到了什么呢?幾句空泛的口號?一年甚至幾年之后通過CMM 2評估?還是五年之后達到千行代碼0.2個錯誤?但是，這些都與開發(fā)人員本身的利益無關，而且又是如此的遙不可及，又怎么能夠要求大家一如既然，始終如一的付出呢?即使是最勤奮，最有職業(yè)道德的開發(fā)人員，如果始終在做一件根本不會給自己帶來任何利益的事情，他(她)也會慢慢的厭倦。在這樣的情況下面，開發(fā)人員不寫comment，很少做歸并的行為也不是那么令人費解了，因為這是一種希望減輕工作負擔的無奈。要知道，開發(fā)人員不是生產(chǎn)線上的機械手，設定好程序，就可以始終如一、機械的工作下去。如果忽略了人的主觀能動性，要想順利的執(zhí)行配置管理過程幾乎是不可能的。

　　那應該怎么做呢?一方面我們應該考慮配置系統(tǒng)能夠給組織帶來的各種好處，但是另外一個方面，我們絕不能單單只考慮組織的利益，而應該花大量的時間來聲明配置管理系統(tǒng)給每一個開發(fā)人員帶來的好處(自身素質(zhì)的提高、技能的提高、收入的改善等等)，并且真正的讓開發(fā)人員在日常的工作中體會到配置管理系統(tǒng)帶來的好處。只有這樣，配置管理才能真正的融合進入每一個人日常的工作中，成為一種習慣。

　　我覺得還是我的方法好

　　“為什么你不在你的私有分支上工作啊?我們規(guī)定了要在自己的私有分支上工作，然后再歸并到集成分支上的�！�

　　“這個部分只有我一個人開發(fā)，沒有必要再建私有分支了。比起你的方法，我覺得還是我的方法好�！�

　　“但是你這樣做是違反了我們的規(guī)定�！�

　　“可是那樣太麻煩了，直接在集成分支上改又方便又不怕歸并的時候出錯。我還是覺得我的方法好。”

　　“可是……”

　　習慣的力量是可怕的，尤其是舊的習慣被證實是有效的(但不一定是最有效的)。如果我們奢望讓大家忘記舊的習慣，養(yǎng)成新的習慣，請不要寄希望于一次的培訓，也不要指望項目經(jīng)理發(fā)一封郵件就能夠萬事大吉了。因為在軟件行業(yè)中，每一個人都受過良好的教育，擁有發(fā)達的頭腦，而且對自己的判斷堅信不疑!這個時候，我們需要的是說服，用好習慣帶來的好處來說服大家改變，并且要讓大家親身體會到這些好處是如此的實在。而且令人沮喪的是，舊有的習慣還會死灰復燃，這給我們的工作帶來了不少的麻煩，所以我們需要持續(xù)不斷的進行監(jiān)控，一旦發(fā)現(xiàn)舊習慣有再次抬頭的傾向，必須要再次重申新習慣給我們帶來的好處。

　　我覺得挺懸。

　　心理學家經(jīng)過研究得出結論：當人們對于做一件事情的結果不抱希望或者結果不可能達到的時候，往往會選擇敷衍、拖延，甚至逃避這件事情。

　　每當我們談到SPI的時候，我們的目標往往是：“三年以后，我們對軟件開發(fā)進度的預計將達到95%的正確性”，“五年以后，我們將要達到千行代碼0.2個錯誤”。每每聽到這樣的宏偉目標，我覺得挺懸!一個需要三年，五年才能達到的目標能讓大家抱多大的希望呢?尤其是在IT這樣一個流動頻繁的行業(yè)中――等到目標達成的時候，我都不知身在何方了?

　　同樣的情況也出現(xiàn)在配置管理的工作中，我們往往急于樹立一個遠大目標，比如“在軟件的整個生命周期中，建立并且維護軟件產(chǎn)品完整性”。這樣的目標很宏偉，但即使是一個專業(yè)的軟件工程人員也很難用一句話來把它解釋清楚，那它對于一個開發(fā)人員意味著什么呢?也許什么意義也沒有，只是一個口號而已。我們有能力僅僅靠一個空泛的口號就能讓大家奮力向前嗎?不能!我們需要用無數(shù)個短期、可行的目標來構筑這個宏偉的遠大目標。

　　“用半個月時間，培訓所有的員工，讓大家掌握配置軟件的基本操作”。

　　“用一個星期時間，分配所有的角色，并且讓大家明確每個角色的職責”。

　　“一個月后，所有的軟件成果都應該納入配置管理系統(tǒng)的管理中”。

　　“三個月后，CCB正式成立，所有對配置項的修改必需經(jīng)過修改控制流程”。

　　……………………

　　……………………

　　正是這些短期，可達的目標讓我們體會到了我們正在進步，我們的努力是有成效的，更加重要的是，開發(fā)人員的付出換回了成果，積極性得到了保護。激情的火焰能夠燒掉征途上所有的荊棘! 人不同于機器，因此在軟件過程改進的過程中，除了技術(Technology)、管理(Management)，還有人(People)的因素。只有三者兼顧(P.M.T.)，才能取得我們夢寐以求的美好結局。