Visual Studio 2005 Team System概述

简介
今天，企业要获得成功，就必须正视构建和维护日益复杂的信息技术 (IT) 解决方案的需求。此外，他们

还要借助于新技术来拓展业务功能并开发全新的业务机会。自 IT 部门接受了技术支持任务的那一刻起，

他们便成为绝大部分业务策略中的关键角色。

企业当然希望能从他们在 IT 项目的投资中获得最大利润，这就意味着 IT 部门需要在越来越大的压力下

多快好省地完成工作。对更高成本效益的追求使得 IT 项目的预见性需求日渐增加。然而，这样做通常造

成繁琐的过程和对成本消耗的监控，这只不过是将费用转嫁到不同的问题。付出的代价是开发机会的时间

投入以及膨胀的 IT 预算。

复杂的应用程序需要多支训练有素的开发团队来实现。对于开发团队作出的任何主要承诺来说，信息交流

都是成功的一个基本元素。新的 Visual Studio Team System 扩展了 Microsoft 的优秀功能，即，通过

提供与业务紧密集成的、可扩展的、能够增加成功几率的生命周期工具，从而为用户提供高效的工具。能

否成功主要取决于，为了降低交付解决方案的复杂性，团队间是否进行了充分的交流。

构建 IT 解决方案的挑战
尽管许多 IT 解决方案项目的工作产品是软件，但生成软件并不是项目的目标。相反，软件是实现目标的

手段 — 驱动不同的业务价值。要应对风险并增加成功的可预见性，大多数 IT 部门转而采用各种各样的

工具和过程来支持 SDLC。大部分旨在提高软件开发效率的尝试均不尽如人意。这些尝试要么在实现时过

于繁琐，并未达到预期的目标，要么根本无法切中团队开发中令人感到苦恼的要害问题。

• 信息交流：重要的大型应用程序由团队构建，这其中有大量可能从未编写过代码的参与者，包括：业务

发起人、项目管理者、架构师以及测试人员。更甚之，团队本身已演变为地理上分布更广且更专业化。角

色的差异导致许多问题无从解决，或者无意识地对计划产生了分歧。为了使团队有效地运转，就必须理顺

信息交流流程，而且必须让它与成员的日常工作行为相吻合。
 
• 工具捆绑：近些年来，在 SDLC 工具领域中已经大量使用了捆绑手法。但是，仅仅是捆绑工具集合并不

能实现工具集成。这只是建立工具包。由于角色限制，非集成工具（无法支持工具间的自动数据流）之间

就产生了矛盾。集成性的匮乏就必须通过手工干预进行弥补，而由此可能产生其他一些问题。在数据层进

行集成，能够使数据流自动化跨工具和常规报告实现。
 
• 不合适的过程：使过程采纳变得复杂的原因是存在一个矛盾，即开发人员在许多生命周期过程中既是最

关键的一环，又是最薄弱的一环。不适合团队成员（特别是整个开发团体）工作风格的过程，将遭遇到明

显地阻力。面临的挑战就是平衡可预见、可重复过程的生产效率和创新。当未形成这种平衡时，每一个人

都挣扎于成本消耗与实现任务目标的矛盾之中。多数过程都以文档为中心。在这种情况下，他们需要额外

付出超出维护日常活动的正常流之外的努力。无论团队使用特定的、灵活的或者常规的过程，每一支团队

都可以受益于自动且集成的软件开发过程。
 
• 另人失望的投资回报 (ROI)：站在 CIO 的角度看，痛苦的抉择在于，在开发活动和工具方面不断投入

的、天文数字的 IT 预算换来的却是另人失望的投资回报。大多数采纳过程和 SDLC 工具的尝试之所以困

难重重，原因在于其陡峭的学习曲线、缺乏工具集成、高额的前期投入费用、持续的维护、特殊技能需求

以及对专门的管理员的需求。结果，包含 SDLC 工具的总拥有成本是难以负担的。因此，CIO 面临一个难

题 — 证明既然费用支出不会再涉及任意可估计到的因素，那么他们的费用支出就是合理的。
 

改进软件开发生命周期
当 Microsoft 首先发布 Visual Basic 之时，就通过降低其复杂度从而使 Windows 软件开发得以广泛应

用。利用 Visual Basic 6.0，Microsoft 让数以百万计的开发人员能够快速开发客户端/服务器应用程序

。最近，利用 Visual Studio .NET，Microsoft 又为开发人员提供了轻松开发分布式应用程序的工具与

技术。通过 Visual Studio 2005 Team System，Microsoft 正在解决日益增加的应用程序复杂性及其设

