4

我们正在向 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 项目

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

2 回答 2

2

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

于 2011-04-29T02:17:27.933 回答
2

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

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

于 2011-04-30T03:09:41.623 回答