一、简介 Visual Studio 2005 Team System（VSTS）能够为一个典型的软件开发团队中的每一种角色（架构师，工程经理，开发者和测试者）提供相应的工具。例如，它支持工程经理使用他们所熟知的工具（MS PROJECT和Microsoft Excel）把工程管理数据存储于Team Foundation Server（以下简称“TFS”，是Visual Studio 2005 Team System的基本组成部件，提供协作服务器特征）内。 本文中，我们将共同探讨如何联合使用MS PROJECT与VSTS数据，并分析这样做存在的优势。 在软件开发工程中，工程经理及工程领导人通常都面临下列问题： ◆他们要花费大量的时间来跟踪例如工程计划，任务，问题，风险等工程管理数据。为此，他们需要与其他团队成员举行频繁的状态会晤以得到最新的数据。显然，在这些会晤上花费的时间将极大地影响团队的整体生产效率。 ◆这些数据通常都是以MS PROJECT或Microsoft Excel形式存储的，并且需要与其它团队成员共享。这样以来，需要创建该数据的多个备份，从而导致很难得到工程状态的一个一致和同步的视图。 ◆因为工程数据存在于多个文件中，因而创建工程报告几乎变成了一个以手工为主的而且是极耗费时间的过程。 如今，VSTS中的工程管理工具有助于帮助解决上面的问题。例如，工程经理可以使用MS PROJECT创建任务和其它工程管理项-例如问题和风险，并把它们保存于Team Foundation Server（TFS）中，而其他团队成员就可以在他们自己的开发环境本身（即Visual Studio）内观察和更新这些数据项了。 因为所有的这些工具都依赖于一个中央服务器上的数据，所以，通过一种工具所作的修改势必影响到其它工具。集中式的工程数据使得捕获、共享和报告更为容易，而且耗费时间相对减少。此外，MS PROJECT与VSTS的紧密集成允许两者之间进行无缝的数据传递和同步；但是，在VSTS的当前版本下，这种内置的集成仅可用于MS PROJECT客户端。如果你要求与MS PROJECT的服务器端（MS PROJECT SERVER）实现这样的集成，那么你必须手工地通过PROJECT SERVER和VSTS提供的API来实现这一目的。不过，微软计划在一个未来发行版本中提供对VSTS和PROJECT SERVER的更好的集成。 在VSTS中创建一个工程计划并与一个团队共享它的过程不同于我们更为熟悉的操作一个独立的MS PROJECT实例的过程。本文后面，我们将详细描述实现这一过程所需要的步骤，例如创建一个计划，更新和共享该计划，以及修订数据冲突等。此外，我们还将讨论平时操作MS PROJECT和VSTS时并不经常遇到的一些内容和特征。而且，我们还将对VSTS和MS PROJECT SERVER加以比较，因为这两者都允许MS PROJECT客户端操作它们的数据。 缺省情况下，VSTS和MS PROJECT的集成会限制工程经理如他们平常那样使用MS PROJECT的方式。但是，因为VSTS和MS PROJECT都提供了可扩展性特征，所以，你可以对它们进行扩展和定制以提供这些工程经理们以前比较习惯的行为。然而，这样的定制内容已经超出本文的讨论范围。 【作者注】VSTS仅能与MS PROJECT 2003协同工作，而无法与更早一些的版本协同工作。因此，为了简化起见，本文中我仅使用“MS PROJECT”来指代“MS PROJECT 2003”。 二、VSTS基本概念 为了充分地理解MS PROJECT与VSTS的集成，首先我们有必要熟悉一下VSTS的一些核心概念。 ◆ Team Foundation Server（TFS）。为了支持在一个组织内部进行协作性开发，VSTS中提供了一个称为“Team Foundation Server”的服务器端组件。 ◆工作项（Work Item）。VSTS把任务，问题，风险等数据都作为工作项存储于TFS中。其实，工作项就是一些工作单元，可以被分配给团队成员并存储有关该工作单元的完整信息。VSTS提供了一些预定义的工作项类型，例如任务，错误和场所。每一种工作项类型（Work Item Type，以下简称为“WIT”）都有一组特定的域和有效的状态转换。用户可以定制这些WIT，也可以定义新的WIT。MS PROJECT可以操作任何类型的工作项，并且不仅仅限于任务。 ◆团队工程（Team Project）。因为一个软件开发过程中的大多数活动都是在一个工程的上下文中进行的，所以，VSTS还把所有的数据（例如角色，成员，工作项和文件）存储在工程上下文（称为“Team Project”）中。一个团队工程要求必须在VSTS内创建，用于存储关于任何软件开发工程的信息。 ◆过程模板（Process Template）。团队工程是基于过程模板创建的。一个过程模板是一组xml文件，用于指定WIT定义，工程角色，工程生命周期结构，工程门户结构，源控件结构以及预定义的报告，等等。VSTS发行中提供了这样两个模板：①“MSF for Agile Software Development”；②“MSF for CMMI Process Improvement”。其中，Process模板也称为Methodology模板。 【作者注】所有在本文中描述的WIT都是符合“MSF for Agile Software Development”过程模板的。 三、联合VSTS以及单独使用MS PROJECT

