"MSF for Agile“过程模板中的子项目

Question

我们的团队刚刚迁移到VS2012和TFS2012。我们正在采用"MSF for Agile“过程模板。然而，有一个障碍。我们是一个由多个Web应用程序组成的团队，我们得到了一个TFS项目来容纳所有这些应用程序。这些项目都在各自独立的敏捷冲刺中运行。当我登录到"MSF“模板网站为我们的TFS项目，我没有看到分离。所有的东西都出现在同一个产品的待办事项中。也就是说，所有的应用程序开发都将在相同的sprint中运行。产生的任何指标和报告都是无用的。

如何将应用程序分离到不同的桶中，同时仍然将它们保存在同一个TFS项目下？

Answer 1

正如MikeR所提到的，这样做的一种方法是使用团队，因为每个团队都有自己的产品积压视图。我还想指出，这种行为与模板无关；无论您使用哪个过程模板，Web Access都将以这种方式工作。

不过，我会质疑这其中的价值。团队的待办事项通常应该代表团队正在做的所有工作，而不管它的起源如何。这将使您能够相对地优先处理您的各种项目的工作。

可以使用区域路径来指示工作项所属的应用程序，从而实现所需的报告功能。或者，您可以考虑在工作项中添加一个字段，以指示工作项应用到的应用程序。通过这种方式，您可以获得这两个世界的最佳结果:真正的相对优先级和基于应用程序/产品的报告。

Answer 2

我也沿着这条路走。在这种情况下，似乎没有“最佳实践”。

我们所做的是将工作项的管理与源代码管理任务分离开来。我们为这些项目维护一个中央存储库，并为源代码管理维护20个不同的项目/解决方案。这种松散的耦合使得事情变得非常简单，尽管它确实需要前期的投资是项目建立的时间。

在主要项目中，我为20个项目中的每一个建立了领域( TFS术语)。这些领域与每个项目之间存在着1:1的关系。然后，每个团队成员都可以清楚地了解项目的位置。

为了将所有内容联系在一起，要求代码检查链接到工作项是至关重要的。这将一切都与主要项目中的任务管理联系起来。没有这个，一切都会出错。有了它，我可以毫不费力地跟踪这些项目的变化。

要管理构建，我们有管理部署任务的构建定义。目前有52个构建定义来管理针对不同客户的部署。当然，这与20个项目重叠。在应用程序中，使用转换将所有配置存储在源代码管理中，以便使用正确的配置将构建正确地部署到客户站点。代码被签入到不同的源代码控制区域这一事实与此无关。

最后，为了减少构建的混乱，我编写了一个基于宏的构建控制器GUI，使我能够简单地选择一个客户站点，并构建适当的配置。如果没有胶水，那简直是一场噩梦。现在只需点击几下，我就可以管理这些构建了。

采用这种方法需要经过大量的尝试和错误，从我们的失败中吸取教训，不再重复同样的错误。

希望这能有所帮助。