VS2010已經發布了正式版，在這個新的工具中，有很多地方可以與XP結合。
XP（Extreme Programming）是極限編程，是敏捷編程中的一種。
極限編程中的思路是：
計劃游戲，小版本，隱喻，簡單設計，測試，重構，結對編程，集體所有權，持續集成，每 周工作40小時，現場客戶，編碼標准。
在極限編程中，強調的是人，強調的是靈活。然而極限編程中在VSTS中能有怎樣的結合呢？ 在這裡，我只想說說我淺薄的想法。
在極限編程中的這些思路中，並不是所有的思路點都能在VSTS中得以實現的，這裡，我只列 舉出來我覺的相關的，如有不正確之處，請大家指正。
VS提供了許多版本，架構師的，開發人員的，測試人員的，還有數據庫設計人員的，當然， 在VS中，沒有極限編程團隊中的客戶成員（也可以說成業務分析師）的版本，我們知道，客戶 往往是不懂開發技術的，所以用不上相對應的開發工具，但在TFS中，可以支持word，Excel， 客戶更多標准化的東西可以用office工具來完成。當然，這裡只是說能把一些量化的用word或 Excel 來記錄，而不是說團隊成員之間不交流，交流的結果總是需要記錄或量化的。所以用VS 相應的工具並不影響極限編程提倡的人與人的交互，反而把大家聚到一個統一的開發平台上進 行協作。還有一點是如果使用者覺的TFS2010提供的過程模板（是基於雜MSF5.0的）太復雜，完 全可以定制自己的過程模板來適應極限開發，這是一個開發的平台。還有TFS2010的安裝大大減 化，也為在VS2010中做敏捷編程提供了很大便利。
在計劃游 戲中的結果，我們可以把討論的結果記錄在一些word文檔中，通過VSTS去控制、分發、保存。 當然在計劃游戲中，每個角色都在積累著自己的資源。業務分析人員更多的是描述，模仿業務 的真實場景，架構人員就要從場景中抽象出要實現業務的技術及實現的框架，開發人員思考實 現的方法，測試人員思考測試的種種用例，這些在可能會從自己的角度提出很多問題，大家討 論，分析，解決然後流程再向前推進。
從技術的角度考慮小版本，VSTS也能做的很好， 因為VSTS在版本控制上已經非常完善，只要各個開發與測試到位，很快會通過Team Build來構 建一個新版本的，當然，這裡的小版本是迭代交付的一種版本，把一個完整的大項目，通過分 化依次分批把功能交付客戶。
測試，特 別是單元測試，在VS中提供了非常強大的功能，可以自動生成針對方法的單元測試，並且還可 以批量測試用例。
集體所有權和持續集成分對應VSTS中的源代碼管理和Team Build。在XP中提到的集體所有權 是讓大家都能看到和有權修改不是自己寫的代碼，當然在VSTS中如果權限放開的話，是允許這 樣做的。XP提倡的是所有人都了解整個系統，所以每個人員都能檢查出系統的問題，所以都有 權修改代碼，但這種修改也會有問題，當後者理解有偏差時，就會出現修改錯誤，VSTS可以通 過權限來做到集體所有權，VSTS2010有了自己的“控制面版”，可以方便的來設置 。同時，VSTS中可以存儲用戶的改動及舊版源代碼，可以很容易恢復原有代碼，當然這些修改 與恢復都建立在一定的溝通機制上。集體所有權意味著我們都改動別人寫的代碼，在VS2010中 ，提供了一個“導航”功能，能方便的導般到文件，類，方法等你一時找不到的元 素。持續集成可以對應到VSTS中的Team Build，因為這樣，可以方便快捷的完成一個階段版本 的生成。當然，要求當前迭代中的所有的開發測試工作項完成，才能生成一個新的版本，否則 只是一次Build。
編碼的標准，在VS中可以很好的做到，本身微軟的類庫提供了一系列 標准，並且是通過代碼分析來約定的，當然這個標准如果與自己的標准不符合，可以寫代碼來 生成自己的編碼規則，可以在生成代碼時就提示開發人員。關於這點可參照我別一篇博客《用 自定義代碼分析來標准開發偏聽則暗的開發》 。
當然上面說的全是XP與VSTS結合的使 用，VSTS不是為XP定做的開發工具，所以不可以100%的適合，我覺得可以靈活的運用。還有， XP強調的是人，人的主動性在整個過程中發揮重要作用，但人有自身的缺點，比如存儲性差， 這點可以用工具補上，還有人之間的組織是感性的，可延遲的，用工具會標准化人的一些行為 等等。我個人理解，在小的開發團隊中，如果能更好的協調人與工具，將給團隊帶來更高的開 發效率。
出處http://yuelei.blog.51cto.com/202879/309031
