TFS 跨项目报告

Question

我们正在向 TFS 迁移，并根据在线评论决定将 TFS 构建为每个团队一个项目，每个“实际项目”都是一个区域（每个发布一个迭代）。

这意味着我们的 TFS 结构有点像：

Apps Team
  - WinForms Project
  - WPF Project
  - Embedded Project
  - WPF Project 2

Web Team
  - Admin Site
  - Client Site
  - Client Site 2

DB Team
  - General Scripts
  - DB 1
  - DB 2

但是，从管理的角度来看，单独查看每个团队的报告是很乏味的。

我想知道那些有使用此结构经验的人，您成功使用了这些选项（或其他选项）中的哪些？

1) 将所有团队移动到同一个项目

• 专业版：没有报告更改
• 专业：跨团队意识
• 缺点：杂乱无章
• 骗局：也许是安全

2) 将所有报告更改为跨团队

• 专业人士：团队仍然可以拥有自己的项目
• 缺点：必须更改和同步所有项目中的所有报告
• 缺点：报告对单个团队的用处越来越小（仍然可以自定义副本）
• 缺点：团队应该共享相同的流程模板（对我来说不是问题）

3) 为包含跨团队报告的管理设置一个 TFS 项目

• 专业版：只需更改一个 TFS 项目
• 专业人士：维护当前以团队为中心的报告
• 优点：降低了管理人员破坏团队项目中工作项的风险。
• 缺点：所有团队都应该使用相同的流程模板（对我来说不是问题）。

Answer 1

我已经按照您在上面的定义设置了项目。我已经为#2 和#3 配置了 TFS 报告。强迫团队重新组织以使报告得以解决的想法使选项＃1对我来说太严重了。 #3 很吸引人，但与第 1 项类似，它限制了各个团队共享相同的工作项类型和流程模板。我总是处于 2 状态。特别是如果团队独立发展他们的流程。我已经能够通过投资自定义报告来缓解“报告变得不那么有用”的问题（我知道这很重要）。

Answer 2

这将是在 SharePoint Services 中使用 Excel Services 的理想选择。与自定义 SQL 报告相比，您可以更快地将它们组合在一起。您可以快速轻松地访问仓库并创建跨团队报告。

此时，您应该可以随意组织您的团队项目并继续调整它们。事实上，您可能会发现您希望每个团队都有一个 TPC，而不是简单的一个 TPC。