TFS 2013真实世界的工作项目使用和工作流程

Question

我管理的团队多年来一直在使用TFS，但我们使用第三方系统来跟踪错误和功能。我希望将我们的团队升级到TFS 2013，并且我已经完成了大量的阅读和研究TFS如何管理工作项目，积压，迭代，任务等。虽然我理解“可以”做什么的原则，但我我很难想象我们的团队将如何使用这些工作项作为任务。

如果有人知道任何基于实际样本的最佳实践指南，或者可以回答任何这些非常好的问题

1）产品积压 - 在“配置计划和迭代”下，设置当前“积压迭代”的概念是什么？我们的团队使用带有内部版本号的短2周迭代，但是将构建迭代设置为当前的积压使得所有新的PBI仅限于该迭代。一旦我将当前构建设置为下一个迭代编号，那么在该迭代中未完成的任何项目都将消失。另一方面，如果我将其设置为父根节点，我可以看到PBI列表随着时间的推移变得相当大。管理未分配并使用简单的Parent-＆gt; build1 / build2等结构的PBI的最佳方法是什么？

2）功能 - 所以我创建了一个功能，也许它涵盖了许多工作项和几个任务。它们会随着时间的推移而完成，但我注意到父项目上没有“自动”完成或状态更新。那么谁/什么时候应该标记完成的功能项？如果产品所有者应该使用功能列表来概述工作，他们不知道所有相关项是否已完成以及何时标记功能完成。

3）工作项目 - 管理这些项目，特别是他们的“状态”或状态似乎是一种皇家的痛苦。在任务板上你不能改变他们的状态，只能通过拖放来改变他们的任务，这很不错。但是您完成了所有任务，父工作项仍处于“新建”状态。您是否真的必须对每个工作项进行微观管理，打开它并将状态设置为完成？

4）质量保证/测试 - 对于每个工作项目，每个团队成员负责测试每个项目，因此每个项目都由多人测试，并记录发现的任何问题。为此使用工作项或任务的最佳方法是什么？

5）构建完成 - 迭代中的每个工作项都标记为完成后，我认为它们是从产品待办事项中删除的正确吗？对此的例外似乎是它们所关联的功能，功能项本身保持打开状态。利益相关者如何查看当前构建中已完成的功能列表？

Answer 1

我无法回答所有事情（事实上，没有人能够回答），但是我的团队如何使用TFS - 它可能会给你一些想法：

我们使用区域路径来表示工作所属的项目或Epic。创建工作项时，它将使用“区域路径”分配给项目，并且永远不会更改。

然后代表＆＃34;何时＆＃34;完成工作后，我们在3个标题下使用分层迭代路径（对于名为＆＃34; Project＆＃34;的项目）：Project \ Completed，Project \ Current，Project \ Future。

产品积压中的故事最初分配给Future（事实上我们更进一步，并使用新故事代表＆＃34;提议＆＃34;工作，以及积极代表＆＃34;已批准＆＃34 ;积压 - 这使我们能够计划暂时的项目/合同，当他们获得绿灯时转换成实际工作）。在这个阶段，我们做规划扑克以获得故事点，然后项目经理为故事分配堆栈等级，以帮助决定从建议到产品积压的内容，然后最终我们应该考虑下一次迭代。

当我们开始迭代时，我们在Future下创建一个新的迭代（称为001），即Project \ Future \ 001。然后从Product Backlog中选择Stories进行实现 - 将它们分配给此迭代。当迭代准备开始时，我们使用传送带＆＃34;将所有迭代沿着一个＆＃34;位置移动的方法。在层次结构中：在迭代路径配置UI中，只需将001迭代从Future拖动到Current。这将自动重新路径该路径中的所有内容，以便所有活动的工作立即在Project \ Current。

下

当我们完成迭代时，我们将有Current \ 001，然后我们添加Future \ 002。然后我们沿传送带移动001和002（分别到Project \ Completed \ 001和Project \ Current \ 002）。通过这种方式，工作被分配给一次迭代并保持在那里，但整个迭代从未来......转移到当前......到完成。这使我们可以构建像＆＃34;所有当前工作＆＃34; （所有工作都在＆＃34; Project \ Current＆＃34;）我们不需要为每次迭代重写，这节省了大量时间并消除了很多错误，试图重新分配迭代路径经常 - 在大多数情况下，迭代只会改变一次（从未来到实际的迭代）。

当一个故事进入当前的迭代时，我们选择一个实施团队（例如，一个所有者接受交付，一个开发人员和一个测试人员来实现这项工作），那些人为任何需要完成的工作添加任务讲述故事。在迭代期间出现的任何错误/问题也是故事或任务的主要内容。

