Visual studio 2012 “中的子项目”；MSF for Agile“；过程模板

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

---

如何将应用程序划分为不同的存储桶，同时仍将它们保留在同一个TFS项目下？

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

然而，我会质疑这一点的价值。团队的积压工作通常应该代表团队正在做的所有工作，而不考虑其起源。这将允许您相对地优先考虑您的各种项目的工作

---

通过使用区域路径来指示工作项属于哪个应用程序，可以实现所需的报告功能。或者，您可以考虑向工作项添加字段，以指示应用程序将工作项应用到。这样，您就可以两全其美：真正的相对优先级和基于应用程序/产品的报告。

我也走上了这条道路。对于这种情况，似乎没有“最佳实践”

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

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

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

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

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

实施这一方法需要大量的尝试和错误，从失败中吸取教训，不再重蹈覆辙

---

希望这有帮助

…就像每个应用程序都有单独的产品积压。您在旧系统中是如何管理的？这不是TFS的另一个版本吗？要稍微拆分项目，可以为每个项目/团队创建子工作区和迭代，此外，还可以创建团队（WebAccess中的管理概述页面）。为什么只有一个团队项目？我认为有人不了解团队项目。解决这个问题的最好方法可能是让他们理解。@MikeR-我们没有一个用于敏捷过程的旧系统。我们今年才采用了它。当前使用sharepoint对其进行手动跟踪。您和Acerar16讨论的“创建团队”理念解决了我的许多问题。@John Saunders-我们是一个内部应用程序团队，支持60多个小到大的应用程序。方钉，圆孔。我知道下一个问题可能是“敏捷是否合适”。管理层已对此作出裁决，并已告知我们要实施。幸运的是，我们不会创建60个“TFS团队”。我们需要为大约6种主要产品拆分信息。我知道您质疑拆分团队待办事项的价值。对于我们的主要产品，指定的工程师通常不会从一个产品中分离出来。因此，我们将不受惩罚。新团队似乎正是我们想要的。只要开始/结束日期相同，我们就可以为不同的团队关联相同的迭代，这是对的吗？也就是说，在为单个团队查看时，它不会扭曲指标和报告。感谢案例研究Jamie。我现在意识到，我不会在一周内完美地完成这项工作。