26

这组问题试图引出关于如何使用 Scrum 2 设置 TFS 2012 区域和迭代的最佳实践答案。

背景： 自 TFS 2005 以来，我们一直在使用 Team System，最初为我们拥有的每个产品创建了一个团队项目，然后使用了我们最终稍微调整的 MSF 4.2 流程模板（仅向某些工作项类型添加了一些字段）。

向前推进到今天，我们现在运行 TFS 2012 和 VS 2012。考虑到过去的经验和社区反馈，我们将转移到单个团队项目和 Scrum 2.1，然后使用区域来分离产品和团队。以下链接很好地阅读了这种方法：

我们计划申请区域的典型布局如下：

-> Team Project (Area root)
 |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
    |---> Product A
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |   |---> Feature Area 3
    |
    |---> Product B
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |
    | (ETC)

 |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
    |---> Product C
    |   |---> Feature Area 1
    |   |---> Feature Area 2
    |
    | (ETC)

从概念上讲，我们对上述内容非常满意，因为它对我们的环境是合乎逻辑的。根据以上内容，我们将有以下团队：*“客户 A 团队”*“客户 B 团队”

问题 1)我们认为，由于我们的团队规模不大，并且为了使管理更易于管理，我们不想为每个产品定义团队，因为我们实际上每个客户都有团队，他们监督该客户的所有产品。这是一个错误，还是可以？

问题 2）假设上述团队配置正常，那么我们是否正确将上述每个区域“映射”到每个团队，即对于团队“客户 A 团队”，指定区域“客户 A”（以及所有子区域）为该团队拥有的区域。那么默认区域呢，将“客户端A”区域的根设置为团队默认区域可以吗？

至于迭代布局，我们计划类似的东西，像这样：

-> Team Project (iteration root)
 |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
    |---> Product A
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |   |---> Sprint 3
    |   |
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |   |---> Sprint 3
    |   |
    |   |---> Release 3
    |
    |---> Product B
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   | 
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |
    | (ETC)

 |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
    |---> Product C
    |   |---> Release 1
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |   |
    |   |---> Release 2
    |   |   |---> Sprint 1
    |   |   |---> Sprint 2
    |
    | (ETC)

问题 3)正确进行迭代似乎比较棘手，尤其是在 TFS 显示积压时。具体来说，对于 TFS Scrum 2 迭代设置，我似乎应该只选择（复选框）那些用于规划和后续开发的叶级迭代。因此，扩展上面的示例，我们可能会认为“客户 A 团队”将在接下来的 4 周（假设 2 周的 sprint）中开始新产品 B 的工作。那么我们是否只能从 Release 1 中选择（复选框）“Sprint 1”和“Sprint 2”？我是否正确理解/使用它？

问题 4)团队待办事项迭代选择——这可能是有问题的，因为我们的概念是每个客户都有团队，而不是每个产品都有团队，但也许我只是理解错了。在 TFS 区域设置中，您指定哪个迭代是“团队的积压迭代”。我的问题是我们的 PBI（产品待办事项）将是特定于产品的，并且不希望将它们与其他产品的 PBI 混合。所以我还无法理解的是，如果我们选择区域“客户 A”作为“团队的待办事项迭代”而不是“产品 B”，将会产生什么影响。我想我在这里让自己感到困惑 - 什么是明智的选择？

上述问题使我不了解这些迭代、区域、团队积压迭代和默认区域的选择将对每个定义的 TFS 2012 团队产生什么影响。我在此设置中遇到的一些问题是 TFS 无法正确识别团队的产品待办事项和冲刺待办事项。

我不知道是否有一个团队项目和多个产品领域（通常建议）使问题复杂化。

问题 5) TFS Web 访问网站 - 对于“工作 | 工作项 | 共享查询”下的任何给定团队，在名为“当前 Sprint”（阻止任务；Sprint 积压等）的文件夹下都有预定义的查询，但似乎这些查询针对“Root Project\Release 1\Sprint 1”进行了硬编码——在给定针对迭代定义的日期的情况下，这些是否不应该自动发现当前的 sprint？如果不是，那么维护这些查询的最佳做法是什么？

您是否知道一些高质量的 TFS 2012 和 Scrum 2 特定培训/教程可能有助于解决这些问题，或者为成功的 Scrum 2 TFS 设置提供一些指导？

4

2 回答 2

26

我希望你找到了我的帖子的用途，我还建议你看一下One Team Project to rule them all和TFS vNext：Configuring your project to have a master backlog and sub-teams。

这是我尽力回答您的问题：

问题 1) 我们认为，由于我们的团队规模不大，并且为了使管理更易于管理，我们不想为每个产品定义团队，因为我们实际上每个客户都有团队，他们监督该客户的所有产品。这是一个错误，还是可以？

这很好，可以让你像你的团队一样成长。如果您的团队成员跨多个客户工作，您可能会遇到优先级和上下文切换问题，您可以通过将团队提升一个级别，或者拥有一个统一的积压工作和单独的子团队，但仍然专注于客户工作而不是产品工作，可以最大限度地减少这些问题。对于您拥有的布局，我确实会推荐这种方法。

问题 2）假设上述团队配置正常，那么我们是否正确将上述每个区域“映射”到每个团队，即对于团队“客户 A 团队”，将区域“客户 A”（和所有子区域）指定为该团队拥有的区域。那么默认区域呢，将“客户端A”区域的根设置为团队默认区域可以吗？

