根據Forrester Research今年第二季度的一份研究報告，在超過1000名專業開發人員中，采用敏捷模式進行軟件開發的已經有10.9%采用了Scrum模式，在所有的敏捷開發模式中名列首位，而在所有的軟件項目管理模式中，敏捷模式更是被35%的開發人員所采用。當然，研究報告為我們呈現的僅僅是一個統計學的觀點，到底你的開發團隊應該采用什麼樣的開發模式，這還是要根據各自不同的開發環境，人員構成，公司架構以及文化背景來決定。
圖1：Forrester 關於敏捷模式的調查報告
Visual Studio 2010 是微軟在2010年4月發布的全新一代的集成開發環境，配合同時發布的Team Foundation Server 2010（TFS——團隊服務器） ，為開發團隊提供了全面的應用程序生命周期管理（ALM）工具和平台。在2010這個版本中，對於敏捷，或者說Scrum模式的支持是前所未有的。雖然微軟的Visual Studio Team System從2005年開始發布的時候就提供了敏捷流程模板（也就是MSF Agile）模板，但是2008版之前的這個敏捷流程模板都是基於MSF（微軟解決方案框架）的；這個框架是微軟針對自己的研發團隊的最佳實踐進行抽取總結出來的，與廣大敏捷開發社區裡面所流行的很多敏捷方法並不是很契合，造成了開發團隊在實施的時候有很多不適用的地方。因此，微軟在開發2010版本的過程中，大量的聽取了敏捷開發社區中的聲音，在自己的MSF Agile 5.0的模板中進行很多針對敏捷，更確切的說是Scrum開發模式的改進，使得2010版本中所集成的MSF Agile 5.0的模板非常適合我們來進行Scrum模式的開發組織。當然，微軟的產品為了追求通用性，在MSF Agile 5.0的模板中並沒有完全采用Scrum模式通行的名稱和流程；同時，微軟在兩周前又發布了一個純粹的Scrum流程模板以供那些希望完全使用Scrum 模式的開發團隊使用，當然這個模板現在仍然是Beta版。
我個人認為，開發團隊采用哪一個模板並不是最重要的，重要的是我們需要在開發過程中不斷地改進過程，並對這個模板進行定制，以便適合我們自己的開發流程。這也是為什麼TFS所提供的是一個模板，因為它的目的就是希望我們在這個模板的基礎上不斷的改進，最終找到適合
自己開發團隊的流程。其實這也很符合Scrum模式的理念；簡單一點來說，Scrum模式是一種針對復雜項目的流程組織方式的框架，其目標是為了讓我們開發出更高質量的軟件產品。圍繞的這個目標，Scrum模式為我們提供一個團隊模型，一系列工具和一個簡單的流程。在這樣一個框架之下，Scrum模式要求我們不斷地改進流程以達到適合團隊的最佳狀態，這種對改進的要求也是Scrum模式區別於其他開發流程的重要特點之一。
為什麼Scrum模式適合軟件開發？
軟件行業至今已經有超過40年的歷史，很多在軟件工程中的管理方法都是在不斷摸索中改進而來的。早期的軟件行業由於規模有限，絕大多數屬於作坊型，幾個人在一起靠著自己的聰明才智創造出軟件產品；但是當團隊規模不斷擴大的時候，開發人員開始需要一種模型來組織越來越龐大的團隊，滿足越來越復雜的需求。因為沒有經驗可循，軟件開發團隊將很多傳統工業工程的方法借鑒到軟件行業，因而出現像“瀑布式”的模型。“瀑布式”模型要求我們在實際的開發工作開始之前進行很多非常細致的設計和計劃，力圖將不可控的開發過程細化成可以控制的顆粒，以達到對復雜項目的總體控制目的。但是“瀑布式”模型忽視了軟件項目的一個本質特點，那就是需求的不確定性；我們不可能像造汽車一樣在上生產線之前把所有的零件都設計好，所有的流程都規定好，再進行裝配；因為任何軟件在實際進行編碼之前都沒有人知道這些代碼應該如何實現，而且每一個開發人員的水平不同，習慣不同，寫出的代碼也是不同的；再加上客戶對於軟件的需求也是在不斷變化的，一年之前的業務流程很可能在一年之後就產生的變化，如果還按照之前的需求進行開發，那麼交付的時候肯定是無法滿足要求的；更重要的事，在客戶沒有看到或者實際操作軟件產品之前，他們永遠也不能明確地告訴你他們要的到底是什麼。因為這種種原因，造成了軟件開發不可能采用傳統的工程方法進行組織，因為其本身是一種需要依賴於開發人員智慧的探索性行為，也造成了我們的軟件項目中有很大一部分是失敗的。
Scrum模式的出現正是基於對於軟件開發行為本質的認識，提供了一種松散的框架，讓我們使用一種探索性的流程方法來組織本來就是探索性的開發過程；從根本上滿足了軟件開發本身對於流程的需求。這種方法論實際上是基於愛德華?戴明所提出的戴明環的管理方法；戴明環理論提出：人類在進行任何復雜活動時，獲得成功的最有效過程要經過：Plan 計劃– Do執行 – Check 檢查– Act改進，四個子過程，並不停的迭代以便找到最佳的方法來解決問題。這個理論不是針對軟件開發提出的，但是軟件開發本身其實就是最典型的復雜活動。
圖2：Scrum的流程
這裡我們再回頭看看Scrum的流程，Scrum的流程主要包含以下內容：
(P) Release/Sprint Planning：發布/迭代計劃
(C&P) Daily Scrum：每日回顧
(C&A) Sprint Review：迭代產品檢查
(A) Sprint Retrospective ：迭代流程檢查
我們可以看到，Scrum模式的流程與戴明環僅僅相扣。有很多認為敏捷模式會弱化計劃的作用，其實不然，敏捷模式更加強調計劃，而且強調更加頻繁的計劃，比如：每日回顧這個流程就要求我們的團隊每個成員每天早上用15分鐘的時間來回答3個問題：
你昨天做了什麼？
你今天計劃做什麼？
有什麼問題阻礙你的開發進程？
其實這正是對於之前開發內容的檢查，同時也是對後續開發內容的計劃過程。
Scrum模式需要怎樣的工具來實現？
對於使用什麼樣的工具來實現Scrum模式，現在也有很多不同的觀點。其實有很多人認為白板和即時貼就是最好的工具，其實對於小型團隊來說這的確是最有效而且最經濟的方法。但是如果考慮到軟件公司的管理需求（工作量統計等），遠程團隊，開發工具集成，代碼質量控制，發布後期支持等等；我們還是需要一個高度集成的平台和一整套工具來支持我們的開發團隊。
圖3：白板和即時貼
Visual Studio 2010所提供的集成開發環境可以滿足我們以上的一系列需求，幫助我們的開發團隊更好組織開發，幫助我們的管理層更好地掌控開發過程，幫助軟件公司開發出更高質量的產品。
Scrum模式對於工具的要求，主要集中在以下一個方面：
團隊組織：滿足PO （產品經理），Scrum Master （流程經理）和開發團隊管理，以不同的權限訪問團隊項目並對不同角色提供個性化的信息支持的能力。
產品需求記錄和跟蹤：對於Product Backlog Item （PBI 產品需求列表）的添加，編輯，優先級排序以及交付開發團隊以後進行跟蹤的能力。
流程管理：滿足Sprint Planning, Daily Scrum, Sprint Review和Sprint Retrospective這些流程中對於信息共享，信息轉移和跟蹤的能力。
產品質量：在整個開發過程中，配合Scrum模式達到產出高質量代碼和產品的能力。
下面我們就看看Visual Studio 2010系統在這4個方面如何滿足Scrum模式的需求，並協助我們開發出高質量的產品。
Visual Studio 2010上的Scrum團隊組織
一個完整的Scrum開發團隊主要由以下角色組成：
Product Owner （PO 產品經理）：我喜歡把PO翻譯為產品經理，因為PO的工作職責就是向客戶和干系人收集產品需求，進行排序並保證開發團隊按照干系人對需求優先級的要求進行交付。
Scrum Master （SM 流程經理）：對於Scrum Master我一直沒有更好的翻譯，將其譯成為流程經理是因為這一角色要保證團隊按照Scrum的方式來組織開發，並協助團隊和PO進行有效的溝通，解決團隊所遇到的問題。Scrum Master和項目經理的區別在於，他更加傾向於保證開發流程的完整性而不是傾向於滿足客戶/干系人的需求。
開發團隊：開發團隊在Scrum模式中是作為一個整體出現的，一般來說團隊的大小控制在3-7個人的規模；團隊作為一個整體向PO負責，而不是每個人對於自己的任務負責。
在Visual Studio 2010 系統中，使用TFS服務器基於角色的權限控制，我們可以很方便地定義出不同的權限范圍。當然，最簡單的方法是把Scrum團隊的角色和TFS的默認角色之間進行映射。
圖4：TFS團隊項目的默認角色
Scrum團隊角色 TFS團隊角色 Product Owner Contributor Scrum Master Project Administrator 開發團隊 Contributor <Builders
Project Administrator
根據團隊不同人員的職責具體分配 項目干系人 Readers 如果客戶願意更直接的參與項目，可以允許他們直接訪問TFS。表1：Scrum團隊和TFS團隊角色映射
Visual Studio 2010系統中對需求記錄和跟蹤的支持
Scrum模式中的需求主要是采用Product Backlog Item（PBI產品需求列表）和Sprint Backlog Item （SBI 迭代需求列表）來進行管理的，在Visual Studio 2010系統中，直接提供了針對這兩個列表的工作項查詢，並且還提供了Agile Workbook （敏捷工作簿）幫助我們更好對工作量和任務分配進行調控。
圖5：使用MSF Agile 5.0模板創建的TFS團隊項目集成了對PBI和SBI的管理功能
圖6：Product Backlog 查詢結果
上圖中就是使用TFS內置的Product Backlog查詢獲取的產品需求列表，這個列表是PO使用的主要工具，我們可以注意到這個列表已經根據Stack Rank列進行了排序，這也反映了產品需求列表的特性：需要根據客戶/干系人對需求項的優先級向團隊交付任務；而PO的除了需要不斷完善這個列表，還需要不斷和客戶干系人進行溝通，一邊確定這個優先級。
在Scrum模式中，對於優先級的定義決定於兩個因素：需求的商業價值和緊迫程度；另外一個重要的指標就是Story Point，這個指標標志著當前需求項的相對大小，注意這裡說的相對大小，很多人將這個值理解為人天或者人時，其實是不准確的，因為在PO准備產品需求列表的過程中，僅憑PO的經驗是很難准確的判斷出以時間為度量的工作量的，但是相對的大小是比較容易判斷的。
另外，從State和Iteration Path兩個列的值我們可以看到，已經有一些需求在迭代1-2中已經解決。根據這些信息，PO可以很容易的對工作進度和剩余需求進行管理。
另外一個重要的查詢就是Iteration Backlog查詢：
圖7：Iteration Backlog查詢結果
Iteration Backlog 中包含了團隊在某個迭代中需要完成的需求以及針對這些需求細化出來的具體開發/架構/測試等任務。在Visual Studio 2010中，微軟終於開始支持樹形結構的工作項關聯，從上圖可以看出，每一個User Story的下面都掛接著相應Tasks，這些任務是在Sprint Planning Meeting中由團隊成員自己根據PO對需求的闡述進行的細化，同時團隊成員還需要根據經驗對這些Tasks進行估算，給出基線估值（Original Estimate）。在開發過程中，團隊成員在每天的Daily Scrum之前需要對前一天的任務更新狀態（State），已完成工作量（Completed Work）和剩余工作量（Remaining Work）字段的內容；通過這些信息我們就可以使用TFS自帶的燃盡圖報表對進度進行查詢和預測了。
實際上，純粹的Scrum模式並不關心已完成工作量（Completed Work）也就是以完成工作量的值，但是對於使用人天/人時等信息來衡量團隊工作量，甚至依賴這些數據想客戶收取開發費用的咨詢類公司來說，這些信息是非常重要的。
Visual Studio 2010對Scrum流程中重要事件的支持
Scrum模式中的幾個重要的會議包括：
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review Meeting
Sprint Retrospective Meeting
這一系列的會議是真正體現Scrum模式對於開發流程控制的核心內容，在Scrum模式中另外一個非常重要的概念是：時間箱（Time Box），它要求我們對於流程中的事件進行非常嚴格的時間控制。很多人在開始進行Scrum模式開發的時候的一個普遍問題是：一個迭代（Sprint）的長度應該是多少？對於這個問題其實也沒有標准答案，而必須根據團隊的大小來進行判斷。對於之前我所建議的3-7人大小的團隊，我會建議采用2周的迭代長度。原因在於1周太短，團隊還無法完成真正有商業價值並可以進行交付的需求；而3周的時間則太長，需求的變化所造成的風險會變得比較大。
采用迭代式開發的時候其實長度是越短越好，我們總是盡可能的縮短迭代以便可以通過給客戶的交付獲得更有價值的反饋以便對後續的開發進行調整，因此這個長度應該是團隊剛剛可以完成可交付需求的最短時間。我們需要嚴格控制的是，迭代的長度應該是一個時間概念兒不是工作量的概念，也就是說如果2周的時間已經耗盡但是團隊還沒有完成當前迭代中的所有需求，那麼也必須結束迭代進行交付，而不能選擇延長迭代來完成未盡需求。這樣做的結果有兩個：1）當前的迭代會以失敗告終；2）通過對已經完成需求的交付，我們可以獲取客戶的反饋。很明顯，失敗的迭代是我們不願意看到的，但是客戶對於已經完成需求的反饋比保持常勝將軍的名譽更加重要，因為後者是保證我們軟件質量（符合需求）的重要手段。
當然，這裡隱藏著另外一個很重要的問題，在團隊無法完全完成需求的情況下如何還能提供可交付的成果，這就要依靠我們對於需求定義方式的變化和 Visual Studio 2010 中對持續集成和更加高效的測試支持來實現了。在需求定義上，我們需要采用業務導向的需求定義，保證每一個需求的完成都可以交付一定的商業價值。以往的需求往往是功能導向的，但是功能導向的需求對於用戶來說不一定具備商業價值，但是業務導向的需求則可以保證這一點，比如：我們可以這樣定義一個User Story，作為市場經理，我希望對客戶數據進行查詢以便可以找到本市的客戶並和他們進行聯系。使用這樣的需求定義意味著只要我們完成這一需求對客戶就是有價值的，因為它不是一個功能碎片，而是一個用戶交互用例。如果在一個迭代中我們無法完成所有的需求，只要完成其中一個，那麼都是可以向客戶交付的。另外，借助Visual Studio 2010對持續集成和測試的支持，我們可以采用每日構建的方式保證所有完成的代碼都符合質量要求，也就避免了在迭代後期進行集中測試而拖延交付的可能性。
Sprint Planning Meeting的支持
在Visual Studio 2010中提供了一個叫Agile Workbook的Excel模板，可以幫助我們很好地完成Sprint Planning Meeting。在這個會議中，最重要的任務就是將PBI轉化成SBI，並且由團隊給出完成這些SBI的承諾；團隊要做出這樣的承諾最重要的依據就是這些需求所涉及的工作量是否可以承受。Agile Workbook正是幫助我們回答這一問題的強大工具。從下圖我們可以看到，當我們制定了迭代上的人員配備並將Task分配給每個開發人員以後，模板會給出非常直觀的柱狀圖，幫助團隊判斷工作量是否可行。
圖8：對迭代1-3上的工作量進行橫向比較，根據歷史數據判斷後續迭代是否可行
圖9：在當前迭代上對每個開發人員的工作量分配進行比較
Daily Scrum Meeting支持
這個會議非常簡短，所以我們更加需要非常直觀的圖表以幫助團隊對進度進行審核，在TFS中提供了燃盡圖為團隊提供這些信息。
圖10：迭代燃盡圖
根據每個開發人員對於工作量的更新，從上圖我們可以很容易對完成時間進行預測，圖中黑色實線和橫軸的焦點就是當前迭代的可能完成時間。
Sprint Review & Retrospective Meeting 的支持
Sprint Review的支持更多地體現於Visual Studio 2010的持續集成能力，因為這個會議是對於需求完成情況的審核，如果我們能夠保證需求是業務導向的並充分利用Visual Studio 2010的自動化構建和測試集成能力。那麼我們就可以保證在這個會議上交付一定的商業價值。具體如何使用Visual Studio 2010來實現在後面做詳細介紹。
Retrospective 會議其實非常簡單，需要我們團隊成員對當前迭代的運作進行總結，但為了使這些信息可以完整的保存以便後續使用，我們可以利用TFS提供的門戶站點，定制一個SharePoint的列表分類的記錄這些反饋以便團隊查詢。
Visual Studio 2010對於產品質量的保證
提高產品質量是Visual Studio 2010在設計階段就確定的重要目標，在2010版本所添加的新特性中，已經想著這個目標形成了一套完整的解決方案。對於Scrum模式來說，交付高質量的產品也同樣是其終極目標，而且我們需要在迭代時間很短的情況下仍然保證質量，這就更加需要依賴工具的支持。
自動化構建
之所以把自動化構建列在首位，是因為軟件工程發展到今天，自動化構建已經是任何一個想要實現高質量的軟件開發團隊都必須采用的工程方法；另外，對於 Visual Studio 2010系統來說，自動化構建也起著承上啟下，貫穿全局的重要地位。當開發軟件進入第一個迭代的開發時，所要進行的第一項工作並不是開始實際的編碼，而是創建出符合團隊需求的構建模板。這樣做的目的在於團隊在後期的實際開發中可以更加專注於需求的開發，而不必花費額外的時間和精力來集成開發人員的代碼；開始階段的代碼量很少，團隊可以有更加清晰的思路將遷入策略，架構驗證，自動化測試列表設置好並保證構建可以正常運行；如果把這個工作放到迭代後期進行，往往會因為代碼中的缺陷和不同開發習慣造成構建模板不能正常運行。
在Visual Studio 2010中，提供了更加便捷的模板創建工具，特別是添加了Gated Check-in 構建的觸發方式，可以保證所有嵌入源代碼庫的代碼都是經過驗證的。
圖11：Gated Check-in 構建觸發器
Gated Check-in 觸發方式和以往的觸發方式所不同之處在於，開發人員執行遷入操作的時候代碼並不會直接進入源代碼庫，而必須先經過構建的驗證：保證編譯成功和定義好的遷入驗證測試可以成功運行，然後TFS才會把代碼真正嵌入服務器。之前的持續集成（Continuous Integration） 方式也會在遷入的時候進行構建，但是這種構建是將代碼先遷入，然後再運行構建，如果代碼中已經存在了缺陷，那麼在服務器上就會留下缺陷代碼；Gated Check-in 借助TFS源代碼管理中的“擱置”功能，先把代碼擱置到服務器上臨時存儲中，在構建成功後才會正式遷入，所以缺陷代碼不會進入服務器。
圖12：構建參數配置
TFS的自動化構建可以集成測試列表，圖中的上方的紅色區域中就是要求構建從項目文件中的測試列表文件中提取單元測試並自動運行；另外一個在 Visual Studio 2010種的重要改進就是下方紅色區域中的架構驗證參數。如果我們的項目文件中包含了架構層次圖（Layer Diagram）的話，那麼我們就是添加這個參數讓構建自動的驗證項目的代碼是否符合架構設計的要求。
圖13：Visual Studio 2010的層次架構圖 Layer Diagram
Scrum模式開發中的架構設計給我們提出了非常大的挑戰，由於我們采取業務導向的需求定義，開發人員必須從數據層一直實現到表現層；在這個過程中如何保證項目的架構仍然符合需求非常困難；而Visual Studio 2010的架構驗證功能則可以幫助我們在每次遷入代碼的時候都進行驗證，保證違反架構規范的代碼不會進入最終的交付產品。
消除無法重現的Bug
無法重現的Bug一直都是困擾開發人員的問題，開發環境，測試環境，生產環境的不同；開發人員，測試人員和最終用戶的不同都是造成Bug無法被重現的客觀因素。在Visual Studio 2010中，提供了很多強大的調試和測試工具來幫助我們解決這個問題。
IntelliTrace（歷史數據調試）
協作調試
測試管理器和手工測試（Test Manager）
實驗室管理（Lab Manager）
IntelliTrace——歷史數據調試器
IntelliTrace在開發過程中的名稱就叫Historical Debugger （歷史數據調試器），後來這個用來進行市場宣傳的名稱反而不能反映它的實質。IntelliTrace可以把程序運行過程中的所有歷史數據都記錄下來，使得程序員可以回滾到任何的歷史點來查看程序狀態，這對於開發人員調試復雜邏輯非常有用；之前我們在做同樣工作的時候必須反復運行程序，以便找到問題，而現在則可以讓程序反向運行。
圖14：IntelliTrace調試器重所記錄的程序歷史數據
另外，IntelliTrace還可以把這些調試數據另存為tdlog文件；當開發人員A發現了B的一個問題的時候，他可以把自己調試環境中的 tdlog發送給B，開發人員B就可以使用這個文件讓Visual Studio恢復到開發人員A的調試狀態，從而保證B可以有效的重現A所看到的問題。
協作調試
協作調試實際上解決多個開發人員在調試過程中的另外一些信息共享問題的方法，上面的IntelliTrace可以共享調試歷史數據；但是用過 Visual Studio 的開發人員都知道，像“斷點”是不能保存到調試數據中，也不會被保存到項目文件中；所以協作調試就提供了開發人員共享斷點信息，並且還可以讓開發人員在斷點信息上添加一些說明，以便幫助其他的開發人員理解問題。
測試管理器和手工測試（Test Manager）
測試管理器是Visual Studio 2010系統中為測試人員特意開發的可以獨立運行的測試環境，它完全獨立，不依賴於Visual Studio IDE，提供非常強大的測試錄制等功能。在前面介紹構建的時候我曾經將單元測試集成到構建中去自動運行，但是單元測試只能針對後台邏輯進行，不能解決UI 測試，或者叫黑盒測試問題。微軟的測試管理器的出現，就是為解決UI測試的問題。
TFS 2010中專門提供測試用例（Test Case）工作項類型，這個工作項允許測試人員對具體的測試步驟進行設計，並且給出預測的結果；同時，借助測試管理器的錄制功能，還可以把測試人員換的操作全部都錄制下來，一邊後來自動播放；或者生成Coded UI 測試，一旦有了Coded UI測試，我們就可以把這些針對UI的測試也集成到自動化構建中去。
圖15：測試用例（Test Case）工作項
實際上，真正可以使用單元測試覆蓋的測試僅占所有的測試的30%都不到，另外這70%的測試以往都是依賴於測試人員手工的進行；現在借助微軟測試管理器的功能，我們可以將這些測試集成到高度自動化的開發流程中。可以幫助我們更加快捷的完成測試，為開發人員提供反饋。
在Scrum模式中，業務導向的需求也要求我們的測試團隊可以更加快捷的給出測試結果，前一天完成的需求最好可以在第二天就將測試結果反饋給團隊；依賴於每日構建，我們可以在每天晚上將前一天的代碼生成一個新版本，共測試團隊使用；測試團隊在第二天就可以把測試結果反饋給開發團隊，同時將可以自動化運行的測試繼承到每日構建中；在第三天的時候我們的團隊就可以利用這些已經自動化的測試來驗證我們的程序了。
由於每天都進行測試，那麼新增的代碼量就非常有限，也就使得Bug的數量可以得到有效的控制，從這個方面上說，測試管理器所提供的手工測試，自動化測試錄制和回放，並且和構建的繼承為我們提供了一個非常高效的高質量的開發平台，從流程和工程技術上為質量提供了保證。
實驗室管理（Lab Manager）
實驗室管理是我在Visual Studio 2010系統中見過的最酷的功能，也是微軟繼承了自己的多項產品為開發團隊提供的最完整的測試解決方案。在測試中一個非常難實現的問題，就是對於不同環境的創建，還原和狀態的保存。如果同一個用例在不同的環境中運行，結果往往是不同的，而且我們客戶的使用環境也往往很復雜，所以就要求我們的測試人員可以搭建很多不同配置的測試環境，以便驗證應用程序可以適應他們要求。
微軟借助自己的Hyper-V虛擬化平台，為測試團隊搭建這樣的測試環境提供了非常好的支持，比如：我們可以使用SCVMM和TFS協同工作，當 TFS需要測試環境的時候，通過SCVMM部署一台符合要求的虛擬機，並把需要測試應用自動的部署到這個虛擬機中，最終在這個環境中運行指定的測試。這樣的測試環境避免了測試人員自己的機器不干淨而導致的結果偏差，而且還可以通過環境快照的方式吧虛擬機的某個狀態直接交付給開發人員進行檢查。
在上面所介紹的這些功能中我們可以看到，實際上我們解決了3個不同測試的不可重現問題：
開發人員本機上的不可重現：IntelliTrace
開發人員和開發人員之間的不可重現：IntelliTrace, tdlog和協作調試
開發和測試環境之間的不可重現：微軟測試和實驗室管理器，Hyper-V
這些功能在工程技術上為團隊保證了高質量，同時配合Scrum模式所推行的時間箱管理，業務導向的需求定義以及流程上的保證，Visual Studio 2010系統和Scrum一起幫助我們創建更好的產品和更好的團隊。
結束
我使用Visual Studio Team System是從2005年開始的，最初的目的只是為了滿足遠程遷入代碼的需要；但隨著2008和2010版本的發布，對於流程定制和整體性的質量解決方案的需求越高。幸運的是，這個時候公司為我提供了到澳大利亞接受Scrum Master培訓的機會，使我可以體系化的了解了Scrum模式的精髓，回來之後就對我們的開發團隊進行了一系列的優化。
同時，作為Scrum Master我也同時獲得了提供Professional Scrum Developer培訓的機會，PSD課程是微軟和scrum.org共同開發的一套基於實踐的scrum開發人員培訓課程，它使用Visual Studio 2010系統作為平台，將參訓人員分為不同的團隊，進行實際的開發工作，在開發的過程中讓學員體會Scrum的妙處和Visual studio 2010的強大。目前我們已經在澳大利亞墨爾本和意大利米蘭成功運作了這個課程。作為在亞洲去唯一向中國提供這一課程的提供商，我也希望能夠和更多的開發人員分享這些內容。
