TFS 中多个版本的迭代

Iterations with multiple releases in TFS

应该如何在 TFS 中构建发布和迭代（特别是 Visual Studio 在线），其中 迭代中的一些工作计入一个版本，而其余工作计入另一个版本?

一些背景：我正在与一个有 2 个代码分支的团队合作：第一个分支用于维护，每 2 周发布一次，第二个分支用于长期 "Version 2.0" 项目（发布在 6 个月内）。我们在每个迭代中都在两个分支中工作，我们都在维护和 "Version 2.0" 项目上工作。

我们当前的迭代树遵循这样的 \<release>\<iteration> 模式：

例如，迭代 1 中的某些工作不会在 维护版本 1 中发布，而是未来 "Version 2.0" 版本。

我希望结构更像这样，至少在概念上是这样，但不要重复迭代：

我考虑过的尝试：重组我们的团队以拥有仅维护和 "Version 2.0"- 开发人员不是一种选择。将我们的迭代分解为仅维护和 "Version 2.0"-only 是不现实的（我们需要快速周转维护，因此需要在每次迭代中进行工作）。计划 2 个并发迭代似乎有点矫枉过正。

最终你需要通过没有两个分支来解决这个问题。您应该拥有产品的单一良好版本，并将 v2 的功能隐藏在功能标志后面。然后，您可以向每个增量添加任何工作、功能或维护，并在每个冲刺结束时发布。届时，您可以选择随维护工作一起提供的功能。

您所描述的问题就这样消失了。

哦，您可能想使用标签来标记您的维护 (Opex) 工作以备后用。

我通过迭代将分支拆分为迭代的不同子节点来解决此限制。毕竟树中并没有真正"type"的概念，所以节点可以是任何你想要的。

此外，我为分支工作保留了一个单独的积压工作。

您似乎在人为地将迭代结构绑定到分支结构。

如果 "Branch 1" 和 "Branch 2" 都在迭代 1 中工作，那么为什么不使用单个迭代，而是使用两个区域路径？这样，您就可以在同一次迭代中同时拥有这两个领域的用户故事和任务。