计、开发和部署所必需的生命周期问题。这一点是通过提供必需的工具和指导从而能够预见、重复结果（

无需付出生产效率和创新的代价）实现的。

• 信息交流：通过降低报告的运转开销和寻觅团队成员间新的交流渠道，Visual Studio Team System 着

重于能够更好地进行交流。例如：

• 通过自动从团队成员使用的工具那里收集信息，可以简化报告过程。从 Visual Studio Team System

采集到的数据保存在数据仓库中，这使项目状态报告和可见性能够面向软件开发团队的所有成员，甚至是

项目组之外的干系人。
 
• 项目经理能够将客户需求转化为开发团队中的工作项，然后跟踪工作项的状态以实现项目状态的监控。
 
• 分布式系统设计器 (Distributed System Designer) 将应用程序开发和部署需求转化为能够让开发人

员和操作进行交流的公共语言 (SDM)。
 
 
• 集成的工具：Visual Studio 的成功已被证实，即开发人员偏爱一个具备对他们需要的工具提供接口的

集成开发环境。通过将开发人员在开发环境中需要的测试和性能工具（例如，单元测试、代码分析和性能

分析）合并在一起，Visual Studio Team System 也期待着这种成功。这使开发人员能够在生命周期的较

早阶段就改善其代码的质量，而无需中断他们的工作。通过尽早地为开发人员提供他们需要用于识别和解

决质量问题的工具，更多的产品缺陷就能够在它们还未构成危害之前即被发现并解决。
 
• 简化的、集成的工作流和过程：有了 Visual Studio Team System，那么过程就不仅仅是文档了。它还

能将自己体现为实际的工具行为更改。当您在项目初期选择过程时，还需要选择工作流和工作产品，它们

会驱动系统的行为方式。对 SDLC 过程的支持是内置的，这使得对工作流的支持是无缝的。通过将过程集

成到团队成员日常使用的基本工具中，Visual Studio Team System 大大消除了过程采纳的障碍，并使自

动收集跨职能的项目标准成为可能，而无需实施人工报告的相关开销。
 
• 增加的投资回报：利用信息交流和生产效率的改进，企业将明显地看到针对其在 SDLC 工具和过程方面

的投资而增加的 ROI。Visual Studio Team System 提供一个具有成本效益的解决方案，从而通过使用跨

所有 SDLC 工具的广泛集成，实现对软件开发生命周期的管理。通过提供集成的工具集并基于现有知识进

行构建，Visual Studio Team System 提供一个友好的环境来帮助开发团队提高效率，而无需掌握不必要

的、复杂的概念和僵化的工具。
 

集成
通过将 SDLC 工具集成到 UI 级别的表面，Visual Studio Team System 提高了团队工作效率并增强了项

目的可预见性，下面说明数据级别表面以及过程级别的项目上下文。

• 用户界面集成：工具间的无缝集成是增强生产效率的关键。Visual Studio Team System 提供跨整个

SDLC 工具套件的、一致的用户体验。对于开发人员而言，可以在他们当前的开发环境中使用某些活动（

例如，单元测试、工作项跟踪、代码剖析以及代码分析）。
 
• 数据集成：通过使用一个公共的跨工具集的数据仓库，Visual Studio Team System 解决了在大多数

SDLC 工具中建立数据仓库这一问题，并启动了一个聚合的项目状态视图。团队根据能够收集到的规则来

管理项目。今天，数据主要限于缺陷跟踪。Visual Studio Team System 中集成的数据将开创一条新路

— 通过平衡利用贯穿于 SDLC 的大量、多样的数据来管理项目规则。Visual Studio Team System 会收

集精确的数据 — 不仅限于缺陷跟踪，而是包括测试结果、代码涵盖、代码生成、任务进度等这些贯穿于

团队常规工作流程的数据。该数据以某些标准的报告方式呈现，客户和 Microsoft 内部团队已在报告中

建立了成功项目管理的关键规则。此外，团队还能够创建自定义报告。仅当以项目的大范围上下文查看数

据时，团队才能够精确地报告项目状态。
 
• 过程集成：在 Visual Studio Team System 中，工具行为由项目开始时选择的过程决定。通过将过程

与工具相集成，Visual Studio Team System 帮助确保在项目各阶段之间或各种项目角色之间避免丢失任

何内容。通过自动处理团队成员之间的工作调整，可以提高团队效率。公司通过使过程标准化，能够纠正

贯穿于过程改进中的系统问题，而无需增加团队的工作量。此外，过程集成并不增加工作量，而通常能够

