TFS 2015多产品迭代组织

我们的开发团队正在升级到TFS 2015，我们能够从头开始跟踪工作项，因此我希望借此机会重新组织我们当前的一些流程

然而，我无法找出一种逻辑方法来组织跨多个产品的迭代，下面是我们今天所做工作的一些背景

-我们有一个小团队，有3名开发人员，我们都同时开发3种不同的产品，桌面、web和移动是这3种产品，它们都是由同一客户拥有的密切相关的产品

-我将TFS设置为一个大型团队项目，正如我所读到的，这是组织工作的最佳方式，而不是单独的团队项目

-每个产品都有不同的版本号，因此我们可以为每个产品确定不同的发布版本

我尝试过的迭代组织方法：

-每个产品的迭代次数（desktop/build1.1 mobile/build3.1 web/build4.1）这不起作用，因为我只能将其中一个设置为“当前”，但实际上我们正在同时处理所有3个
-单次迭代编号（root/build1.1）这在逻辑上对我们来说也没有意义，因为1.1只适用于其中一个产品，当我为这些产品创建构建时，它们将具有不同的构建编号，而这些编号与TFS不匹配。此外，并非所有3款产品都是每次发布的，因此，即使我对所有3款产品使用了一个发布号，对于当前版本中未更新的产品，发布版本号也会存在差距
-子迭代，例如，我可以将mobile/build3.1作为desktop/build1.1的子版本，但它不会以这种方式显示在“Current”下，因此我们不会从视觉上看到当前版本也会包括mobile3.1项目
-我已经读到，我们可以为每个产品创建单独的团队，但随后我们必须切换仪表板以查看每个产品的当前构建。这也让人感到奇怪，因为同样是3个人在多个产品上工作

---

我的目标是让我们能够在一个单独的地方看到每个不同的产品发布号，其中有分配给它的当前项目，有人能建议一种组织方式吗
我不认为迭代路径是解决问题的方法，多个团队也是如此。使用迭代路径跟踪团队的冲刺，并保持单个团队，因为您是一个小团队
几天前，杰西·霍温（Jesse Houwing）很好地回答了一个问题
标记可能是最简单的方法，但是您可能会发现创建一个可以链接到Backlog项的自定义工作项类型（Release）更好，或者可能只是PBI上的一个自定义字段