(七)从一个工程计划中删除工作项
一旦创建一个工作项，你就不能从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中的 “Assigned To”域展示了一个这样的示例）。点击“Close”按钮可以关闭这个对话框并再次显示图8中的“Publishing Errors”对话框。这一次由于已经改正了错误的工作项，所以你可以使用“Publish”按钮了。点击这个按钮将会把该工作项出版到TFS中。
(九)出版时的数据冲突问题
有时，被出版的工作项中的数据可以与TFS中对应那些工作项的相关数据不匹配。这种情况在多个人从不同的客户端更新工作项时经常发生。当发生这样的冲突时，MS PROJECT将显示一个如图10所示的对话框，该对话框中显示出本地的以及服务器版本的数据。

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

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

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

七、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与其它产品的协同开发是一个极为复杂的话题-我们只是刚刚开了个头而已。