我们发现TFS工具非常差（笨拙，缓慢，微观管理），因此我们现在使用自制的仪表板向我们展示故事列表，因此在我们的Scrum中我们可以逐步浏览故事并查看每个人的任务/错误/问题，正在处理它们的人，以及自上次scrum以来他们在任务上报告的工作量。这为我们讨论这个故事提供了一个非常明确的基础。

我们在完成任务/错误/问题时将其关闭，但故事一直持续到迭代结束（这样可以附加和处理发现的任何新错误）。然后我们使用自定义工具来解决＆＃34; Resolve＆＃34;故事，关闭所有子工作项，然后检查父功能或史诗现在是否已完成，并且还可以标记＆＃34;已解决＆＃34;。这也可以通过手动过程在库存TFS中完成，但它相当费力，自动化它的代码只需要一两个小时的工作。我真的不明白为什么TFS让你在手动更新所有数据库表时很容易实现自动化。 （以类似的方式，TFS看板是不必要的时间来管理，因为项目只有完美形成才出现在它上面 - 得到任何估计，剩余，完成，区域，迭代，分配，父链接等错误它消失了！所以我写了一个简单的创建任务工具，询问估计，受让人和头衔，并填写其余内容 - 这花了我几个小时来实现和消除了所有耗时的错误和使用TFS＆＃39; raw＆＃39;

的麻烦

在处理任务时，TFS提供“活动”。状态（计划，开发，测试，文档等） - 这意味着每个单独的任务将通过一系列不同的人线性传递实施......但我们认为这是一个糟糕的方法，因为我们想鼓励团队在一个故事上工作，并行工作，而不是＆＃34;把他们的任务扔到下一个人身上＃34;。因此，团队中的每个人都在故事下创建一个或多个任务，这些任务代表他们必须亲自完成的工作包（编程，测试，记录）以及每个任务只有一个所有者。 （这在我们的scrum仪表板中运行良好，因为它显示了故事及其子任务/错误/问题的列表，因此可以一目了然地看到故事的整个工作环境）。单独的任务允许程序员和测试人员在紧密，迭代，协作的敏捷循环中协同工作，通常逐步推出部分功能以进行测试，而不是程序员在完成整篇文章之前完成所有工作以瀑布式的方式到测试仪上。在迭代结束时，故事团队将他们的故事演示给更广泛的开发团队，他们都同样负责确保所需的一切都得到满足。在演示之后，产品负责人/冠军然后接受完成的工作（或拒绝它）。这极大地减少了在裂缝和＃34;之间掉落的工作量。人们认为别人会这样做，帮助我们在最后获得可靠的交付。自从我们采用这种方法以来，我们发现团队内部的沟通和故事传递得到了显着改善。

我应该提一下，为了获得良好的估算和预算，我们会尝试将每项任务保持不到5天的工作时间，并且为了避免微观管理，我们会尽量避免在约2天内将任务拆分成任何东西（尽管显然有些任务必然更短。）

正如我所提到的，我们将错误/问题记录为他们影响的任务或故事的子项（如果它们影响多个故事，也可以添加相关链接）。在迭代结束时以及向团队其他成员演示新功能时，发布版本将作为整体进行回归测试。发现的任何错误都在发布分支中修复，并且（希望）在一两天内我们有稳定的客户发布。我们的目标是从每次迭代中获得客户可释放质量的产品，并将每个开发人员的突出错误数量保持在5以下（通常为1-3）。在引入这个系统之前，我们每个开发人员平均有20个错误，这是一个令人不快的技术债务。 （注意：我们在每次迭代中都会预留一些时间来修复这些错误，但是当错误太多而无法解决时，我们通常会将它们转换为新故事，以便可以对它们进行估计并安排在未来的迭代中，就像其他工作，因此永远不允许建立错误列表和技术债务，并且在可能的情况下，不允许修复错误会破坏我们的迭代计划。

我们不会将正在进行的工作（迭代中的项目）作为产品Backlog处理 - 产品待办事项是我们计划在将来执行的工作，当它进入迭代时，它会积极地工作并且不再在＆＃34;做＆＃34; list（它是迭代积压，而不是产品积压）。当所有工作（任务/错误）完成后，父故事就可以被解决（＆＃39;我们认为它已经完成了＃34;＆＃39;）然后关闭（＆＃39;产品负责人接受它作为＆＃34;完成＆＃34;＆＃39;）因此，一个简单的查询（在Project \ Current下关闭）将告诉您这次迭代的内容。

