TFS 2015多个产品的迭代组织

时间:2016-01-22 01:58:50

标签: tfs scrum tfs2015 backlog

我们的开发团队正在升级到TFS 2015,我们可以从头开始进行工作项跟踪,因此我希望利用这一点来重新组织我们当前的一些流程。 / p>

但是,我无法找到一种合理的方式来组织多个产品的迭代,这里有一些关于我们今天所做的事情的背景

    - 我们有1个小团队,3个开发人员,我们同时处理3种不同的产品,桌面,网络和移动是3种产品,他们都是由同一客户拥有密切相关的
    - 我将TFS设置为一个大型团队项目,因为我已经读过这是组织工作的最佳方式,而不是单独的团队项目
    - 每个产品都有不同的内部版本号,因此我们可以为每个产品识别不同的发布版本

我为迭代组织所尝试的事情:

    - 每个产品的迭代次数(desktop / build1.1 mobile / build3.1 web / build4.1)这不起作用,因为我只能将其中一个设置为' Current&#39 ;但实际上我们同时处理所有这三个
    - 单个迭代号(root / build1.1)这对我们来说也没有意义,因为1.1仅适用于其中一个产品,当我为产品创建构建时,它们将具有不同的构建号这不符合TFS。此外,并非每次都会发布所有3种产品,因此,即使我使用了所有3种产品的单一版本号,在当前版本中未更新的产品的发布版本号中也存在差距< / UL>
      - 子迭代,我可以将mobile / build3.1作为desktop / build1.1的子代,但它并没有以这种方式显示在&#39; Current&#39;所以我们不会在视觉上看到当前版本还包括mobile3.1项目
      - 我已经读过,我们可以为每个产品创建单独的团队,但是我们必须切换仪表板才能看到每个产品的当前版本。这也很奇怪,因为它只是同样的3个人从事多种产品

    我的目标是让我们能够在一个单独的地方看到每个不同的产品发布号码,并将当前项目分配给它,有人可以建议一种方法来组织这个吗?

1 个答案:

答案 0 :(得分:0)

我不觉得迭代路径是去这里的方式,也不是多个团队。使用迭代路径来跟踪团队的冲刺并保持一个团队,因为你是一个小团队。

几天前有一个Similar question,杰西·怀特很好地回答了这个问题。

标签可能是最简单的方法,但您可能会发现创建一个自定义工作项类型(发布),您可以链接到Backlog项目更好,或者只是PBI上的自定义字段。