[轉]基於Visual Studio 2010 進行敏捷/Scrum模式開發

http://www.infoq.com/cn/articles/visual-studio-2010-agile-scrum-development

根據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個問題：

1. 你昨天作了什麼？
2. 你今天計劃作什麼？
3. 有什麼問題阻礙你的開發進程？

其實這正是對於以前開發內容的檢查，同時也是對後續開發內容的計劃過程。

Scrum模式須要怎樣的工具來實現？

對於使用什麼樣的工具來實現Scrum模式，如今也有不少不一樣的觀點。其實有不少人認爲白板和即時貼就是最好的工具，其實對於小型團隊來講這的確是 最有效並且最經濟的方法。可是若是考慮到軟件公司的管理需求（工做量統計等），遠程團隊，開發工具集成，代碼質量控制，發佈後期支持等等；咱們仍是須要一 個高度集成的平臺和一整套工具來支持咱們的開發團隊。

圖3：白板和即時貼

Visual Studio 2010所提供的集成開發環境能夠知足咱們以上的一系列需求，幫助咱們的開發團隊更好組織開發，幫助咱們的管理層更好地掌控開發過程，幫助軟件公司開發出更高質量的產品。

Scrum模式對於工具的要求，主要集中在如下一個方面：

1. 團隊組織：知足PO （產品經理），Scrum Master （流程經理）和開發團隊管理，以不一樣的權限訪問團隊項目並對不一樣角色提供個性化的信息支持的能力。
2. 產品需求記錄和跟蹤：對於Product Backlog Item （PBI 產品需求列表）的添加，編輯，優先級排序以及交付開發團隊之後進行跟蹤的能力。
3. 流程管理：知足Sprint Planning, Daily Scrum, Sprint Review和Sprint Retrospective這些流程中對於信息共享，信息轉移和跟蹤的能力。
4. 產品質量：在整個開發過程當中，配合Scrum模式達到產出高質量代碼和產品的能力。

下面咱們就看看Visual Studio 2010系統在這4個方面如何知足Scrum模式的需求，並協助咱們開發出高質量的產品。

Visual Studio 2010上的Scrum團隊組織

一個完整的Scrum開發團隊主要由如下角色組成：

1. Product Owner （PO 產品經理）：我喜歡把PO翻譯爲產品經理，由於PO的工做職責就是向客戶和干係人收集產品需求，進行排序並保證開發團隊按照干係人對需求優先級的要求進行交付。
2. Scrum Master （SM 流程經理）：對於Scrum Master我一直沒有更好的翻譯，將其譯成爲流程經理是由於這一角色要保證團隊按照Scrum的方式來組織開發，並協助團隊和PO進行有效的溝通，解決 團隊所遇到的問題。Scrum Master和項目經理的區別在於，他更加傾向於保證開發流程的完整性而不是傾向於知足客戶/干係人的需求。
3. 開發團隊：開發團隊在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模式中的幾個重要的會議包括：

1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review Meeting
4. 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個不一樣測試的不可重現問題：

1. 開發人員本機上的不可重現：IntelliTrace
2. 開發人員和開發人員之間的不可重現：IntelliTrace, tdlog和協做調試
3. 開發和測試環境之間的不可重現：微軟測試和實驗室管理器，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的強大。目前咱們已經在澳大利亞墨爾本和意大利米蘭成功運做了這個課程。做爲在亞洲去惟一貫中國提供這一課程的提供商，我也但願可以和更多的開發 人員分享這些內容。