我将使用 TFS 2012，我很困惑如何为一项工作设置工作项，其中与完成工作所需的步骤有关。例如，如果工作首先需要从最终用户那里获得反馈，那么开发人员需要构建基类。基类工作完成后，另一个开发人员需要构建 UI 组件。UI 完成后，测试人员需要测试工作。这项工作需要多人，包括一名以上的开发人员。在前一步完成之前，每个步骤都无法开始。所有这些步骤应该是不同的工作项还是全部在一个工作项中？如果有多个工作项，当前一个工作项完成时，您如何让该工作项显示为可以为下一个人工作？如果只有一个工作项，那么您如何处理多个开发人员的步骤？这是一个例子。可能存在这样的情况，即我们有五个开发人员在开始自己的工作之前都相互依赖。
问问题
2203 次
2 回答
3
听起来您正试图将 TFS 融入正式的瀑布流程。就为您创建甘特图而言，它可能不太适合。在 TFS 中，您可以使用用户故事和任务的层次结构来完成您想要的一半。对于另一半，您可以在任务之间创建适当的链接类型。
但是，TFS 不会为您提供类似甘特图的视图，它不是这样设计的。如果您真的想以这种方式管理项目，我会考虑将 TFS 与 MS Project 和/或 Project Server 集成。
顺便说一句，我强烈考虑让这些人互相交谈，而不是依赖工具。
于 2013-09-26T17:33:28.970 回答
1
只要您执行敏捷流程，您就走在了正确的轨道上。冲刺应该基于 PBI 部署，而不是完成的任务。如果您发现自己在多个 sprint 中推动 PBI，您可能想要拆分您的 PBI。这样做比一直想知道你的团队是否完成任务要好，因为一组任务正在进入一个新的 sprint。在 sprint 结束时完成 PBI 应该是敏捷团队的关键目标。
分配完成 PBI 所需的所有任务。任务应该由团队共同创建。这将有助于决定如何分解任务。我会根据功能分组（UI、业务模型等）将提到的任务分解为独立的任务。这样做的艺术是不要过多地分解它们。团队将自行决定。（记住保持敏捷，让团队犯短期错误，如果它有助于长期：估计、范围、质量等。
为每个 PBI 分配具有唯一名称的 QA 任务。不要使用 QA 作为任务名称，在 Board 视图中确定优先级可能会变得很困难。如果你有一个测试团队，让他们在那里创建 QA 任务。敏捷就是敏捷（团队就是团队）。
我学到的另一个主要关键点是在 PBI 完全计划好之前不要继续执行任务，在任务完全计划好之前不要继续冲刺。这将有助于确保一旦您开始冲刺，您不会在冲刺中间为该冲刺做出决定。
我希望这能给你一些指示。
于 2013-09-26T20:45:24.637 回答