根據(jù)The Standish Group International， Inc.的研究報告，40%的軟件開發(fā)項目在完成前被取消，33%的項目延期或超支。如果像這樣搞建筑項目，您能夠想象一下紐約城會變成什么樣子？

　　協(xié)同是關鍵

　　從開發(fā)環(huán)境到版本控制，你常常會走過又一個循環(huán)：采購工具，使用培訓，圍繞著工具使用建立內部開發(fā)過程，日常應用等等。希望在合同到期時能夠順利完成并且沒有超支…

　　讓我們來問這樣一個問題：下一步是什么？

　　在你讓開發(fā)小組提高了一點點效率之后，在你配置了開發(fā)工具之后，你仍然需要保持競爭力，下一步改善那里能夠獲得大的生產力？

　　我們要求你看一下目前你周圍的信息組織，你一定能看到不同的開發(fā)小組，同時你也能夠發(fā)現(xiàn)其它許多技術上的協(xié)作者，如文檔、外部資源、客戶、設計人員等等。你將發(fā)現(xiàn)不同的開發(fā)小組的數(shù)量在增加，麻煩也在增加。你還能發(fā)現(xiàn)合作者分散在不同的部門或不同的地方。

　　當你看到這一切時，相信你會認識到項目組織中存在的噪音和混亂帶來了沉重的經(jīng)濟負擔。你將意識到這是下一步提高生產力的突破點，不是其它的技術工具，也不是下一個更快的編譯器。

　　下一個效益增長點將來自管理，簡化技術協(xié)作，使不同的小組以一種更快速而簡單的方式共享工作中的相關信息，從而降低“項目組織中的噪音”，而且使的小組不會被拖住后腿。換句話說，你的下一個效益增長點將來自實現(xiàn)你的信息組織中所有成員之間的協(xié)同工作。

　　“我只需要版本控制，或許是軟件配置管理…

　　何必要協(xié)同呢？”

　　獲得協(xié)同的動機依賴于企業(yè)內信息組織的個體：應用開發(fā)組（如上圖中的Tom），應用開發(fā)管理（如Ann）和技術協(xié)作者（如文檔、幫助平臺和客戶等等），他們參與不同的軟件活動，所以會有各自的看法。

　　例如，讓我們考慮一下Tom，作為軟件開發(fā)組長，他可能在應用開發(fā)和維護領域有特長，因此自然會傾向于采用專門技術，如版本控制等。那么Tom是否需要技術協(xié)作？

　　從哪兒提高生產力，版本控制和軟件配置管理通過加強日常開發(fā)環(huán)境的控制，很快得到了大家的認可。但是它們能進一步提高生產力嗎？

　　許多已經(jīng)使用了版本控制和軟件配置管理工具和軟件組織，很快發(fā)現(xiàn)生產力的提高比預期的要低，下面列出了其中一些原因：

　　不同的項目組使用不同的工具，降低了效率。但搞統(tǒng)一是不合理的，違背自然規(guī)律。

　　不同工具之間有“隔閡”，難于重用數(shù)據(jù)，也減少了項目組之間的交流。

　　已有的版本控制工具不能支持遠程用戶，或者性能明顯退化（如一個基于文件服務器的工具，當在WAN或Internet上使用時，會變得非常遲緩）。

　　考慮到上述因素，很明顯Tom肯定會對技術協(xié)作發(fā)生興趣：

　　建立在版本控制和軟件配置管理之上，提供對信息技術資源的準確訪問。

　　通過無縫訪問不同的版本控制工具促進代碼共享。

　　從任何地方訪問（LAN/WAN/Internet/WEB），改善已有的版本控制工具

　　從其它平臺（通過統(tǒng)一的JAVA客戶端），擴展垮平臺的代碼共享和重用。

　　提供一個具有高度伸縮性的現(xiàn)代化體系結構，使得將工具擴展到其它領域和功能范疇成為可能。

　　StarTeam滿足所有上述需求，它具有：

　　與PVCS和SourceSafe的互操作性，完全的地理位置獨立性，客戶/服務器體系結構，為Internet和WAN開發(fā)環(huán)境特別優(yōu)化，

　　能夠運行在任何JAVA平臺上的統(tǒng)一的客戶端應用。

　　更重要的是，StarTeam支持開發(fā)隊伍建立一個協(xié)同工作的穩(wěn)固基礎的需要。