我们的开发团队正在升级到 TFS 2015，我们能够从头开始工作项跟踪，因此我希望利用这一点来重新组织我们当前的一些流程。
但是，我无法找到一种合乎逻辑的方式来组织跨多个产品的迭代，以下是我们今天所做工作的一些背景
- - 我们有 1 个小团队和 3 名开发人员，我们都同时开发 3 种不同的产品，桌面、Web 和移动是 3 种产品，它们都由同一客户拥有
- - 我将 TFS 设置为一个大型团队项目，因为我已经阅读了这是组织工作而不是单独的团队项目的最佳方式
- - 每个产品都有不同的内部版本号，因此我们可以为每个产品识别不同的发行版本
我尝试过迭代组织的事情：
- - 每个产品的迭代次数（桌面/内部版本1.1移动版/内部版本3.1 web/build4.1） 这不起作用，因为我只能将其中一个设置为"当前"，但实际上我们正在同时处理所有 3
- - 单个迭代次数（根/构建1.1） 这对我们来说在逻辑上也没有意义，因为 1.1 仅适用于其中一个产品，当我为产品创建构建时，它们将具有与 TFS 不匹配的不同内部版本号。此外，并非所有 3 种产品每次都发布，因此即使我对所有 3 个产品使用单个版本号，当前版本中未更新的产品的发布版本号也会有差距
- 作为桌面/build1.1 的子项，但它不会在"当前"下以这种方式显示，因此我们不会直观地看到当前版本也将包括 mobile3.1 项目
- - 我读到我们可以为每个产品创建单独的团队，但随后我们必须切换仪表板以查看每个产品的当前版本。这也感觉很奇怪，因为它只是相同的 3 个人在开发多个产品
我的目标是让我们能够在一个地方看到每个不同的产品版本号，这些版本号分配了当前项目，任何人都可以建议一种组织方法吗？
我不认为迭代路径是这里要走的路，也不是多个团队。 使用迭代路径跟踪团队的冲刺，并保持单个团队，因为你是一个小团队。
几天前有一个类似的问题，杰西·霍温（Jesse Houwing）很好地回答了这个问题。
标记可能是最简单的方法，但你可能会发现创建可链接到积压工作项的自定义工作项类型（发布）更好，或者可能只是 PBI 上的自定义字段。