TFS 跨项目报告
我们正在向 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 项目
- 优点：维护当前以团队为中心的报告
- 优点：降低管理中断工作的风险团队项目中的项目。
- 缺点：所有团队都应该使用相同的流程模板（对我来说不是问题）。
We are migrating towards TFS and have decided based on online commentary to structure TFS as one Project per team, with each "real project" being an Area (and each release an Iteration).
This means our TFS structure is somewhat like:
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
However, from a management perspective it is tedious to review each team's reports individually.
I am wondering for those with experience using this structure, which of these options (or other option) have you successfully used?
1) Move all teams to the same Project
- Pro: No report changes
- Pro: Cross-team awareness
- Con: Clutter
- Con: Perhaps security
2) Change all reports to be cross-team
- Pro: Teams can still have own Projects
- Con: Have to change and synchronise all reports across all Projects
- Con: Reports become less useful to individual teams (can still customise copies)
- Con: Teams should share the same process template (a non-issue for me)
3) Setup a TFS Project just for Management containing cross-team reports
- Pro: Only have to change one TFS Project
- Pro: Maintain current team-focused reports
- Pro: Reduced risk of management breaking Work Items in team projects.
- Con: All teams should use the same process template (a non-issue for me).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我已经按照您上面定义的方式设置了项目。我已经为 #2 和 #3 配置了 TFS 报告。强迫团队重组以便完成报告的想法使得选项#1 对我来说过于严峻。 #3 很有吸引力，但与第 1 种类似，限制各个团队共享相同的工作项类型和流程模板。我总是处于第二种状态。特别是当团队独立发展他们的流程时。我已经能够通过投资定制报告来缓解“报告变得不太有用”的问题（我知道这很重要）。
I have set up projects as you've defined above. And I've configured TFS reporting for both #2 and #3. The thought of forcing teams to re-org so the reports work out makes option #1 too severe for me. #3 is appealing, but in a similar way to number 1, limits individual teams to sharing same work item types and process templates. Invariably I end up in the 2 state. Particularly if the teams evolve their processes independently. I've been able to mitigate the "reports become less useful" problem by investing in customizing reports (non-trivial I know).
这对于在 SharePoint Services 中使用 Excel Services 来说是一个很好的选择。您可以比自定义 SQL 报告更快地将它们组合在一起。您可以非常快速、轻松地访问仓库并创建跨团队报告。
那时，您应该可以随意组织您的团队项目并对其进行调整。事实上，您可能会发现您希望每个团队有一个 TPC，而不仅仅是一个 TPC。
This would be a good candidate for using the Excel Services in SharePoint Services. You can put them together much more quickly than custom SQL Reports. You can hit the warehouse and create cross team reports very quickly and easily.
At that point, you should feel free to organize your Team Projects and adjust them going forward. In fact, you might find that you want a TPC per Team rather than simply one TPC.