我们的团队刚刚迁移到 VS2012 和 TFS2012。我们正在采用“MSF for Agile”过程模板。但是，有一个障碍。我们是一个由多个 Web 应用程序组成的团队，我们被分配了一个 TFS 项目来容纳所有这些应用程序。这些项目都在各自独立的敏捷冲刺中运行。当我登录 TFS 项目的“MSF for Agile”模板网站时，我看不到任何分离。一切都出现在同一个产品 backlog 中。即所有应用程序开发都将在相同的冲刺中运行。生成的任何指标和报告都将毫无用处。
如何将应用程序分成不同的存储桶，同时仍将它们保留在同一个 TFS 项目下？
正如 MikeR 所提到的，一种方法是使用团队，因为每个团队都有自己的产品 backlog 视图。我还想指出，这种行为与模板无关；无论您使用哪种流程模板，Web Access 都将以这种方式运行。
然而，我会质疑这其中的价值。团队的积压工作通常应该代表团队正在做的所有工作，无论其起源如何。这将使您能够相对优先地为您的各种项目的工作进行比较。
您可以通过使用区域路径来指示工作项属于哪个应用程序来实现所需的报告功能。或者，您可以考虑向工作项添加一个字段，以通过应用程序指示工作项适用的应用程序。通过这种方式，您可以两全其美：真正的相对优先级和基于应用程序/产品的报告。
我也走上了这条路。似乎没有适用于这种情况的“最佳实践”。
我们所做的是将工作项的管理与源代码控制的任务分离。我们为这些项目维护一个中央存储库，以及 20 个用于源代码控制的不同项目/解决方案。这种松散耦合使事情变得非常简单，尽管它确实需要项目设置时间的前期投资。
在主项目中，我为 20 个项目中的每一个都建立了区域（TFS 术语）。这些区域与每个项目之间存在 1:1 的关系。然后，每个团队成员都可以清楚地了解项目所在的位置。
为了将所有内容联系在一起，要求代码签入以链接到工作项是至关重要的。这将一切都与主项目中的任务管理联系起来。没有这个，一切都会出错。有了它，我可以毫不费力地跟踪这些项目的变更集。
为了管理构建，我们有管理部署任务的构建定义。目前有 52 个构建定义来管理不同客户的部署。当然，这些与 20 个项目重叠。在应用程序中，所有配置都存储在源代码控制中，使用转换，以便将构建正确部署到具有正确配置的客户站点。将代码签入到不同的源代码控制区域这一事实是无关紧要的。
最后，为了管理构建的混乱，我编写了一个基于宏的构建控制器 GUI，使我能够简单地选择客户站点，并构建适当的配置。没有那一点胶水，这简直是一场噩梦。现在只需单击几下，所有构建都为我管理。
实施这种方法需要大量的试验和错误，从我们的失败中吸取教训，并且不再重复同样的错误。
希望这可以帮助。