在TFS中使用多个版本的迭代

Question

应该如何在TFS (特别是Visual )中构建发布和迭代，其中迭代中的一些工作对一个版本进行计算，而其余的工作则依赖于另一个版本

一些背景:我正在与一个拥有两个代码分支的团队合作:第一个分支用于维护，每两个星期发布一次，第二个分支用于一个长期的“Version2.0”项目(发布时间为6个月)。在每次迭代中，我们都在两个分支中工作，我们都在维护和“Version2.0”项目上工作。

当前的迭代树遵循如下的\<release>\<iteration>模式：

• 待办
  • 维护版本1
    • 迭代1

​

- Maintenance Release 2 
    - **Iteration 2**

​

​

例如，当迭代1中的某些工作不会在维护版本1中发布，而是在未来的“Version2.0”版本中发布时，就会出现问题。

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

• 待办
  • 维护版本1
    • 迭代1

​

- Maintenance Release 2 
    - **Iteration 2**

​

- Version 2.0 Release 
    - **Iteration 1**
    - **Iteration 2**

​

​

我考虑尝试的是:重组我们的团队，使其拥有只维护和“Version2.0”-only开发人员，这不是一种选择。将我们的迭代分解为只进行维护，“Version2.0”-only是不现实的(我们需要在维护方面进行快速的循环，因此工作需要在每次迭代中进行)。规划2次并发迭代似乎有点过火。

Answer 1

我通过迭代将分支划分为迭代的不同子节点来解决这个限制。毕竟，树中并没有“类型”的概念，所以节点可以是您想要的任何东西。

• 待办
  • 2.0版积压
  • 迭代1
    • 维护第1版
    • 2.0版卷

​

- **Iteration 2** 
    - Maintenance Release 2
    - _Version 2.0 Roll-up_

​

- **Iteration 3** 
    - Version 2.0 Release

​

​

另外，我还为分支机构的工作保留了一个单独的待办事项。

Answer 2

最终，您需要通过没有两个分支来解决这个问题。您应该有一个好的产品版本，并将v2的特性隐藏在功能标志后面。然后，您可以将任何工作、特性或维护添加到每个增量中，并在每个sprint的末尾发送。在这一点上，您可以选择您随维修工作一起送货的特性。

你当时描述的问题就消失了。

哦，您可能希望使用标记来标记您的维护(Opex)工作，以便以后使用。

Answer 3

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

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