TFS 和 Scrum - 区域、迭代、积压迭代、冲刺迭代的最佳实践配置

Question

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

上下文:
自 TFS 2005 以来，我们一直在使用 Team System，最初为我们拥有的每个产品创建了一个团队项目，然后使用了 MSF 4.2 流程模板，我们最终对其进行了微调(仅向某些工作项类型添加了几个字段)。

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

http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/

TFS Areas, Optimal Definition and Configuration

Team Foundation Server - Area / Iteration

我们计划申请区域的典型布局是这样的:

-> 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)

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

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

问题 2) 假设上面的团队配置没问题，那么我们是否正确地将上面的每个区域“映射”到每个团队，即对于团队“Client A Team”指定区域“Client A”(和所有子区域)作为区域归那支球队所有。默认区域呢，可以把“Client 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 周内开始新产品 B 的工作(假设有 2 周的冲刺)。那么我们是否只从第 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 设置提供一些指导？

Answer 1

我希望你能使用我的帖子，我也建议你看看 One Team Project to rule them all和 TFS vNext: Configuring your project to have a master backlog and sub-teams .

以下是我尽力回答您的问题:

Question 1) We figured that because our teams aren't that big and to make administration more manageable, that we didn't want to define teams per product since we physically have teams per client and they oversee all the products for that client. Is this a mistake, or is this OK?

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

Question 2) Assuming that the above team configuration is OK, are we then correct to "map" each of the areas above to each team i.e. For team "Client A Team" specify area "Client A" (and all sub-areas) as the areas to be owned by that team. What about the default area, is it ok to set the root of the "Client A" area as the default for the team?

这确实是正确的，并且应该会在使用这些默认值选择该团队时创建您的所有工作项。许多组织还创建了一个父级或主待办事项列表，其中创建、排序杂项，然后将其划分为适当的团队待办事项列表，TFS 敏捷规划工具的产品负责人 Greg Boer 在他的博文 TFS vNext: Configuring your project to have a master backlog and sub-teams 中写道。 .

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

-> 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 解决方案的其他部分。

Question 3) This seems to be trickier to get the iterations right, especially when it comes to TFS showing the backlog. Specifically, for the TFS Scrum 2 Iteration setup, it seems that I should be selecting (check box) only those leaf level iterations that are for planning and subsequent development. So extending the above example, we might have that the "Client A Team" will be available to start work on a new Product B for the next 4 weeks (assume 2 week sprints). Would we then only select (check box) "Sprint 1" and "Sprint 2" from Release 1? Am I understanding/using it correctly?

你是，但你真的在寻找 3 个 Sprint，以便在 Scrum 过程中拥有一个可操作的待办事项。我建议您按顺序对您的冲刺进行连续编号，以便在用户界面中您不会对冲刺 2 感到困惑，如果它被称为冲刺 1，则您还勾选冲刺 4。 记录当前团队的经验水平也很好.

-> 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)

但是您对所涉及的技术过程及其将实现的结果从根本上是正确的。

Question 4) Team Backlog Iteration selection - This might be problematic due to our concept of having teams per client and not teams per product, but maybe I just understand it wrong. In TFS Areas setup, you specify which iterations the "Backlog iteration for the team". My problem is that our PBI (Product Backlog Items) will be product specific and do not wish to mix them with PBIs from another product. So what I'm unable to understand yet is what the impact will be if we select area "Client A" as the "Backlog iteration for the team" instead of perhaps "Product B". I think I'm confusing myself here - what would be a sensible choice?

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

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

I don't know whether have one team project and multiple areas for products (as is generally recommended) is complicating the issue.

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

Question 5) TFS Web Access website - For any given team under "WORK | work items | Shared Queries" there is predefined queries under a folder called "Current Sprint" (Blocked Tasks; Sprint Backlog; etc), but it seems that these queries are hardcoded against "Root Project\Release 1\Sprint 1" - should these not automatically discover which is the current sprint given the dates defined against iterations? If not, then what is the best practice for maintaining these queries?

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

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

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

Do you know of some quality TFS 2012 and Scrum 2 specific training / tutorials that might help address these questions, or give some guidance for a successful Scrum 2 TFS setup?

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