降低与 SDLC 中所采纳过程相关的开销。
 

扩展性
尽管存在一些基本的工具可组成 SDLC 工具（例如，架构师工具、测试工具等），但是 SDLC 并未限制住

工具的数量。当集成支持 SDLC 的工具时，团队会发现在提高团队效率，同时降低复杂性这些方面的好处

。Visual Studio Team System 将提供基本的平台，让所有提供商能够以一种普通的、公众可理解的形式

交换信息。这理所当然地铸造了一个充满活力的合作伙伴体系，合作伙伴能够构建完全集成的工具，简化

构建 IT 解决方案的复杂性，以及推动信息交流和鼓励团队协作。要获得跨 UI、数据和过程集成的最大

价值，就需要扩展性。扩展性促成交互性。

Visual Studio Team System 设计基础是扩展性模型。Microsoft 提供的 SDLC 工具利用与第三方可用的

扩展性功能相同的扩展性功能。扩展性体现在集成的三个层次：UI、数据和过程。

• 用户界面扩展性：Visual Studio Team System 利用现有的 Visual Studio Industry Partner (VSIP)

计划，将补充的产品和服务插入到 Visual Studio 集成开发环境 (IDE) 之中。
 
• 数据扩展性：Visual Studio Team System 利用 Visual Studio Team Foundation Core Services

(TFCS) 将这些工具集成在一起。TFCS 提供一组能够将工具集成在一起的工具，无需工具间的紧密耦合。

对于数据收集，TFCS 还能够将第三方工具用于由 Visual Studio Team System 使用的数据仓库。
 
• 过程扩展性：Visual Studio Team System 使用方法论模板来定义每个项目将遵循的过程。不存在适用

于所有组织、以至一个组织内的所有项目的通用过程。不要为此担心，Visual Studio Team System 是一

个灵活的工具集，它采用即灵活又正规的过程。Microsoft 的 Global Solution Integrator 合作伙伴将

提供他们自己的方法论模板产品；或者，您可以自己创建模板。过程扩展性允许自定义工作项类型、签入

策略、自定义报告以及项目管理模板。
 

有关详细信息，请参阅 Visual Studio 2005 Team System：Microsoft Solutions Framework 和 Visual

Studio 2005 Team System:扩展套件。

Microsoft Visual Studio 2005 Team System
Microsoft Visual Studio 2005 Team System 提供支持整个软件开发团队的工具：

• 架构师：Visual Studio 2005 Team Architect Edition 包括集成、高效的工具，用于直观地构建面向

服务的解决方案，这些解决方案从部署环境的初始状态开始设计。有关详细信息，请参阅 Visual Studio

2005 Team System：设计分布式系统以进行部署。
 
• 开发人员：Visual Studio 2005 Team Developer Edition 为开发人员提供高级的静态分析、代码剖析

、代码涵盖以及单元测试工具，使团队能够在整个生命周期中尽早、频繁地规划质量。有关详细信息，请

参阅 Visual Studio 2005 Team System：构建健壮而可靠的软件。
 
• 测试人员：Visual Studio 2005 Team Test Edition 构建于开发人员版本之上，更好地为测试人员提

供了用于管理和运行各种测试（包括单元测试、手工测试和 Web 测试）的工具，以及使团队能够在应用

程序部署之前检验其性能的高级负载测试工具。有关详细信息，请参阅 Visual Studio 2005 Team

System：通过更完善的测试实现更好的软件。
 
• 项目管理人员：Visual Studio 2005 Team Foundation 提供一套基于软件项目管理人员已知内容的项

目管理工具：Microsoft Excel、Microsoft Project 和 Windows SharePoint Services。与 Microsoft

Office 集成，项目管理人员不再需要手工将数据从这些应用程序映射到供工程团队使用的数据。项目站

点提供仪表盘式的项目状态视图，以及向下追溯风险承担者的功能。丰富的报告提供了从整个常规的团队

工作流中收集的规则。自定义项目过程基于业界公认的实践来驱动生命周期。有关详细信息，请参阅

Visual Studio 2005 Team System：软件项目管理。
 
• 团队开发：Visual Studio 2005 Team Foundation 还提供团队协作工具，使组织能够不费吹灰之力即

可管理并跟踪过程和软件项目的运行状况。Portfolio Explorer 将可从项目站点获得的这些相同的项目

工作产品集成到 Visual Studio IDE，从而让团队能够进行有效的访问。Visual Studio 2005 Team

Foundation 还提供一个可扩展的工作项跟踪系统和企业级别的源代码管理。有关详细信息，请参阅