(一) 单独使用MS PROJECT

当单独使用MS PROJECT时，工程经理通常遵循下面的步骤： 1. 创建一个新的工程计划并且使用进一步细化的结构填充它； 2. 通过电子邮件或其它方式与团队成员共享该工程计划； 3. 保存该工程计划。 然而，借助于VSTS，还存在另外的方法来使用工程管理数据。下面，我们按时上面的步骤来解释MS PROJECT和VSTS的集成特征。尽管这些步骤实质上都是相同的，但是，它们在执行上还是略微有些差别。 1. 工程经理通过MS PROJECT创建一个新的工程计划； 2. 在填写该工程计划前，他们连接到VSTS中的一个团队工程并且把团队工程中现有的工作项导入到工程计划中。然后，他们添加新的工作项或修改导入的工作项。 3. 最后，他们把所有的工作项出版到TFS中，以便团队成员可以在Visual Studio内各自的工作项列表中观察它们。 (二) 通过MS PROJECT插件支持VSTS集成 为了支持MS PROJECT与VSTS的集成，你需要安装一个VSTS插件。当在一台安装有MS PROJECT的机器安装任何一种VSTS团队客户端（Team Architect，Team Developer，Team Test或者Team Foundation Client）软件时，这个插件都会自动地安装。该插件将把一个新的菜单组-“Team”连同一个工具栏添加到MS PROJECT中，如图1所示。

图1：把VSTS插件安装到MS PROJECT后出现的新的Team菜单组和工具栏

另外，该插件还添加了许多简化操作VSTS数据的对话框。 【作者注】因为在“Team”菜单组下的工具栏按钮和菜单项执行的是相同的动作，所以，我在后面干脆使用术语“按钮”来代指工具栏按钮和菜单项。不过，的确存在两个菜单项没有相应的按钮，我会单独描述它们。 四、创建一个工程计划

有了VSTS，你就可以使用工作项（work item）来创建一个工程计划。这种方式提供了下列优点： ◆工作项存储于TFS中，这将有效地避免多个工程计划副本所导致的不一致性。 ◆团队成员可以直接在Visual Studio中更新他们的工作项。这样的改变也将自动地反映到工程计划中，从而有助于减少状态会晤的次数。 ◆你可以为工作项域中允许的值指定复杂的规则。这些规则并非仅仅是静态的约束；它们可以在任何时候根据一个工作项的状态进行改变，从而使工程计划的创建和维护更为一致和减少错误。 ◆工作项支持复杂的查询。工程经理可以使用这些查询和MS PROJECT视图来得到高度定制的工程计划视图。 注意，仅当使用基于工作项的工程计划时才会有上面所描述的优点。当这些优点与VSTS的其它特征结合到一起时，工程管理过程将变得更为有效和简单。有关VSTS的其它工程管理特征的详细描述，请读者参考MSDN文章“Visual Studio 2005 Team System:Software Project Management”。

