在微软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 软件需求抽象示意图