这组问题试图引出关于如何使用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”区域的根目录设置为团队的默认区域吗？
对于迭代布局，我们计划类似的东西，如：
-> 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区域设置中，您指定哪个迭代是“团队的Backlog迭代”。我的问题是我们的PBI（产品待办事项项目）将是特定于产品的，并且不希望将它们与来自其他产品的PBI混合。所以我无法理解的是，如果我们选择区域“客户端A”作为“团队的Backlog迭代”而不是“产品B”，将会产生什么影响。我想我在这里感到困惑 - 这将是一个明智的选择吗？
上述问题使我无法理解这些选择对于每个定义的TFS 2012团队的迭代，区域，团队积压迭代和默认区域的影响。我在这个设置中遇到的一些问题是TFS能够正确识别团队的产品积压和sprint积压。
我不知道是否有一个团队项目和多个产品领域（通常建议）会使问题复杂化。
问题5） TFS Web Access网站 - 对于“WORK |工作项|共享查询”下的任何给定团队，在名为“当前Sprint”的文件夹下有预定义查询（阻止任务; Sprint积压;等等），但似乎这些查询是针对“Root Project \ Release 1 \ Sprint 1”进行硬编码的 - 如果这些查询根据迭代定义的日期不能自动发现哪个是当前sprint？如果没有，那么维护这些查询的最佳做法是什么？
您是否知道可能有助于解决这些问题的一些优质TFS 2012和Scrum 2特定培训/教程，或者为成功的Scrum 2 TFS设置提供一些指导？
答案 0 :(得分：26)
我希望您找到了我的帖子，我还建议您查看One Team Project to rule them all和TFS vNext: Configuring your project to have a master backlog and sub-teams。
我尽最大努力回答您的问题：
问题1）我们认为，由于我们的团队规模不大且管理更易于管理，因此我们不想为每个产品定义团队，因为我们每个客户都有团队，他们监督所有团队该客户的产品。这是一个错误，还是这样？
这很好，可以让你的团队成长。如果您的团队成员跨多个客户端工作，您可能会遇到优先级和上下文切换问题，您可以通过将团队提升到一个级别，或者使用单个统一的待办事项和单独的子团队来最小化这些问题，但仍然关注客户端工作而不是产品工作。我确实会推荐这种方法用于你的布局。
问题2）假设上面的团队配置没问题，我们是否更正了＆＃34; map＆＃34;每个团队上面的每个领域，即团队＆＃34;客户A团队＆＃34;指定区域＆＃34;客户A＆＃34; （以及所有子区域）作为该团队拥有的区域。那么默认区域是否可以设置＆＃34;客户端A＆＃34; area作为团队的默认值？
这确实是正确的，并且当使用这些默认值选择该团队时，应该导致创建所有工作项。许多组织还创建了一个父或主积压，其中创建，订购misc项目，然后将其分成适当的团队积压，作为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解决方案的其他部分。
问题3）这似乎更难以使迭代正确，特别是当TFS显示积压时。具体来说，对于TFS Scrum 2迭代设置，似乎我应该选择（复选框）仅用于规划和后续开发的叶级迭代。因此，扩展上面的例子，我们可能会拥有＆＃34;客户A团队＆＃34;将在接下来的4周内开始研究新产品B（假设为期2周的冲刺）。那么我们只选择（复选框）＆＃34; Sprint 1＆＃34;和＆＃34; Sprint 2＆＃34;从第1版？我能正确理解/使用它吗？
你是，但是你真的在寻找3 Sprint，以便在Scrum流程中有可操作的积压。我建议连续对你的冲刺进行连续编号，这样你在UI中就不会对Sprint 2感到困惑，如果它被称为Sprint 1，你也可以选择Sprint 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)
但是，从根本上讲，所涉及的技术流程及其取得的成果是正确的。
问题4）团队积压迭代选择 - 由于我们的概念是每个客户而不是每个产品的团队，这可能会有问题，但也许我只是理解错了。在TFS区域设置中，您可以为团队指定＆＃34; Backlog迭代的哪些迭代＆＃34;。我的问题是我们的PBI（产品待办事项项目）将是特定于产品的，并且不希望将它们与来自其他产品的PBI混合。所以我无法理解的是，如果我们选择区域＆＃34;客户A＆＃34;作为团队的＆＃34; Backlog迭代＆＃34;而不是＆＃34;产品B＆＃34;。我想我在这里让自己感到困惑 - 这将是一个明智的选择吗？
您不会混淆自己，并且在团队积压中输入内容的人需要将默认值更改为他们希望更改的产品的迭代/区域。至少默认情况下您获得正确的信息对于输入项目的人员，产品负责人或团队成员来说，团队和这应该是一件容易的事情。
您指定为团队默认值的区域下的任何内容默认包含在您看到的项目中。您可以在团队的默认区域上“右键单击”，然后取消选择“包括子区域”，这样您就只能看到顶层，这是用于Greg主备份的技术。不过，我建议您保持“包含子区域”的设置，以提高团队的可见性和透明度。
我不知道是否有一个团队项目和多个产品领域（通常建议）会使问题复杂化。
它可以。有些组织更喜欢将“团队”的下拉列表添加到其工作项（如Conchango / EMC模板）中，并将其用作团队名称，可以在Agile Planning Tools配置中将其配置为默认值。这样，如果您遇到这种情况，则不需要在Area或Iteration中指定Team。如果没有关于如何配置组织的更多信息，我无论如何都不建议。
问题5）TFS Web Access网站 - 适用于＆＃34; WORK |下的任何特定团队工作项目|共享查询＆＃34;在名为＆＃34; Current Sprint＆＃34;的文件夹下有预定义的查询。 （阻止任务; Sprint Backlog;等等），但似乎这些查询是针对＆＃34; Root Project \ Release 1 \ Sprint 1＆＃34;进行硬编码的。 - 如果根据迭代定义的日期，这些不会自动发现哪个是当前的sprint？如果没有，那么维护这些查询的最佳做法是什么？
选项1：每个Sprint花费2分钟来更改查询
选项2：创建一个工具来为您完成
选项3：在Release中添加一个“Current”迭代节点，并将当前活动的迭代移动到该节点下方。然后将查询设置为指向“客户端A \产品A \版本1 \当前”的“下”。然后更快地更改嵌套迭代一次并且所有查询都有效。然后，您只需要更改当前但每次发布一次。
您是否知道可能有助于解决这些问题的一些优质TFS 2012和Scrum 2特定培训/教程，或者为成功的Scrum 2 TFS设置提供一些指导？
我会推荐Scrum.org的专业Scrum开发人员培训或/和ALM顾问合作。
答案 1 :(得分：1)
与此问题以及有关TFS结构，项目和团队的所有事项相关，@ MRHinsh上有关于使用TFS团队而不是将其分配到区域的以下博客文章。但这并非毫无顾忌。
更多关于他的博客：http://nakedalm.com/team-foundation-server-2012-teams-without-areas/