Jaa*_*ans 26 tfs scrum sprint backlog tfs2012
这组问题试图引出关于如何使用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"(以及所有子区域)为该团队拥有的区域.那么默认区域,可以将"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区域设置中,您指定哪个迭代是"团队的Backlog迭代".我的问题是我们的PBI(产品待办事项项目)将是特定于产品的,并且不希望将它们与来自其他产品的PBI混合.所以我无法理解的是,如果我们选择区域"客户端A"作为"团队的Backlog迭代"而不是"产品B",那将会产生什么影响.我想我在这里让自己感到困惑 - 这将是一个明智的选择吗？
上述问题使我无法理解这些选择对于每个定义的TFS 2012团队的迭代,区域,团队积压迭代和默认区域的影响.我在此设置中遇到的一些问题是TFS能够正确识别团队的产品积压和sprint积压.
我不知道是否有一个团队项目和多个产品领域(通常建议)使问题复杂化.
问题5) TFS Web Access网站 - 对于"WORK | work items | Shared Queries"下的任何给定团队,在名为"Current Sprint"的文件夹下有预定义的查询(Blocked Tasks; Sprint Backlog;等),但似乎这些查询对"Root Project\Release 1\Sprint 1"进行了硬编码 - 如果根据迭代定义的日期,这些是不是会自动发现哪个是当前的sprint？如果没有,那么维护这些查询的最佳做法是什么？
您是否了解可能有助于解决这些问题的一些优质TFS 2012和Scrum 2特定培训/教程,或者为成功的Scrum 2 TFS设置提供一些指导？
MrH*_*ood 26
我希望你能找到我的帖子,我还建议你看一个团队项目来统治他们所有和TFS vNext:配置你的项目有一个主积压和子团队.
以下是我尽力回答您的问题:
问题1)我们认为,因为我们的团队不是那么大,并且使管理更易于管理,所以我们不想为每个产品定义团队,因为我们实际上每个客户都有团队,他们监督该客户的所有产品.这是一个错误,还是这样？
这很好,可以让你的团队成长.如果您的团队成员跨多个客户端工作,您可能会遇到优先级和上下文切换问题,您可以通过将团队提升到一个级别,或者使用单个统一的待办事项和单独的子团队来最小化这些问题,但仍然关注客户端工作而不是产品工作.我确实会推荐这种方法来进行布局.
问题2)假设上述团队配置正常,我们是否更正将每个上面的区域"映射"到每个团队,即团队"客户A团队"指定区域"客户A"(以及所有子区域)为该团队拥有的区域.那么默认区域,可以将"Client A"区域的根目录设置为团队的默认区域吗？
这确实是正确的,并且当选择具有这些默认值的团队时,应该导致创建所有工作项.许多组织还创建了一个父或主积压,其中misc项目被创建,订购,然后被分成适当的团队积压作为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周内开始处理新产品B(假设为期2周的冲刺).那么我们只能从第1版中选择(复选框)"Sprint 1"和"Sprint 2"吗？我是否正确理解/使用它？
你是,但是你真的在寻找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区域设置中,您可以指定哪些迭代"团队的Backlog迭代".我的问题是我们的PBI(产品待办事项项目)将是特定于产品的,并且不希望将它们与来自其他产品的PBI混合.所以我无法理解的是,如果我们选择区域"客户端A"作为"团队的Backlog迭代"而不是"产品B",那将会产生什么影响.我想我在这里让自己感到困惑 - 这将是一个明智的选择吗？
您不会混淆自己,并且在团队积压中输入内容的人需要将默认值更改为他们希望更改的产品的迭代/区域.至少默认情况下您获得正确的团队和此对于输入物品的人,产品负责人或团队成员来说,这应该是一件容易的事情.
您指定为团队默认值的区域下的任何内容默认包含在您看到的项目中.您可以在团队的默认区域上"右键单击"并取消选择"包含子区域",这样您只能看到顶级,这是用于Greg主要积压的技术.但是,我建议您保持"包括子区域"的设置,以提高团队的可见性和透明度.
我不知道是否有一个团队项目和多个产品领域(通常建议)使问题复杂化.
它可以.有些组织更喜欢将"团队"的下拉列表添加到其工作项(如Conchango/EMC模板)中,并将其用作团队名称,可以在Agile Planning Tools配置中将其配置为默认值.这样,如果您遇到这种情况,则不需要在Area或Iteration中指定Team.如果没有关于组织配置方式的更多信息,我无论如何都不建议.
问题5)TFS Web Access网站 - 对于"WORK | work items | Shared Queries"下的任何给定团队,在名为"Current Sprint"的文件夹下有预定义的查询(Blocked Tasks; Sprint Backlog;等),但似乎这些查询对"Root Project\Release 1\Sprint 1"进行了硬编码 - 如果根据迭代定义的日期,这些是不是会自动发现哪个是当前的sprint？如果没有,那么维护这些查询的最佳做法是什么？
选项1:每个Sprint花费2分钟来更改查询
选项2:创建一个工具来为您完成
选项3:在Release中添加一个"Current"迭代节点,并将当前活动的迭代移动到该节点下面.然后将查询设置为指向"客户端A \产品A \版本1 \当前"的"下".然后更快地更改嵌套迭代一次并且所有查询都有效.然后,您只需要更改当前但每次发布一次.
您是否了解可能有助于解决这些问题的一些优质TFS 2012和Scrum 2特定培训/教程,或者为成功的Scrum 2 TFS设置提供一些指导？
我会推荐Scrum.org的专业Scrum开发人员培训或/和ALM顾问合作.