【问题标题】:TFS 2015 Iteration Organization for Multiple ProductsTFS 2015 多个产品的迭代组织
【发布时间】:2016-04-28 12:37:10
【问题描述】:

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

但是我想不出一个合理的方式来组织多个产品的迭代,这里是我们今天所做的一些背景

    - 我们有 1 个小团队和 3 个开发人员,我们都同时开发 3 个不同的产品,桌面、Web 和移动是 3 个产品,它们都密切相关,属于同一个客户
    - 我已将 TFS 设置为 1 个大型团队项目,因为我已经阅读过这是组织工作而不是单独的团队项目的最佳方式
    - 每个产品都有不同的内部版本号,因此我们可以为每个产品确定不同的发布版本

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

    - 每个产品的迭代号 (desktop/build1.1 mobile/build3.1 web/build4.1) 这不起作用,因为我只能将其中一个设置为“当前”,但实际上我们是同时处理这三个方面
    - 单次迭代编号 (root/build1.1) 这对我们来说在逻辑上也没有意义,因为 1.1 仅适用于其中一种产品,当我为产品创建构建时,它们将具有不同的构建编号不匹配 TFS。此外,并非每次都发布所有 3 个产品,因此即使我对所有 3 个产品都使用了一个版本号,当前版本中未更新的产品的版本号也会有差距
    - 子迭代,例如,我可以将 mobile/build3.1 作为 desktop/build1.1 的子级,但它不会在“当前”下以这种方式显示,因此我们不会直观地看到当前版本还将包括 mobile3.1 项目
    - 我读到我们可以为每个产品创建单独的团队,但是我们必须切换仪表板才能查看每个产品的当前构建。这也让人感觉很奇怪,因为这只是 3 个人在开发多种产品

我的目标是让我们能够在一个地方查看分配了当前项目的每个不同的产品版本号,任何人都可以提出一种组织方法吗?

【问题讨论】:

    标签: tfs scrum tfs-2015 backlog


    【解决方案1】:

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

    几天前有一个Similar question,Jesse Houwing 回答得很好。

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-11-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-02-03
      • 1970-01-01
      • 2013-12-11
      相关资源
      最近更新 更多