TFS 2015多个产品的迭代组织

问题描述:

我们的开发团队正在升级到TFS 2015,我们能够从头开始我们的工作项目跟踪,所以我期待利用这一点重新组织我们目前的一些流程。TFS 2015多个产品的迭代组织

但是我想不出来组织在多个产品迭代一个合乎逻辑的方式,这里就我们今天的所作所为

    一些背景 - 我们有1个个小队以3个开发人员,我们对3的所有工作不同的产品同时在桌面,网络和移动是这三种产品,他们都是由同一客户拥有密切相关
    - 我有TFS设置为1大型团队项目,因为我读过这是最好的方法组织工作而不是单独的团队项目
    - 每个产品都有不同的构建麻木呃所以我们可以识别不同的发行版本的每个产品

事情我已经尝试了迭代组织:

    - 迭代每个产品(编号桌面/移动build1.1/build3.1网/ build4.1 )这是行不通的,因为我只能将其中的一个设置为“当前”,但实际上我们正在同时处理所有这3个问题
    - 单次迭代编号(root/build1.1)这对我们来说也是没有意义的,因为1.1只适用于其中一种产品,当我为产品创建构建版本时,它们将具有与TFS不匹配的内部版本号。并非所有3款产品每次都会发布,因此即使我对所有3版本使用了单一版本号,在当前版本中未更新的产品的发布版本号也会有差距。
    - 子迭代中,我可以将mobile/build3.1作为desktop/build1.1的子项,但它不会在'Current'下显示,所以我们不会直观地看到当前版本将包含mobile3。 1项还
    - 我读过,我们可以为每个产品创建单独的团队,但我们必须切换仪表板才能看到每个产品的当前版本。这也感觉很奇怪,因为它只是3个人一起工作的多个产品

我的目标是让我们能够看到每个不同的产品发布号码,其中包含当前项目分配给它在一个地方,任何人都可以建议一种组织这方面的方法?

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

几天前有一个Similar question这是由杰西Houwing很好的回答。

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