五、连接到VSTS 为了在MS PROJECT中创建和更新工作项，你首先需要连接到一个团队工程。为此，在MS PROJECT中打开一个新的工程计划，这将激活插件工具栏中的"Choose Team Project"按钮（图1）。当你点击此按钮时，你将看到如图2所示的对话框。

图2：连接到一个Team Foundation Server-这个对话框 让你选择一个团队工程和一个Team Foundation Server

在此对话框顶端的下拉列表框列出当前可用的Team Foundation Server。如果一个也没有列出，那么，你可以通过点击“Servers…”按钮显示一个对话框列出所有可用的服务器来添加新的服务器。该对话框中含有“Add”和“Remove”按钮；点击“Add”按钮将显示一个如图3所示的对话框。

图3：添加Team Foundation Server-此对话框 让你把一个新的TFS添加到服务器列表

以这种方式添加的服务器以顺序方式显示于图2所示的下拉列表框。当你选择一个TFS时，在“Team Projects”文本框中将显示在相应的服务器下可用的团队工程。注意，每次仅可以选择一个团队工程。当你选择一个工程并点击OK后，你将看到一个正常的MS PROJECT接口，但是它将显示了一组不同的数据栏，如图4所示。

图4.连接到一个团队工程的空白工程计划-此图展示了一个新的MS PROJECT计划， 其中显示了适合于一个团队工程的一组栏目

通过点击“Get Work Items”按钮，你可以从连接的团队工程中导入工作项，图5显示了相应的对话框。

图5：使用这个对话框，你可以从一个选择的团队工程中观察、选择和导入工作项

“Get Work Items”对话框允许用户观察选择的团队工程中可用的工作项和选择工作项以导入到新的工程计划中。通过在团队工程中运行一个基于WIT的查询或存储查询，该插件能够完成这一任务。该对话框将以数据格子的形式展示查询结果。用户可以选择那些他们想导入的工作项-通过选择相应的复选框来实现。 在你选择一些工作项后，点击OK返回到以你选择的工作项填充的工程计划下，如图6所示。

图6：填充工程计划-以选择的工作项填充的MS PROJECT计划

六、使用工程

当你把一个打开的工程计划连接到选定的团队工程时，两处接口将会改变：①“Choose Team Project”按钮被禁用，其它按钮都可以使用；②工程计划中的数据栏改变成显示相应的工作项域。在本文后面，我将描述这些栏以及它们到MS PROJECT栏的映射。 注意，你并不限于仅使用那些自动显示的栏。借助于MS PROJECT的“Insert Column”选项，你还可以在工程计划中显示其它的MS PROJECT栏。 值得注意的是，你还可以从Visual Studio内部打开MS PROJECT；当你以这种方式打开它时，你不必手工地把工程计划连接到一个团队工程和导入工作项。下面展示了这一过程。Visual Studio提供一个类似于格子的接口来展示一个工作项查询的结果，如图7所示。

图7：查询结果以一个类似于格子的形式显示于Visual Studio内

