標籤：http io ar 使用 sp 檔案 div on 問題
公司意識到軟體組態管理的重要性，所以開始加強軟體組態管理，但做了幾個月了，效果不是很明顯，而且做這個工作難度很大，主要是大部分開發人員不支援組態管理所要求做的工作，比如公司採用VSS做版本控制，但開發人員基本上都不願意用VSS做check in/check out，所以結果令人很不滿意。請各位高手、專家指點迷津，怎樣才能做好軟體組態管理？謝謝！ 返回IT界網站首頁>>
-
--------解決方案--------
-
培訓+宣傳+強硬措施，讓開發人員在意識上認可，可以抓一些典型的案例。讓他們意識到組態管理是開發的一部分。另外要考慮足夠的可操作性，簡單而實用，避免過多的耗費工作量，否則只能引起大家的反感。
-
--------解決方案--------
-
非常感謝MyStarDream(摘星夢) 的建議，我會試著去做，謝謝！還希望和你繼續交流！
-
--------解決方案--------
-
是啊，我現在就遇到這樣的問題，目前的解決辦法，是個別人員搞特殊化，新員工嚴格按照規範開發！！！！
-
--------解決方案--------
-
如果你使用ClearCase，就可以映射一個VOB到本地硬碟，讓所有開發人員使用這個映射硬碟。
或者在Visual Studio中設定。這就需要MIS部門的管理了。
-
--------解決方案--------
-
在組態管理初期，從公司管理層制定管理政策是必不可少的，畢竟作為一個
組態管理人員沒有多大權利。你能強制項目負責人聽你的指使嗎？
-
--------解決方案--------
-
我也做組態管理，同時也做了CMM流程改善。有如下體會可以大家分享：
1－－寫好必要的操作手冊和支援文檔，把這些標準的文檔發給你的上司，引起他們的注意；
2－－爭取一個小時的時間對大家進行統一的培訓，真樣你就會有一個發揮的時間；
3－－在介紹組態管理和使用組態管理工具的時候，清楚明了，並且強調這是部門的要求，需要所有人員參與配合。大家都可以在實施組態管理過程中得到相應的關於軟體過程管理的知識，體現程式員的基本素質，適應軟體組織發展的要求；
4－－自己要有信心，對同事要有熱情，及時報告結果。
祝所有的組態管理同仁工作順利！！
-
--------解決方案--------
-
謝謝happykarol(咯咯)！你的經驗非常值得借鑒，希望和你多交流！
-
--------解決方案--------
-
1－－寫好必要的操作手冊和支援文檔，把這些標準的文檔發給你的上司，
引起他們的注意；
僅僅是引起注意還不夠，一定要讓你的上司認識到組態管理工作的重要性，從而
獲得上層的支援，否則，作組態管理的人在公司裡可就真是舅舅不親，姥姥不疼
了。上司覺得你的工作可有可無，開發人員又覺得你礙手礙腳，tmd，裡外不
是人。
-
--------解決方案--------
-
我覺得通過行政手段來達到組態管理的目標，畢竟是沒有辦法的辦法了。因為我想大家也都是程式員出身的，知道同事之間的信任關係如何如何重要。
開發人員不願意按照你的組態管理方法來做，有他的意識問題，這時一定要向他們說明工作不是他一個人在做，讓他們明白如果他不這麼做的話，會給別人帶來什麼樣的麻煩。最好有實際的例子。
另外一個更重要的原因可能在於你的組態管理方法不夠合理。比如過程過於繁瑣，Lirayry的規劃不好或不穩定等等。
我在做PM，一起做開發的人一開始也很不理解為什麼要用VSS，也有過這樣那樣的摩擦。最終還是讓他們理解了為什麼要這樣做：
1.至少不用擔心操作失誤造成代碼丟失
2.以前他們經常在自己的硬碟上存有無數個各種日期的版本(我也幹過這樣的傻事)
3.利於大家的檔案交換和更新
4.在測試階段,嚴格對所有要Check In的檔案進行Diff,可以避免版本錯亂.
等等。
-
--------解決方案--------
-
謝謝laolin(老林)同志非常好的意見!我會試著努力的去改變工作方式的.
近段時間我們公司的大部分員工都在使用者現場長時間出差,所以我的工作根本沒辦法開展。不知道是否有必要一個項目組的所有人員都長時間住在使用者那裡做開發?高昂的差旅費、住宿費、補助費等，不知道這樣的項目能不能賺錢？
-
--------解決方案--------
-
> 不知道是否有必要一個項目組的所有人員都長時間住在使用者
> 那裡做開發?高昂的差旅費、住宿費、補助費等，不知道這樣
> 的項目能不能賺錢？
所有的公司大概都想把項目拿回來在公司內部做，以求更高的利潤。到現場做肯定是沒辦法的辦法。不過對於老闆來說，這樣可以減少管理成本和風險。到現場做，往往客戶會對進度和品質把關（？）
-
--------解決方案--------
-
其實我認為只需要一部分人在現場就可以了，沒有必要所有人都呆在那裡，這樣成本太高，而且很多情況下是沒有那個必要。我不知道公司管理員是怎麼想的？如果一個公司所有項目都要在使用者現場做的話，我覺得這個公司一定不是一個好公司！呵呵！我們公司好不好，現在我也不敢確定。見諒！
-
--------解決方案--------
-
只要頭重視，一切都好辦。
-
--------解決方案--------
-
做兩個項目目錄(開發庫/產品庫),利用Share檔案的方法進行Check In/Out,當基準確定時,再利用Branch分離檔案.也許這樣程式員更易於接受一點.
-
--------解決方案--------
-
從個人觀點來看，做到軟體的開發版本管理離真正的CMM2裡的軟體組態管理還是不一樣的。
從組態管理要求有軟體產品的基準：這個基準和我們所說的程式版本的管理還是不一樣的。我想大家都知道軟體和程式這兩個東東的不一樣吧。組態管理裡的要求基準是軟體的基準，把所有可啟動並執行程式，對應的原始碼和文檔歸在一起作為一個基準，從基準開始的更改必須是受控的。而這些任務，必須要有相應的人來完成，這個職責必須明確，但可以由項目組中的人來兼任，未必要專人負責。因而我覺得在公司中開始開展組態管理過程，並不是一定要有VSS這個破玩意兒的啊。
再來說說軟體版本管理工具，開發人員不習慣用這個是因為他們看這個看作公司的制度，而不是看作開發過程中如同IDE一樣必不可少的工具了，樓主反思一下在推行軟體版本管理工具的過程吧。其實，我覺得軟體版本管理工具中，VSS是最差的了。首先，他安全性極差：用過的人都知道，他首先要對相應的檔案夾有寫的許可權才行，萬一有對許可權不滿的人把整個檔案夾XX了....；CHECK－OUT－LOCK這個有時也蠻頭痛的，萬一有人CHECK－OUT了不應該由他CHECK－OUT的東東，而檔案又不可以MULTIPUL CHECKOUT，那就只能找管理員或直接找人去了；VSS好象也不支援BRANCH，這個功能在軟體持久性發展上也是很重要的。
回到組態管理上，我覺得做負責組態管理的人只需要去管理基準就行了。由項目裡的人負責提交整個軟體產品的原始碼，目標代碼，各種文檔，並保證這些東西是在一個版本的，並完全相匹配的，由組態管理的人負責歸檔。當軟體有新的版本發布，或是補丁發布時，亦必須交由組態管理人員負責歸檔。在小的項目中，提交軟體產品可以是專案經理本身，而在大的項目中，提交的則應該是測試組經過測試的東東
-
--------解決方案--------
-
FYI: 《PMT軟體組態管理文集》
http://www.itjie.wang
-
--------解決方案--------
-
我們公司在做組態管理時分了兩個層面，在項目周期內，組態管理在項目中進行，由項目小組成員兼任，公司級組態管理員指導，pm作為支援，當項目結項後，所有產品進入公司級的組態管理，公司級組態管理員專人負責。現在再考慮是否進入基準即納入公司級組態管理。組態管理同時分為開發庫、基準庫和產品庫。
-
--------解決方案--------
-
現在我們公司的做法與dian(點) 一樣，可以多交流。
-
--------解決方案--------
-
我們公司的做法與dian差不多，也是2級控制。希望能夠多交流。
-
--------解決方案--------
-
我們公司一開始也是沒什麼組態管理，大家吃了很多虧，鬧了很多亂子，客戶非常不滿意。。。
經過這些痛苦的曆程，大家現在都強烈認識到組態管理的必要性和重要性，每個項目組都有專門的組態管理負責人，在專案計劃中有完整的組態管理計劃，在開發過程中，大家嚴格按照計劃和要求，把組態管理流程和填寫相關文檔做為一件非常重要的工作來做，這樣使我們的開發和管理有序且有效。
順便說一句，我們使用過VSS,CVS來進行組態管理，還有誰用過其他比較好的工具的，推薦一下？
-
文章來源 IT界
公司意識到軟體組態管理的重要性，所以開始加強軟體組態管理，但做了幾個月了，效果不是很明顯，而且做這個工作難度很大，主要是大部分開發人員不支援組態管理所要求做的工作，比如公司採用VSS做版本控制，但開發人員基本上都不願意用VSS做check in/check out，所以結果令人很不滿意。請各位高手、專家指點迷津，怎樣才能做好軟體組態管理？謝謝！ 返回IT界網站首頁>>
-
--------解決方案--------
-
培訓+宣傳+強硬措施，讓開發人員在意識上認可，可以抓一些典型的案例。讓他們意識到組態管理是開發的一部分。另外要考慮足夠的可操作性，簡單而實用，避免過多的耗費工作量，否則只能引起大家的反感。
-
--------解決方案--------
-
非常感謝MyStarDream(摘星夢) 的建議，我會試著去做，謝謝！還希望和你繼續交流！
-
--------解決方案--------
-
是啊，我現在就遇到這樣的問題，目前的解決辦法，是個別人員搞特殊化，新員工嚴格按照規範開發！！！！
-
--------解決方案--------
-
如果你使用ClearCase，就可以映射一個VOB到本地硬碟，讓所有開發人員使用這個映射硬碟。
或者在Visual Studio中設定。這就需要MIS部門的管理了。
-
--------解決方案--------
-
在組態管理初期，從公司管理層制定管理政策是必不可少的，畢竟作為一個
組態管理人員沒有多大權利。你能強制項目負責人聽你的指使嗎？
-
--------解決方案--------
-
我也做組態管理，同時也做了CMM流程改善。有如下體會可以大家分享：
1－－寫好必要的操作手冊和支援文檔，把這些標準的文檔發給你的上司，引起他們的注意；
2－－爭取一個小時的時間對大家進行統一的培訓，真樣你就會有一個發揮的時間；
3－－在介紹組態管理和使用組態管理工具的時候，清楚明了，並且強調這是部門的要求，需要所有人員參與配合。大家都可以在實施組態管理過程中得到相應的關於軟體過程管理的知識，體現程式員的基本素質，適應軟體組織發展的要求；
4－－自己要有信心，對同事要有熱情，及時報告結果。
祝所有的組態管理同仁工作順利！！
-
--------解決方案--------
-
謝謝happykarol(咯咯)！你的經驗非常值得借鑒，希望和你多交流！
-
--------解決方案--------
-
1－－寫好必要的操作手冊和支援文檔，把這些標準的文檔發給你的上司，
引起他們的注意；
僅僅是引起注意還不夠，一定要讓你的上司認識到組態管理工作的重要性，從而
獲得上層的支援，否則，作組態管理的人在公司裡可就真是舅舅不親，姥姥不疼
了。上司覺得你的工作可有可無，開發人員又覺得你礙手礙腳，tmd，裡外不
是人。
-
--------解決方案--------
-
我覺得通過行政手段來達到組態管理的目標，畢竟是沒有辦法的辦法了。因為我想大家也都是程式員出身的，知道同事之間的信任關係如何如何重要。
開發人員不願意按照你的組態管理方法來做，有他的意識問題，這時一定要向他們說明工作不是他一個人在做，讓他們明白如果他不這麼做的話，會給別人帶來什麼樣的麻煩。最好有實際的例子。
另外一個更重要的原因可能在於你的組態管理方法不夠合理。比如過程過於繁瑣，Lirayry的規劃不好或不穩定等等。
我在做PM，一起做開發的人一開始也很不理解為什麼要用VSS，也有過這樣那樣的摩擦。最終還是讓他們理解了為什麼要這樣做：
1.至少不用擔心操作失誤造成代碼丟失
2.以前他們經常在自己的硬碟上存有無數個各種日期的版本(我也幹過這樣的傻事)
3.利於大家的檔案交換和更新
4.在測試階段,嚴格對所有要Check In的檔案進行Diff,可以避免版本錯亂.
等等。
-
--------解決方案--------
-
謝謝laolin(老林)同志非常好的意見!我會試著努力的去改變工作方式的.
近段時間我們公司的大部分員工都在使用者現場長時間出差,所以我的工作根本沒辦法開展。不知道是否有必要一個項目組的所有人員都長時間住在使用者那裡做開發?高昂的差旅費、住宿費、補助費等，不知道這樣的項目能不能賺錢？
-
--------解決方案--------
-
> 不知道是否有必要一個項目組的所有人員都長時間住在使用者
> 那裡做開發?高昂的差旅費、住宿費、補助費等，不知道這樣
> 的項目能不能賺錢？
所有的公司大概都想把項目拿回來在公司內部做，以求更高的利潤。到現場做肯定是沒辦法的辦法。不過對於老闆來說，這樣可以減少管理成本和風險。到現場做，往往客戶會對進度和品質把關（？）
-
--------解決方案--------
-
其實我認為只需要一部分人在現場就可以了，沒有必要所有人都呆在那裡，這樣成本太高，而且很多情況下是沒有那個必要。我不知道公司管理員是怎麼想的？如果一個公司所有項目都要在使用者現場做的話，我覺得這個公司一定不是一個好公司！呵呵！我們公司好不好，現在我也不敢確定。見諒！
-
--------解決方案--------
-
只要頭重視，一切都好辦。
-
--------解決方案--------
-
做兩個項目目錄(開發庫/產品庫),利用Share檔案的方法進行Check In/Out,當基準確定時,再利用Branch分離檔案.也許這樣程式員更易於接受一點.
-
--------解決方案--------
-
從個人觀點來看，做到軟體的開發版本管理離真正的CMM2裡的軟體組態管理還是不一樣的。
從組態管理要求有軟體產品的基準：這個基準和我們所說的程式版本的管理還是不一樣的。我想大家都知道軟體和程式這兩個東東的不一樣吧。組態管理裡的要求基準是軟體的基準，把所有可啟動並執行程式，對應的原始碼和文檔歸在一起作為一個基準，從基準開始的更改必須是受控的。而這些任務，必須要有相應的人來完成，這個職責必須明確，但可以由項目組中的人來兼任，未必要專人負責。因而我覺得在公司中開始開展組態管理過程，並不是一定要有VSS這個破玩意兒的啊。
再來說說軟體版本管理工具，開發人員不習慣用這個是因為他們看這個看作公司的制度，而不是看作開發過程中如同IDE一樣必不可少的工具了，樓主反思一下在推行軟體版本管理工具的過程吧。其實，我覺得軟體版本管理工具中，VSS是最差的了。首先，他安全性極差：用過的人都知道，他首先要對相應的檔案夾有寫的許可權才行，萬一有對許可權不滿的人把整個檔案夾XX了....；CHECK－OUT－LOCK這個有時也蠻頭痛的，萬一有人CHECK－OUT了不應該由他CHECK－OUT的東東，而檔案又不可以MULTIPUL CHECKOUT，那就只能找管理員或直接找人去了；VSS好象也不支援BRANCH，這個功能在軟體持久性發展上也是很重要的。
回到組態管理上，我覺得做負責組態管理的人只需要去管理基準就行了。由項目裡的人負責提交整個軟體產品的原始碼，目標代碼，各種文檔，並保證這些東西是在一個版本的，並完全相匹配的，由組態管理的人負責歸檔。當軟體有新的版本發布，或是補丁發布時，亦必須交由組態管理人員負責歸檔。在小的項目中，提交軟體產品可以是專案經理本身，而在大的項目中，提交的則應該是測試組經過測試的東東
-
--------解決方案--------
-
FYI: 《PMT軟體組態管理文集》
http://www.itjie.wang
-
--------解決方案--------
-
我們公司在做組態管理時分了兩個層面，在項目周期內，組態管理在項目中進行，由項目小組成員兼任，公司級組態管理員指導，pm作為支援，當項目結項後，所有產品進入公司級的組態管理，公司級組態管理員專人負責。現在再考慮是否進入基準即納入公司級組態管理。組態管理同時分為開發庫、基準庫和產品庫。
-
--------解決方案--------
-
現在我們公司的做法與dian(點) 一樣，可以多交流。
-
--------解決方案--------
-
我們公司的做法與dian差不多，也是2級控制。希望能夠多交流。
-
--------解決方案--------
-
我們公司一開始也是沒什麼組態管理，大家吃了很多虧，鬧了很多亂子，客戶非常不滿意。。。
經過這些痛苦的曆程，大家現在都強烈認識到組態管理的必要性和重要性，每個項目組都有專門的組態管理負責人，在專案計劃中有完整的組態管理計劃，在開發過程中，大家嚴格按照計劃和要求，把組態管理流程和填寫相關文檔做為一件非常重要的工作來做，這樣使我們的開發和管理有序且有效。
順便說一句，我們使用過VSS,CVS來進行組態管理，還有誰用過其他比較好的工具的，推薦一下？
-
文章來源 IT界 http://www.itjie.wang/seprocess/8071230.html
怎樣才能做好軟體組態管理！
