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