最后，当我们关闭迭代时，整个迭代进入Project \ Completed，这样您就可以轻松查询所有已完成的工作（在Project \ Completed下），并仍然在各自的迭代中进行分组。所以，如果你想知道什么＆＃34; Build 107＆＃34;补充一下，您可以在迭代路径Project \ Completed \ 107下对所有已关闭的故事进行查询。我们将不完整/被遗弃的工作标记为已移除，因此对我们来说，已关闭意味着＆＃34;完成＆＃34;。如果工作没有在一次迭代中完成并且在下一次迭代中继续，那么我们只需将故事移动到下一次迭代，然后完成的工作将显示在＆＃34; Build 108＆＃34;相反 - 所以这完美地跟踪迭代实现的交付。

为了保持一致，只有少数团队成员可以更改不同类型的项目。所以我们的计划项目＆＃34; （Epics，Features，Stories）仅由项目经理或产品所有者更改。任务都是拥有的，因此由正在开展工作的开发人员创建/更改/关闭。 PM跟踪故事的进度并开发跟踪任务的进度。

Answer 2

  

1）产品积压 - 在'配置计划和迭代'下   设置当前“积压迭代”的概念是什么？我们的   团队使用短期2周的迭代与内部版本号，但设置   构建迭代，因为当前的积压使得所有新的PBI都限定为   只有那个迭代。在该迭代中未完成的任何项目都会   一旦我将当前构建设置为下一个迭代编号，就会消失。   另一方面，如果我将它设置为父根节点，我可以看到   PBI列表随着时间的推移变得相当大。什么是最好的方法   用于管理未分配且工作简单的PBI   Parent-＆gt; build1 / build2等结构？

TFS有两个不同的积压。您团队的产品Backlog以及团队的Sprint积压。在迭代配置屏幕中，您可以定义哪个迭代包含您的团队产品积压（通过设置Backlog迭代）以及下面哪些迭代将代表您的冲刺。

如果你有一个庞大的PBI列表，你可以将它们放在当前积压迭代之上的迭代中，这将有效地将它们隐藏在积压页面中。或者您可以将它们放在一个单独的迭代中，这是您的Backlog迭代的一个步骤。

  

2）功能 - 所以我创建了一个功能，也许它涵盖了许多工作项   和几个任务。他们随着时间的推移完成，但我注意到了   父项目没有“自动”完成或状态更新。所以   谁/何时是特色项应该标记为完成？如果   产品所有者应该使用功能列表来获得概述   工作，他们不知道所有的依赖项目是否已经存在   完成以及何时标记要素完成。

没有自动完成或自动关闭。通常情况下，产品负责人（scrum角色）会密切关注他所要求的内容，并且知道某个功能何时即将完成。

您还可以通过选择“待处理日志项目的功能”视图，在“产品待办事项”视图中查看产品待办事项项目的层次结构。这也将列出基础故事的状态：

  

3）工作项目 - 管理这些项目，特别是他们的“州”或   身份似乎是一种皇室般的痛苦。在任务板上你无法改变   他们的状态，只有他们拖拉的任务，这很好。但是你   完成所有任务，父工作项保持状态   '新'。你真的必须微观管理每个工作项目，打开它，   并将状态设置为完成？

通常情况下，产品所有者/项目经理会批准提货故事并将其从新批准转移到批准。然后在Sprint计划会议期间（或在sprint开始时），团队选择他们将处理哪些项目，并将这些项目从Approved转移到Committed。

然后在sprint结束时（或者当故事下的所有任务完成时），开发团队向产品所有者显示已完成的工作，然后将故事移至完成状态。

  

4）质量保证/测试 - 对于每个工作项目，每个团队成员都有责任   用于测试每个项目，因此每个项目都由多人测试，并且   记录发现的任何问题。什么是使用工作项目的最佳方式   这个任务？

取决于团队的成熟度。并取决于您采用测试经理（测试用例工作项）。如果您的团队非常成熟并且正在使用测试管理器将测试用例链接到您的故事，那么您可以在Web Access中查看测试的状态。如果团队始终以ATDD工作方式工作，那么他们将完成测试成功所需的工作，然后再进行下一项工作。在这样的工作流程中，并不需要创建“设计 - 构建 - 测试”工作项。该工作项可能类似于“使测试X通过”，并将包括创建测试，构建代码和使测试通过的所有工作。

  

5）构建完成 - 迭代中的每个工作项都被标记   完成然后我认为他们从产品积压中删除正确吗？   这个例外似乎是它们所依赖的特征，   功能项目本身仍然开放。利益相关者如何查看列表   在当前版本中完成的功能？

再次使用Feature to Product Backlog Item视图查看哪些功能已完成所有工作。利益相关者在心理上验证这确实是他们想要的，并且他们没有额外的请求，工作和真正完成该功能所需的反馈。如果是这种情况，他们将通过将其移至完成来关闭该功能。