TFS 和 Scrum - 区域、迭代、积压迭代、冲刺迭代的最佳实践配置
Posted
技术标签:
【中文标题】TFS 和 Scrum - 区域、迭代、积压迭代、冲刺迭代的最佳实践配置【英文标题】：TFS and Scrum - Best Practice configuration for Areas, Iterations, backlog iteration, sprint iteration 【发布时间】：2012-11-18 07:12:57 【问题描述】：这组问题试图引出关于如何使用 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)
从概念上讲，我们对上述内容非常满意，因为它对我们的环境是合乎逻辑的。根据上述情况，我们将拥有以下团队： *“客户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 积压）的文件夹下都有预定义的查询; 等），但这些查询似乎是针对“根项目\发布 1\Sprint 1”进行硬编码的——在给定针对迭代定义的日期的情况下，这些查询是否应该自动发现当前 sprint？如果不是，那么维护这些查询的最佳做法是什么？
您是否知道一些高质量的 TFS 2012 和 Scrum 2 特定培训/教程可能有助于解决这些问题，或为成功设置 Scrum 2 TFS 提供一些指导？
【问题讨论】：
【参考方案1】：与这个问题以及有关 TFS 结构、项目和团队的所有事情有关，@MrHinsh 有以下关于使用 TFS 团队不将它们分配到区域的博客文章。但这并非没有谨慎。
更多信息请访问他的博客：http://nakedalm.com/team-foundation-server-2012-teams-without-areas/
【讨论】：
【参考方案2】：我希望你发现我的帖子有用，我也建议你看看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”区域的根设置为团队默认区域可以吗？
这确实是正确的，当使用这些默认值选择该团队时，应该会创建您的所有工作项。许多组织还创建父或主积压工作，其中创建、订购杂项，然后将其划分为适当的团队积压工作，如 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 迭代设置，我似乎应该只选择（复选框）那些用于计划和后续开发的叶级迭代。因此，扩展上面的示例，我们可能会认为“客户 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 顾问合作。
【讨论】：
感谢 MrHinsh 的详细和量身定制的回复。超出我所希望的并具有重大价值，即使只是为了确认或详细说明现有的理解。选项 3 将当前迭代嵌套在“当前”节点下的“技巧”将非常方便！我希望这对其他人和我们一样有价值。 优秀的答案。谢谢！以上是关于TFS 和 Scrum - 区域、迭代、积压迭代、冲刺迭代的最佳实践配置的主要内容，如果未能解决你的问题，请参考以下文章