Visual Studio 2005 Team System：企业级源代码管理和工作项跟踪。
 

图 1. Visual Studio Team System

小结
复杂性是现代化业务的牵绊。它不仅扼住项目的下限，牺牲项目上限，并对之间的任何事务产生强大压力

。由于应用程序在复杂性的阴影下推进，因此软件团队要对应用程序进行缩放，就十分需要相同的简单性

和灵活性的 RAD 原则。缩减复杂性意味着能够更高效、节约成本和将项目下限降至更低，同时为扩大项

目上限而节约时间并提供更多的机会。

 

 

了解Team System

每个人都在谈论协作开发工具，主要的开发人员不可能连续10分钟都不会遇见报告新情况的提示。我们不能责怪微软，但是我们需要的不仅仅是一个协作环境。对于绝大部分IT团队来说，协作开发是未来的事，是目前还没有实现的目标。现在所需要的是这样的一个协作解决方案：

• 和已经在使用的工具紧密结合
  
• 高度直觉化，而且
  
• 提供了一种新的开发方法，而且并不意味着要放弃现有的一切。
  
  Visual Studio Team System是微软的回应。这个回应已经非常清楚，好的方面是它提供了所有团队需要的结构，管理工作所需要的跟踪工具，以及为了协作需要使用的所有工具。不好的方面是微软再一次在代替我们决定自己应该做什么方面，走得太远。它对于你的团队是否有用？因为目前正在使用的协作工具并不让人满意。
  
  结构化图表工具
  IT开发者们，在额头上都应该写着一个大大的单词：ARCHITECTURE（结构）。今天，IT开发中缺少的最大的遗患，除了平台，就是在应用开发中缺少恰当的结构化思维。这也就是为什么世界总是开玩笑说我们需要啄木鸟的原因。

  有很多、很多细节上的天才可以在T-SQL中重写达芬奇的密码，但是谁会认为两维的客户端—服务器结构对于互联网应用来说已经足够好了呢?今天，要开发出一个好的应用，尤其是一个好的互联网应用，你需要的不仅仅是一个好主意、好的工具、好的应用级设计；你还需要一个应用结构，一个高级架构，它应该能够帮助你的应用获得实现功能所需要的条件（包括硬件、网络、数据资源基础架构），不幸的是很多IT经理都不能真正理解这一点。很多IT团队都疲于奔命，成了全天候的消防队员，因为越来越多的用户通信堵塞了他们的数据库访问，因为他们的应用不能够在用户规定的时间内完成修改或加强。
  Team System在它的Team Edition for Software Architects版本中提供了一个名为Application Designer（应用设计器）的工具帮助解决这一问题。Application Designer是一个图形化的解决方案结构工具。它帮助用户创建应用系统解决方案的图表，这些应用系统解决方案包括了很多不同的类型组件（比如应用、网络服务、界面），并用你所选择的语言，生成骨干代码。Team Edition for Software Developers的版本中提供了图表功能。图表定义了图表组件之间的连接，让你能够按照自己的需要使用它们。
  这个创意满足了结构方面的不同开发需求，而不仅仅是满足了经理和开发者的需求。这里的设计者工具包与以往相比，功能更为强大，它内嵌了VS/TS的“分布式应用图表”概念。该工具会捕获所有的工作过程，而不仅仅是工作流和代码编写，还包含了针对系统图表、应用图表、配置图表和逻辑数据处理中心图表的结构化图表工具。
  
  

  利用微软Solutions Framework4.0
  MSF描述了一些方法，根据这些方法可以计划或进行应用开发。Version 4.0包含在Team System之中，为你提供了两个完备的系统开发生命周期模型，一个是针对灵活开发，另一个是针对流程改进。
  微软很热切地指出，这些方法是说明性的；也就是说，它们不仅仅是通用方法，只能给你一些通用指示。它们是针对具体情况的，能够根据你所执行的应用的特点，给与你的团队有针对性的行动指南。
  MSF4.0为细节开发和实施提供了一个meta-model机制，被一个支持者团队（team爱好者和对此感兴趣者组成）将其转化成了现实。这样一个雄心勃勃的飞跃不可能完美，我们也并没有期待它是完美的，但是它的方向是正确的，不过对于IDE软件解决方案供应商来说，这并不轻松。
  
  团队角色定义和约束
  MSF包含了一个Team Model（团队模型），在这个模型中为每一位项目参与者都分配了一个角色，或者多个角色。角色的分配是根据参与者的任务、权限、责任和义务来进行的。在Team System中，这些角色包括项目经理、Architect、开发者、测试人员和两个可选角色：版本经理和商业分析员。

  也许Team System中所定义的最重要的团队成员角色就是所使用的Team System版本本身，它定义团队成员在项目或者开发工作中能够或不能够做什么。其他重要的角色包括project permissions和advocacy assignment。
  
  Project/Excel集成
  Team Foundation Server直接同微软的Project和Excel进行通信。管理插件让你能够从Visual Studio 2005 Team Explorer打开Excel 或者Project，并在它们和Team Foundation Server之间传递工作项目列表。这些传递发生在一个开放项目之中，这非常方便，某位经理能够把工作项目列表从project导出，并离线进行处理。
  
  Application designer
  在BizTalk Server 2004和它的程序设计器上花费了很多时间，相信很多人都花费了很多时间在Visio上，设计图形并把它们连接在一起，就好象在会议室的白板上所做的那样。Team System的Application Designer大大改善了这一情况，它把Windows窗体应用、网络服务、BizTalk设计、数据库、ASP.NET Web服务和应用、外部网络服务结合在一起，生成代码来执行这种集成。因此可以节省设计工作，并实现资源控制。
  逻辑资料处理中心和数据资源管理
  我们在网络应用设计过程中，遇到过的最糟糕的灾难有两种，一种是用户界面设计把获取数据资源当做理所当然，第二种则相反。开发者通常在逻辑方面禀赋超常，但是在数据接入后勤方面能力不足。如果我们希望有一个干净而高效的应用，我们就需要在网络里挖掘数据。
  Team System对这个问题的解决方法是提供了一个逻辑资料处理中心设计器，它整合了客户端、Web服务器、SQL Servers和其他服务器，形成一个强制的、以计划为导向的模式，这让解决方案设计师们能够真正地注意到大局，并对网络以及对于数据来源之间界面的影响保持适当的注意力。由于网络服务在综合应用系统之中越来越多地成为中心，这种做法受到了广泛的欢迎。
  
  软件配置管理
  随着项目复杂程度的提高，如果代码管理不善的话，麻烦也会接踵而至。糟糕的团队沟通会雪上加霜，缺少结构化、高水平的集成计划，如果不会让项目彻底失败的话，也会导致不能很好满足用户需求和期望的尴尬场面。今天，对于保障项目成功来说，软件配置管理是非常重要的，谢天谢地，Team System中包含了这样的功能。
  来源控制在今天已经是一种被广泛接受的假定前提，但是这里的例外是跟踪工作项目以及更早地建立管理。工作项目包括人物、bugs、需求、风险、和高级情况。这些工作项目可以在你的方法中进行定义，你还拥有丰富的道具，方便你的开发周期中进行详细的项目定义。你对这些项目的跟踪可以是完全个性化的。建设管理——名为Team Build，是基于MSBuild——为你提供了一个建设个性化的工具，它包含了编译、来源控制、单元测试、静态分析、binary routing、建设报告和测试结果报告。
  用SharePoint Services创建团队portal
  很多IT团队都使用SharePoint Services进行团队协作、项目跟踪、文件共享，甚至是资源控制。Team System非常适合SharePoint。编译、登录/登出和安全都是内嵌的，SharePoint对于上述提到的MS客户端都非常友好。
  集成化测试
  如果你想从结构化方面涉及并进行实施，你需要从头到脚的完整测试。我们在前面已经提到过单元测试，但是整体测试或者系统级测试通常需要手工完成。Team System允许你从Word模板中创建并进行高级测试和bug跟踪，Word模板可以从Visual Studio 2005中打开；在这个过程中，仍然需要人的干预，但是你现在可以获得和单元测试一样的连贯性和深度。你还可以使用Generic Test Designer创建使用到其他测试工具的测试，并记录结果。你还可以使用Web Test Recorder，在测试网站过程中，捕获测试者的浏览情况。Web Test Recorder可以从Visual Studio中打开，运行在Internet Explorer之上。
  系统设计器
  尽管整个VS/TS会在大的方面让你沉浸不已，你还是会喜欢System Designer，这个工具可以把一个综合应用打散成最小的开发单元，无论这个单元在你的具体项目中指的是什么。这样做的思路是在大型应用中，在保持组件好管理特性的同时——在多层的系统中，非常难以实现——在开发过程中保持项目的连续性。
  System Designer层粒度的扩大让你可以对组件进行测试和开发，并将它们组合成子系统，在这个过程中，最高配置和定义如果必要的话，可以属于更高的项目层级，然后将这些变化散播到应用层。而且如果需要的话，你可以为以后的对比和检查保存这些修改，直到子系统毫无瑕疵为止。