在微軟Visual Studio 2010 Ultimate Beta2版本中，MSF for Agile Software Development 5.0過程框架，是以Scrum模型為基礎導向擴展，并且結合了VSTS2010工具的眾多測試功能特性，為更多的從事微軟.NET技術相關的開發人員以實現高質量的軟件產品。
在本文中，筆者將介紹Visual Studio 2010 Ultimate Beta2版本中的MSF for Agile的Scrum和XP敏捷思想與VSTS2010強大的測試功能，通過對這些內容的闡述，讓讀者了解在VSTS2010中的敏捷測試驅動開發方法，以便于.NET開發人員能把敏捷驅動開發為導向的技術，應用在自己的項目和團隊中，從而構筑出敏捷的開發團隊。
1.引言
在前幾篇的文章中提到過的Scrum，相信讀者們都應該已經不陌生了，它的核心在于迭代，并且以每個sprint時間段的周期進行產品功能迭代。團隊首先瀏覽開發需求，考慮可用技術，并對自身技術及能力做出評估，所有實踐是圍繞著一個迭代和增量的過程來展開，而在每個迭代內部，可以使用測試驅動和持續集成的XP(eXtreme Programming，極限編程)工程實踐。
XP，是輕量級的開發流程，其主要的精神是“在客戶有系統需求時，給予及時滿意的可執行程序”，所以適合需求快速變動的方案。Scrum與XP所不同的是，Scrum只是一個敏捷過程框架，它并沒有提供核心的價值觀與指導原則，也缺乏具體的實踐方法，例如，測試驅動開發、結隊編程等。Scrum僅僅規定了實施的基本流程與檢查表，它是一個開放的管理框架，重心在于項目管理，而不是指導團隊成員如何進行開發。這既是Scrum的優點，因為它很靈活，能夠適應大多數場景，也可以兼容并包地引入其他方法學所提倡的實踐;同時也是Scrum存在的固有缺陷，使得它難以被實踐。如果沒有一位的Scrum Master，而團隊成員又缺乏自我組織和管理的能力，會讓開發過程變得一團糟，團隊成員將會無所適從。
在團隊中開發人員隨時可以與客戶進行有效溝通，撰寫user stories以確認需求。簡易快速的系統設計，撰寫獨立的驗證程序以解決特殊困難的問題，并找出演算法即可丟棄驗證程式。規劃多次小型階段的方案計劃，并且以快得速度完成每一階段的程序交付客戶，客戶負責Acceptance tests;Coding前必須完成Unit Test與Acceptance tests程序，所有模組整合前都須經過Unit Tests;開發人員必須快速回應Bug和需求變更;要求二人一組使用一臺電腦設計程序，當一人coding時，另一人負責思考與設計(結對編程);程序必須符合程序規范，并常做程序的重構(Refactoring)。
在Agile開發實踐方面，Scrum可以借鑒XP提倡的結隊編程以及測試驅動開發實現編碼，通過重構對編碼進行調整以適應需求的變化，Scrum為體，XP為用。XP開發流程的基本步驟，如圖1所示。
圖1 XP開發流程的基本步驟
測試驅動開發意味著你要先寫一個自動測試，然后編寫恰好夠用的代碼，讓它通過這個測試，接著對代碼進行重構，主要是提高它的可讀性和消除重復，這將會對Agile Team整體素質要求較高。
時至，Agile Process的精神已經成為共識，但是沒有一種固定的流程可以重復使用在不同的方案上，而且不管是RUP、XP、SCRUM、或其他的開發流程都允許相當大的彈性，我們必須按方案性質的不同，調整或混合出適合的開發流程，并允許團隊在進行中做必要的彈性修改，才能夠達成目標。
2.敏捷之驅動開發
在XP開發實踐中的TDD(Test Driven Development)，它有一個別稱叫 Test-First Programming，要求開發的第一步是根據需求，必須先寫單元測試程序，然后再寫實現程序讓符合需求的測試通過。我們知道XP中的需求是以“用戶故事”(User Story)的形式描述的，而用戶故事實質上是一種軟件“特性”(Feature)。TDD 講的是如何通過編寫“測試”，尤其是單元測試，來驅動軟件的設計和編程。
系統測試從哪里來?來自系統需求。系統需求從哪里來?來自用戶目標，TDD則也不例外。在需求不穩定的情況下，這樣的TDD會有什么問題?會不會帶來許多冗余的工作?答案是肯定的，這樣必然會帶來單元測試的不穩定，這需要敏捷開發人員有相當強的抽象能力，抽象、界定出主要相對穩定需求可以實施TDD。
敏捷團隊可以采用在軟件工程學里有比較成熟的OOAD(Object Orient Analysis & Design，面向對象的分析和設計)軟件開發方法(參見筆者著作《我也能做CTO之程序員職業規劃》的高級程序員技術能力)，在用戶需求層面找到，并抽象出相對不變的需求。OOAD科學分析法體現的是‘現實事實的抽象理解能力’，以業務為中心來分析解決問題，不涉及求解方案。分析階段所做的主要工作是理解問題和需求構模，將現實世界中的問題映射到問題域，從而穩定主要需求。OOAD包括‘設計模式能力’，反映計算機世界來體現現實世界。
分析階段主要是明確用戶的功能需求，滿足用戶所需的系統部件及其結構。設計階段則主要是確定實現用戶需求的方法，即怎樣做才能滿足用戶需求，并構造出系統的實現藍圖。
OOAD方法要求在設計中要映射現實世界中(指問題域，如圖2所示)的對象和實體，如程序員、汽車、項目實施人員等。這需要在設計中盡可能地接近現實世界，以自然的方式表述實體。所以，面向對象技術的優點是能夠構建與現實世界相對應的問題模型(橋梁)，并保持它們的結構關系和行為模式。
例如，我們通常做的系統分析是在假定需求不變的情況下進行的，這樣可以把企業的資源配置到優的程度，但是企業的需求是變化、不穩定的，那么以變化的需求為基礎建立起來的軟件系統當然也不穩定了。需求是項目的根本，既然需求都是不穩定的，那么何以建立起穩定的企業信息系統呢?
圖2 軟件需求抽象示意圖