这确实是正确的，并且当使用这些默认值选择该团队时，应该会创建所有工作项。许多组织还创建了一个父积压或主积压，其中创建、排序并划分为适当的团队积压，如 Greg Boer，TFS 敏捷规划工具的产品负责人，在他的帖子TFS vNext：配置您的项目以拥有一个主积压和子团队。

只要您的团队不跨越客户端之间的边界，您的迭代布局确实看起来不错，否则您将开始难以将区域和迭代映射到团队。如果您认为您可能需要将一个团队或一组团队映射到多个客户，那么您可能需要更多类似的东西：

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |---> Release 2
        |   |---> Release 3
        |
        |---> Product B
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

    |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
        |---> Product C
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

虽然仍然不是动态的，但这将启用该场景。但是，我仍会保留我的 $\TeamProject\Client A\ProductA 源代码控制结构，而不是对其进行过滤。它只是对规划过程的划分，不应该溢出到 ALM 解决方案的其他部分。

问题 3) 正确进行迭代似乎比较棘手，尤其是在 TFS 显示积压时。具体来说，对于 TFS Scrum 2 迭代设置，我似乎应该只选择（复选框）那些用于规划和后续开发的叶级迭代。因此，扩展上面的示例，我们可能会认为“客户 A 团队”将在接下来的 4 周（假设 2 周的 sprint）中开始新产品 B 的工作。那么我们是否只能从 Release 1 中选择（复选框）“Sprint 1”和“Sprint 2”？我是否正确理解/使用它？

你是，但你真的在寻找 3 个 Sprint 以作为 Scrum 流程的一部分来获得可操作的积压工作。我建议您按顺序对您的 sprint 进行连续编号，以便在 UI 中您不会对 Sprint 2 感到困惑，如果您也勾选 Sprint 4（如果它称为 Sprint 1）。保持对当前团队的经验水平的统计也很好.

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |   |---> Sprint 1
        |   |   |---> Sprint 2
        |   |   |---> Sprint 3
        |   |---> Release 2
        |   |   |---> Sprint 4
        |   |   |---> Sprint 5
        |   |   |---> Sprint 6
        |   |---> Release 3
        |   |   |---> Sprint 7
        |   |   |---> Sprint 8
        |   |   |---> Sprint 9
        |
        | (ETC)

但是您对所涉及的技术过程及其将达到的结果基本上是正确的。

问题 4) 团队待办事项迭代选择——这可能是有问题的，因为我们的概念是每个客户都有团队，而不是每个产品都有团队，但也许我只是理解错了。在 TFS 区域设置中，您指定哪些迭代是“团队的积压迭代”。我的问题是我们的 PBI（产品待办事项）将是特定于产品的，并且不希望将它们与其他产品的 PBI 混合。所以我还无法理解的是，如果我们选择区域“客户 A”作为“团队的待办事项迭代”而不是“产品 B”，将会产生什么影响。我想我在这里让自己感到困惑 - 什么是明智的选择？

您不会混淆自己，并且将某些内容输入团队积压的人将需要将默认值更改为他们想要更改的产品的迭代/区域。至少在默认情况下，您将获得正确的团队，并且对于输入项目的人、产品负责人或团队成员来说，正确分类应该是一件容易的事。

默认情况下，您指定为团队默认值的区域下的任何内容都包含在您看到的项目中。您可以“右键单击”团队的默认区域并取消选择“包括子区域”，这样您就只能看到顶层，这是用于 Greg 的 Master Backlog 的技术。但是，我建议您保持“包括子区域”的设置，以提高团队内部的可见性和透明度。

我不知道是否有一个团队项目和多个产品领域（通常建议）使问题复杂化。

它可以。一些组织更喜欢将“团队”的下拉列表添加到他们的工作项目（如 Conchango/EMC 模板）中，并将其用作他们的团队名称，可以在敏捷规划工具配置中将其配置为默认值。这样，如果您遇到问题，您就不需要在区域或迭代中指定团队。如果没有有关您的组织如何配置的更多信息，我没有任何建议。

问题 5) TFS Web 访问网站 - 对于“工作 | 工作项 | 共享查询”下的任何给定团队，在名为“当前 Sprint”（阻止任务；Sprint 积压等）的文件夹下都有预定义的查询，但似乎这些查询针对“Root Project\Release 1\Sprint 1”进行了硬编码——在给定针对迭代定义的日期的情况下，这些是否不应该自动发现当前的 sprint？如果不是，那么维护这些查询的最佳做法是什么？

选项 1：每个 Sprint 花费 2 分钟来更改查询

选项 2：创建一个工具来为您执行此操作

选项 3：在您的版本中添加一个额外的“当前”迭代节点，并将当前活动的迭代移动到该节点下方。然后将查询设置为指向“Client A\Product A\Release 1\Current”的“Under”。然后更改一次嵌套迭代会更快，所有查询都可以工作。然后，您只需要更改当前版本，但每个版本一次。

您是否知道一些高质量的 TFS 2012 和 Scrum 2 特定培训/教程可能有助于解决这些问题，或者为成功的 Scrum 2 TFS 设置提供一些指导？

我会推荐来自 Scrum.org 的专业 Scrum 开发人员培训或/并与 ALM 顾问合作。

于 2012-12-05T19:45:14.053 回答
1

与此问题以及有关 TFS 结构、项目和团队的所有事情相关，@MrHinsh 有以下关于使用 TFS 团队而不将它们分配到区域的博客文章。但这并非没有谨慎。

更多在他的博客： http: //nakedalm.com/team-foundation-server-2012-teams-without-areas/

于 2013-11-01T13:32:22.187 回答