TFS和Scrum - 区域、迭代、待办事项迭代、冲刺迭代的最佳实践配置

Question

TFS和Scrum - 区域、迭代、待办事项迭代、冲刺迭代的最佳实践配置

tfsscrumbacklogsprint

26

这组问题试图引出一个最佳实践的答案，关于如何使用Scrum 2在TFS 2012 Areas和Iterations中进行设置。

背景： 我们自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)

问题4) 团队待办事项迭代选择-由于我们的概念是每个客户一个团队而不是每个产品一个团队，这可能会有问题，但也许我理解错了。在TFS区域设置中，您可以指定“团队的待办事项迭代”。我的问题是，我们的PBI（产品待办事项）将是特定于产品的，不希望将它们与来自其他产品的PBI混合在一起。因此，我还无法理解如果我们选择“客户端A”作为“团队的待办事项迭代”，而不是“产品B”，其影响将是什么。我想我在自己混淆 - 什么选择是明智的？

上述问题源于我对所选迭代、区域、团队待办事项迭代和默认区域对每个定义的TFS 2012团队的影响不理解。我在此设置中遇到的一些问题是TFS能否正确识别每个团队的产品待办事项和冲刺待办事项。

我不知道是否为产品有一个团队项目和多个区域（通常推荐）会使问题复杂化。

问题5) TFS Web Access网站- 对于“WORK | work items | Shared Queries”下的任何给定团队，都有一个名为“Current Sprint”的文件夹下的预定义查询（阻止任务;冲刺待办任务;等），但似乎这些查询针对“Root Project\Release 1\Sprint 1”进行硬编码-它们不应该自动发现指定迭代日期吗？如果不能，那么维护这些查询的最佳实践是什么？

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

- Jaans

2个回答

1

关于此问题以及所有与TFS结构、项目和团队有关的事项，@MrHinsh在他的博客文章中介绍了如何使用TFS Teams不分配到一个区域。但需要注意的是。

更多信息请参阅他的博客：http://nakedalm.com/team-foundation-server-2012-teams-without-areas/

- Jaans

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- MrHinsh - Martin Hinshelwood · Accepted Answer

我希望我的文章对您有所帮助，我还建议您查看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”区域的根设置为团队的默认值是否可以？

是的，这是正确的，并且应该会导致在选择该团队时创建所有工作项以及使用这些默认设置。许多组织还会创建一个 parent 或 master backlog，其中创建杂项项目，对其进行排序，然后将其划分到适当的团队 backlog 中，正如 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解决方案的其他部分。

你理解和使用得很好。但要想在Scrum流程中拥有可操作的待办事项清单，你需要看三个Sprint之后的内容。我建议按顺序连续编号你的Sprint，这样在UI界面上当你打勾第四个叫做Sprint 1的Sprint时，你就不会混淆它是否属于Sprint 2了。同时，记录当前团队的经验水平也是一个好习惯。

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

但在技术过程和结果方面，你的理解是基本正确的。

你没有让自己困惑。团队中输入条目的人需要将默认值更改为他们想要更改的产品的迭代/区域。至少，默认情况下，你得到了正确的团队，这应该是一个容易分类的事情，无论是输入条目的人、产品负责人还是团队成员。

你指定的团队默认区域下的任何内容都默认包括在你看到的项目中。你可以“右键单击”团队的默认区域并取消选择“包括子区域”，这样你只能看到顶层，这是Greg的主备忘录使用的技术。然而，我建议你保持“包括子区域”的设置，以便团队内部具有可见性和透明度。

有一个团队项目和多个产品区域（通常推荐）是否会使问题变得复杂，我不知道。

这可能会使问题复杂化。一些组织喜欢在他们的工作项中添加“团队”下拉列表（如Conchango/EMC模板），并将其用作团队指定，可以在敏捷计划工具配置中配置为默认值。如果你遇到了这种情况，那么你就不需要在区域或迭代中进行团队指定。如果没有更多的组织配置信息，我无法推荐任何一种方式。

对于“WORK | work items | Shared Queries”下的任何给定团队，有一个预定义的查询文件夹称为“Current Sprint”（Blocked Tasks; Sprint Backlog;等），但是看起来这些查询是针对“Root Project\Release 1\Sprint 1”硬编码的-它们不会自动发现基于迭代日期的当前冲刺是哪个吗？如果不是，那么如何维护这些查询的最佳实践呢？

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

选项2：创建工具来替你完成这项任务

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

我建议从Scrum.org获得专业的Scrum开发者培训，或与ALM顾问互动。