在图7中，你可以看到在查询结果页面的按钮工具栏中出现一个显示有MS PROJECT图标的按钮。点击这个按钮将自动地连接到包含那些工作项的团队工程，并且使用一个包含在此查询结果页面中选择的工作项的工程计划打开MS PROJECT。Visual Studio还允许你从Team Explorer中打开一个连接的工程计划。为此，Team Explorer提供一个树状结构来存取不同的团队工程组件-例如工作项，文件，等。其中有一个“Work Items”结点，其上下文菜单中提供了选项“Add Work Items with Microsoft Project”；点击该选项将打开一个连接到团队工程的空白工程计划。 在创建工程计划并把它连接到一个团队工程后，你可以使用该计划来编辑现有工作项或创建新的工作项。 【作者注】从此往后，我将使用术语“连接的工程计划”来指代一个通过连接到一个团队工程创建的工程计划。这里的“连接的”并不是指在MS PROJECT和TFS之间创建网络连接，而只是意味着该计划关联到一个团队工程中。就网络连接来说，MS PROJECT通常是在一种中断连接的方式下工作的，仅在必要时，例如当时出版或刷新时，它才连接到TFS。 (三) 添加与编辑工作项 你可以使用与在一个中断连接的工程计划中添加或编辑任务一样的方式在一个连接的计划中添加和编辑工作项。你可以通过在工程计划的一个空白行的适当的栏中输入工作项域的值来添加新的工作项。你可以通过某工作项的一个或多个栏中的值来编辑现有工作项。你可以编辑除了“Work Item ID”栏（工程计划中的第一栏）以外的栏的值。工作项ID是一个数字，它唯一地标识一个TFS中的所有工程的工作项。 许多栏都提供了相应的下拉列表框以显示一组预先定义的值-这些值可以直接从该栏中输入。例如，“Work Item Type”栏就展示所有的WIT-任务，错误，等等。 (四) 共享工程计划

借助于VSTS，你可以与其它团队成员共享工程计划，并且仅通过一个简单的按钮点击把它更新到当前状态。但是这种简化并没有减少工程管理器对于共享过程的控制权，也没有导致数据一致性方面的妥协。工程经理可以专门选择他们想共享的工作项。它们还可以选择单向或双向方式来实现工作项同步。如果工程计划（本地的）中的数据与TFS中央位置的数据发生冲突，那么，该工程可以把本地的和服务器版本的数据共同呈现给用户，然后，由用户选择他们想保留的版本。 (五) 出版与刷新的问题 MS PROJECT以中断连接的方式使用工作项的一个本地的副本工作；因此，为了实现与TFS中所作更改的同步，你必须通过点击“Publish”按钮来出版该计划。 当你出版一个包含新输入行的工程计划时，TFS会为相应的团队工程针对每一个新行创建一个新的工作项。每一个新的工作项都有一个对应的工作项ID。MS PROJECT插件正是使用对应栏中的这个值来标识TFS中每一行相应的工作项。通过这种方法，可以确定你是否已经出版了某些项-如果一些行中的ID栏为空，那么这意味着那些行还没有出版并且在TFS中也没有任何相应的工作项。同样，当改变和出版一个工程计划中的现有工作项时，这样的改变将影响到TFS中的这些工作项。 就象你出版一个工程计划中的改变一样，你可以通过刷新当前视图实现TFS中所作的改变与工程计划的往回同步-这是通过点击连接的工程计划中的“Refresh”按钮实现的。存在多个情况可以从本地的MS PROJECT副本外部来改变工作项。例如，当出版工作项时，团队成员将在他们的工作项列表中得到分配给他们的工作项。当他们完成一些工作时，他们可以通过Visual Studio更新相应的工作项。团队领导人还可以从MS Excel或一些其它MS PROJECT实例中更新一些工作项。所有这些都是与共享单个数据副本的多个团队成员观察到的内容保持同步的。 (六) 同步选项 通过设置“Publish and Refresh”栏中适当的值，工程经理可以控制一个工程计划和TFS之间的同步级别。“Publish and Refresh”是一个特别的栏，因为它在任何工作项中都没有一个相应的域，这个栏仅用于设置同步级别-这可以是下列三个值之一： 1. Yes-在工程计划所作的改变将被出版到TFS，而且在TFS中所作的改变还要往回同步工程计划。这是一个工程计划中针对所有工作项的双向同步设置（也是缺省的设置）。 2. Refresh Only-在工程计划中所作的改变不被出版到TFS，但是，在TFS中所作的改变还要往回同步工程计划。当工程计划需要使用工作项的一个只读副本时，使用这个选项。这是一种单向式（TFS→本地）选项。 3. No-在工程计划所作的改变不被出版到TFS，而且，在TFS中所作的改变也不往回同步工程计划。对于仅应该存在于工程计划中的任务，你可以使用这个选项。 【作者注】上面我一直使用的术语"任务"是指工程计划中的行，因为该行根本不会被出版，所以也就不存在任何相应的工作项。 通常，工程经理使用“Summary”任务来把一个工程计划中的庞大的任务列表组织成一些较小的组。但是“Summary”任务并不被独立地追踪，因为它们仅显示其包含的任务的计算值，并且没有任何与之关联的工作。注意，你可以给这些"Summary"任务一个“No”值以确保在出版工程计划时TFS不会为这些创建相应的工作项。

