TFS中有多个版本的迭代

TFS（特别是Visual Studio Online）中应该如何构建版本和迭代？迭代中的某些工作只计入一个版本，而其余工作计入另一个版本？TFS中有多个版本的迭代

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

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

当一些迭代1的工作，例如，将不会在维护发布版本1而是未来发生的问题“2.0版”发布。

我想的结构更加类似这样的，至少在概念上，但没有重复迭代：

我所考虑的尝试：将我们的团队重组为拥有仅维护和“2.0版” - 只有开发人员不是一种选择。将我们的迭代分解为仅维护版本和“2.0版本” - 仅仅是不现实的（我们需要快速的维护周转，因此需要在每次迭代中进行工作）。规划2个并发迭代看起来像是过度杀伤。

2015-02-10 Keith

我已经通过迭代将分支分割成迭代的不同子节点来解决此限制。毕竟，树中没有真正的“类型”概念，所以节点可以是任何你想要的。

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

2015-03-16 22:05:57 Keith

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

您所描述的问题随即消失。

噢，您可能希望使用标签标记您的维护（Opex）工作以供日后使用。

2015-02-11 05:22:33

好的建议，但不幸的是我们的V2更改太复杂，无法在同一分支中进行管理。我正在看标签，我并不满意他们的发布跟踪，但到目前为止，他们看起来像我最好的替代品。 – Keith 2015-02-16 18:30:27

看起来你似乎是在人为地将你的迭代结构绑定到你的分支结构上。

如果您在“分支1”和“分支2”的Iteration 1中工作，那么为什么不使用单个迭代，而是使用两个区域路径？这样，您可以在同一次迭代中为这两个区域创建用户故事和任务。

2015-03-16 22:25:45

回答