“偉大的使用Visual Studio的程序員，他繼承了整個項目團隊的光榮的傳統，蓋茨大叔這一刻靈魂附體！程序員一個人，他代表了整個團隊良好溝通精誠合作的歷史和傳統！在這一刻！他不是一個人在戰鬥！還有項目經理，架構師，測試人員！他不是一個人！！”
個人程序英雄主義一去不復返了
圖1，程序超人
求伯君！
王江民！
鮑嶽橋！
以及如雷貫耳的蓋茨大叔！
他們憑藉自己的個人才華，在當年用雙手敲出了風靡一時的各種軟件，最終成就了自己，成了令衆人羨慕的英雄。
現在的程序員越來越多，但是“英雄”的名字再也沒有聽說過了。在那個蓋茨大叔認爲“無論對誰來說，640K內存都足夠了”的年代，程序員可以憑藉自己的個人才華，用雙手敲出一個獨立的軟件，一個完整的系統，就像求伯君的WPS，王江民的殺毒軟件一樣。但時至今日，要完成一個比較完善的軟件，對於單個的程序員來說，已經是不可能完成的任務，只能是湯姆克魯斯的“MISSON IMPOSSIBLE”了。Windows XP的代碼超過2000萬行，加上各種其他組件，代碼量接近3000萬，那麼Windows 7的代碼量就更加可想而知。如果現在你還夢想着一個人完成一個系統，我只能說你是程序員中的“唐吉坷德”，是當代的“愚公”！
如果你還做着個人程序英雄的美夢，是時候醒醒了。
你不是一個人在戰鬥
圖2，你不是一個人在戰鬥
從你的座位上站起來，看看人頭攢動的開發大廳：
對！你不是一個人在戰鬥！
現在已經不是一個人就完成整個軟件，包辦軟件整個生命週期的需求分析，架構設計，編碼，測試甚至後期的維護的時候了。現在的軟件開發，已經成爲一個分工明細的工廠化製造。在爲了開發一款軟件而組織起來的項目組中，有負責管理的跟技術無關的項目經理、有負責系統整體架構設計的架構師、有負責編碼實現的程序員、也有負責測試的測試人員。
在以往的時候，項目中的這種種角色，各自使用自己的工具軟件進行工作，長槍短炮齊上陣好不壯觀。項目經理使用Project，Excel等制定項目計劃，進行任務劃分和分配，架構師使用Rose進行架構設計，而開發人員則使用Visual Studio進行編碼，到了測試人員那裏，他們又使用開源的CPPUnit等工具進行測試。這些工具軟件被簡單鬆散地集合在一起，幾乎可以稱得上八國聯軍了。各個軟件之間無法進行信息流的溝通，軟件開發流程和項目管理流程兩者是完全分裂開的，導致信息在項目內部的阻塞，造成項目成員之間的溝通不暢。
微軟看到了這種軟件開發趨於團隊作戰的趨勢，同時也看到了這種近乎單兵作戰各自爲政的現狀，所以在Visual Studio Team System中提供了協同一致的應用程序生命週期管理工具，讓參與軟件開發的各種人員，從架構師到開發人員，從項目經理到測試人員，都能夠更加容易地在整個應用程序生命週期管理(ALM)過程中進行協作。是的，你不再是一個人在戰鬥！
Visual Studio Team System爲項目團隊中的各種角色提供了合適的工具，並且將這些工具以Team Foundation Server爲核心整合在一起，增強了軟件開發團隊中的溝通與協作，使得整個團隊不再是單兵作戰，而是成爲一個有機的整體。
We say UML
在以往的開發中，架構師用各種各樣的圖表來描述系統的架構，而程序員更容易理解的是實際的代碼。當架構師向程序員描述整個系統架構的時候，程序員往往會因爲不熟悉架構師的語言或者表述方式而對系統的架構有所誤解。這就像兩個說着不同語言的人，產生誤解是難免的事情。
現在，我們有了解決的辦法：我們都說UML這種統一的語言。
UML已經成爲了建模語言的事實標準，架構師都習慣使用它來描述系統的各種行爲，而程序員也能夠很好地理解這種建模語言並用編程語言將它們實現。這樣，當架構師和程序員都在說同一種語言的時候，團隊中的溝通就更加順暢了。
圖3，We say UML
在Visual Studio 2010中增加一個新的項目模板，叫做“建模項目”，通過這個模板，我們可以快速創建一系列UML圖，目前可以創建UML 2.x 13個圖中的5個，另外還可以創建層圖和有向圖（.dgml）。
圖4，Visual Studio 2010中的UML圖
在架構管理方面，VSTS 2010通過新的架構瀏覽器(Architecture Explorer)和架構層圖(Architecture Layer Diagram)，以圖形化的方式描述系統架構，從而使得項目中的技術人員或非技術人員都能以模型透過圖形化的方式進行協作，以及定義企業與系統功能。現在連項目經理都可以自豪地說：現在我終於可以聽懂架構師在說什麼啦！
打通團隊溝通任督二脈
一個軟件項目最大的成本是什麼？
硬件投入？不是！
人員培訓？不是！
請客吃飯？不是！
溝通成本！沒錯，溝通成本是一個軟件項目的最大成本。
在一個軟件項目中，因爲溝通不暢而引起的成本隨處可見：需求分析師因爲和架構師溝通不暢，導致架構師的設計並不是客戶的需求；架構師因爲和程序員溝通不暢，導致程序員實現的並不是架構師的設計；程序員因爲和測試人員溝通不暢，導致測試人員並不能完全覆蓋程序員的所有代碼，完成程序員所需要的所有測試工作。可以想象，最後出來的產品跟客戶的真正需求相差了十萬八千里。
項目組中團隊成員的溝通都很重要，但是最重要和最頻繁的溝通應該是程序員和測試人員之間的溝通：程序員需要根據測試人員的測試報告對軟件進行調試，以修復其中的bug；而測試人員也同樣需要程序員提供的代碼更改，進行更加有針對性的測試。爲了打通這項目溝通中最重要的任督二脈，VS2010提供了一系列有力的工具。
在項目實踐中，程序員往往抱怨測試人員提交的Bug無法重現，是一些無效的Bug。現在VS2010提供了一個全新的功能：高級按鍵精靈。它可以全自動錄製測試的整個過程，可回放，可以定製的測試。這樣開發人員在看到測試人員錄製的測試過程之後，可以輕鬆地重現所有Bug。另外，VS2010中也推出了虛擬實驗室自動化處理方案，名爲Visual Studio 2010 Lab Management。當測試人員在虛擬機環境下測試並找到一個軟件Bug的時候，只用一個基本的點擊就可以把整個環境的鏡像點(多個虛擬機)記錄下來。他可以把這個鏡像點的鏈接，作爲附件自動內嵌在Bug報告中，同時可以選擇包含更多的信息，比如帶時間座標的視頻，操作記錄，歷史調試記錄等等。程序員得到這個軟件Bug報告後，不必詢問測試人員到底做了什麼，以及重新配置 Bug重現的環境。只需點擊鏈接，即可得到一個基本的實驗室環境視圖，其中可以包括多個虛擬機環境，他可以用一次點擊就可以恢復所需的整個環境狀態。開發人員就擁有了整個環境，包括歷史環境下的調試工具和代碼，找到導致軟件Bug的事件發生的順序和流程。這樣，重現測試人員提交的代碼再也不是難事了。
另外一方面，程序員在修改代碼之後，測試人員就需要重新運行所有測試用例，雖然代碼修改並不會影響其中的某些測試用例。測試人員常常也會抱怨，程序員爲什麼不告訴他們，哪些測試用例受到影響需要再次運行，而哪些測試用例不會受到影響。爲了解決這個溝通問題，VS2010提供了兩個重要的新視圖：測試影響視圖(Test Impact View)和代碼變更視圖(Code Changes View)。
圖5，Test Impact View
通過這兩個視圖，程序員可以更加了解代碼修改對測試的影響。當開發人員變更代碼的時候，測試影響視圖會分析哪些測試需要運行以驗證代碼變更。這將幫助測試人員只運行必要的測試以對代碼變更進行驗證，從而對簽入的代碼充滿信心。新的測試影響視圖顯示了代碼變更後必須運行的測試的列表，同時顯示了每個測試所影響到的代碼變更。而代碼變更視圖則顯示了所有代碼變更的列表，同時顯示了爲了驗證這個代碼變更所必須運行的測試。這樣就避免了運行全部測試來驗證某一個小的代碼變更所造成的浪費，使得測試更加高效。
用VS2010打通程序員和測試人員之間溝通的任督二脈，自然整個項目組溝通舒暢，神清氣爽，開發效率自然提高不少。