图8：这个对话框显示所有由于错误而没有出版的工作项

请记住：因为工程计划往往工作于非连接方式下，所以，仅当出版或刷新时才使用“Publish and Refresh”栏中的值。

(七) 从一个工程计划中删除工作项 一旦创建一个工作项，你就不能从TFS中删除它。因此，当一个用户从一个工程计划中删除一个工作项记录时，该工作项仅能从该工程计划的副本中被删除，但这个工作项仍存在于TFS中，并且可以通过点击"Get Work Items"按钮再把它导回到工程计划中。 (八) 出版错误问题 工作项中一切定义在WIT中的域都有自己的数据类型和规则，例如，域“Rank”是integer类型的，因此仅可以有数字型值，而域“Assigned To”仅能以有效的工程成员之一作为命名。MS PROJECT插件通过提供一个仅包含有效值的下拉列表框来强制实施这其中的大部分规则。例如，“Assigned To”栏相应的下拉列表框将仅显示有效的用户，而相应于“Discipline”栏的下拉列表框则仅显示相应于该域的在WIT定义中定义的值。 但是也存在一些MS PROJECT插件无法强制实施的规则。例如，一个用户可以在“Rank”栏中输入一个字符串值，尽管它在WIT中被定义为一个integer类型。当一个用户要出版的一个工程计划中存在一些栏包含无效的工作项值时，具有无效值的工作项不会被出版；代之的是，该插件将在“Work Item Publishing Errors”对话框中报告它们，如图8所示。 从图8中的对话框中可以看出，用户可以选择一个工作项并点击“Edit Work Item”按钮来观察和修改错误。点击该按钮后将显示一个如图9所示的对话框。

图9：工作项编辑器-这个对话框让你编辑并修改由于错误而未被出版的工作项

这个对话框显示所有关于工作项的信息，它甚至还展示那些并不是工程计划的一部分的域。引起出版错误的域从外观上看起来具有一个黄色的背景（图9中的“Assigned To”域展示了一个这样的示例）。点击“Close”按钮可以关闭这个对话框并再次显示图8中的“Publishing Errors”对话框。这一次由于已经改正了错误的工作项，所以你可以使用“Publish”按钮了。点击这个按钮将会把该工作项出版到TFS中。 (九) 出版时的数据冲突问题

有时，被出版的工作项中的数据可以与TFS中对应那些工作项的相关数据不匹配。这种情况在多个人从不同的客户端更新工作项时经常发生。当发生这样的冲突时，MS PROJECT将显示一个如图10所示的对话框，该对话框中显示出本地的以及服务器版本的数据。

图10：Conflict Resolution-当从一个本地的副本出版数据时将会引发一个与TFS中数据的冲突， 你可以使用这个对话框来决定保留哪一个版本

点击“View Database Version…”按钮将会以只读方式在一个类似于图9中所示的对话框中显示服务器端工作项。你可以选择针对每种冲突想保留的版本并出版这些工作项。 (十) 保存工程计划

因为一个连接的工程计划中的大多数数据是存储于TFS中的，所以，你不必再保存一个本地副本。但是也存在一些情况，此时连接的工程计划可能包含仅存在于本地的数据，并且不被出版到TFS中，例如： ◆Summary任务或那些“Publish and Refresh”栏被标记为“No”的任务（如前面所述）； ◆其它的MS PROJECT栏。 在这种情况下，你应该保存工程计划的一个本地的副本。当你打开一个本地保存的工程时，该计划自动地连接到相关联的团队工程中并且实现自身与TFS的同步。 (十一) 工程计划栏的映射问题 前面图4中的工程计划中展示了一个工程计划（此时，它被连接到通过“MSF for Agile Software Development Process”模板创建的一个团队工程中）中缺省栏的集合。注意，在此并非所有显示出来的栏在任何工作项中都有相应的域。一些栏仅能作为MS PROJECT栏单独存在，而不被出版到TFS中，例如“Duration”和“Row No”栏。同样，在连接的工程计划中的一些栏并没有被显示于缺省的视图中，但是在工作项中的确存在相应的域。例如，域“Priority”和“Discipline”在缺省的视图中就没有显示，但是在出版或刷新时它们能够与工作项保持同步。表格1列出了所有的用于保持在MS PROJECT和工作项之间同步的栏。这些栏可以是下列三种类型任何一种： ◆适合于在“MSF Agile”过程模板中所有可用的WIT的栏。例如：Task，QoS，Risk，Scenario，Bug，Work Item ID，Area Path，等；这些栏的“Work Item Type”值在表格1中都为“All”。 ◆仅适合于特定工作项类型的栏。例如，“Completed Work”栏仅应用于“Task WIT”。这些栏在表格1中的工作项类型值对应于每一栏适用的工作项的名字。 ◆不适合于任何WIT的栏。这些栏存储了仅与MS PROJECT内部相关的信息，例如，“Publish”和“Refresh”，它们在表格1中对应的工作项类型值为“None”。 注意，还存在适合于多个WIT的栏，并且可以拥有在WIT定义中从一个预先定义的列表内指定的值。如果这些列表中具有与可用WIT定义不同的值，那么这些栏相应的下拉列表框将显示来自于所有的WIT中的组合值的列表。例如，针对一个任务WIT的“State”域可能是“Active”或“Closed”，但是对于其它三种WIT，则有可能是“Active”，“Closed”或“Resolved”。在工程计划中对应“State”栏的下拉列表框中将展示所有这三个值。

表格1-所有用于实现一个本地的MS PROJECT副本和存储于TFS中的工作项集之间同步的栏

MS PROJECT 栏	描述	工作项类型
Work Item ID	工作项对应的唯一ID。	All
Title	标题提供了对要完成的工作项的一个简明的概述。	All
Area Path	用于把工作项分组成一个适当的特征或团队区域。该区域必须是工程层次中的一个有效结点。	All
Iteration Path	工作项隶属的迭代。	All
Publish and Refresh	指定某个选项之一：Yes，No，Refresh Only。	None
Work Item Type	工作项的类型。	All
Discipline	显示该任务是一个开发任务，测试任务，或是一个普通任务。	Task
Assigned To	该工作项当前被分配到的人。	All
Completed Work	在当前任务上已经完成的工作量。	Task
Remaining Work	在当前任务上尚未完成的工作量。	Task
Baseline work	从最初的计划算起，已经工作的小时数。	Task
State	工作项的工作流状态。例如，相应于一个工作项应该是“Active”或“Closed”。	All
Reason	一个工作项处于当前状态的原因。例如，一项任务可以是“Closed”，因为它已经被完成，被推迟，被删除或过时。	All
Rank	这个等级域代表了一种主观上重要性评价。	QoS ，Scenario and Task
Issue	对应一个Yes或No值，指示是否该工作项被以某种方式阻止。如果这个域被设置为Yes，该工作项将出现在工程经理的问题报告中。	All
ExitCriteria	这个域指示当前工作项对于启动或完成一个迭代是否是关键性的。如果这个域被设置为“Yes”，那么，此工作项将出现在工程经理的工程清单中。	QoS ，Scenario and Task
QualityOfServiceType	服务质量的类型，它可以是：Performance， Security，Stress，Load，Platform或者Other。	QoS
Priority	业务优先权。	Bug
Rev	指示工作项的修订版本号。	All
Links and Attachments	指示是否工作项拥有任何链接或附件，其值为Yes或No。	None

表格1中的每一栏与其在VSTS中的等价的工作项域都是一一对应的。你可以通过点击“View Column Mappings”菜单项来观察这些映射，如图11中的对话框所示。

图11：栏映射

图11展示了缺省的栏映射，但是你可以通过定制过程模板来改变它们或添加新的映射。 (十二) 通过Areas和Iterations进行组织 通过把工作项按层次分类，你可以把它们组织成一个团队工程。VSTS支持两种层次： ◆Iterations-描述生命周期迭代。此时，一个工程将被划分为Planning，Envisioning，Development等组成部分。 ◆Areas-描述一个逻辑的工程划分（区域和组件）。例如，你可以把你的工程任务划分为每一种逻辑架构：用户接口层，业务层和数据存取层。 你可以分别通过“Iteration Path”和“Area Path”栏把工作项与这两个层次加以关联。这些栏都有一个下拉列表框，它们以一个树结构形式进行层次显示，如图12所示。

图12：该图展示了选择一个工作项的迭代路径的过程

你还可以使用这些层次来创建MS PROJECT视图-它们把工作项分组为各个层次。上面这两类层次结构都可以在MS PROJECT中通过“Areas and Iterations”对话框（通过点击“Edit Areas and Iterations”菜单项中显示，见图13）进行修改。

图13：此对话框展示了树结构形式的Area和Iteration层次， 你可以从中添加、删除、移动或改变结点缩进

七、MS PROJECT SERVER和VSTS比较

MS PROJECT SERVER 2003是一个企业工程管理产品，它实现了工程调度和管理，资源利用和项目清单，时间表等功能，而且还允许多个成员共享数据-提供一个基于Web的接口来观察和更新工程计划任务。 MS PROJECT SERVER能够与MS PROJECT（客户端）进行全面集成-你可以把任务从MS PROJECT出版到MS PROJECT SERVER中，然后在MS PROJECT中观察更新的任务。 由于VSTS在共享数据和MS PROJECT集成方面存在许多类似的特征，所以人们经常把它与MS PROJECT SERVER 2003进行比较。但是，这两个产品是针对不同领域的两个完全不同的产品。PROJECT SERVER主要针对企业工程管理领域，而VSTS则主要针对软件开发生命周期领域。VSTS并不仅提供了作业（或任务），而且还提供可扩展的工作项基础结构来创建每一项工程要求定制的工作项。而且，因为它与Visual Studio IDE紧密集成，所以，VSTS允许团队成员从IDE内部更新它们的任务及其它工作项。 总之，这两个产品各自提供互补的特征，而且也存在某些共同之处。正是我们所讨论的这些特点使得人们觉得很有必要把这两个产品集成到一起。尽管在VSTS 1.0版本中还不没有实现这两个产品之间的内置集成，但是微软已经计划在VSTS的2.0版本中提供这种紧密的集成。此外，已经出现一些社团组织，他们正在主动地开发PROJECT SERVER和VSTS之间的连接器。 八、小结 本文较全面地探讨了有关把Visual Studio 2005 Team System和MS PROJECT联合起来进行协同开发的实现过程及相关注意事项。其实，有关于Visual Studio 2005 Team System与其它产品的协同开发是一个极为复杂的话题-我们只是刚刚开了个头而已。