问题标签 [sprint]

Scrum 的挑战之一是如何将 QA 融入流程中。当然，在 Sprint 期间，QA 与开发人员一起处理每个单独的用户故事，但是在完全完成的 sprint 中让 QA 有时间在发布到生产环境之前进行完整的回归和负载测试呢？

我见过两种方法：

1. 在 Sprint 的最后一天投入生产；或者
2. Sprint 一周后投入生产

这两种方法都有它们的挑战，所以我想知道大多数商店在每个 Sprint 发布时都会做什么？

Sprint Backlog 中可以包含和跟踪哪些类型的任务作为工作项？

Sprint backlog 中是否可以包括分析、审查和单元测试（用户故事），或者只能包括和跟踪核心编码任务？

基本上，我将用户故事分解为技术任务以更新 Sprint backlog，并且想知道是否可以在 sprint backlog 中更新和跟踪具有非编码角色的任务。

我是一名产品负责人，我正在帮助设置一个主题冲刺。需要明确的是，我所说的主题是指所有用户故事都相关或围绕一个共同目标聚集。我还有其他故事在我想要包含的主题中效果不佳。问题是，当我将 sprint 的愿景分割开来时，我们的工作效果并不好。有什么建议么？

我们使用带有 TFS 的 Scrum 1.0 来管理我们的项目。有 2 个（即将成为 3 个）团队同时从事不同的Sprint 。这似乎会导致 TFS 出现问题，尽管 Sprint Burndown 图表变得倾斜且完全不正确。

我已经将两个团队移动到相同的迭代路径/Sprint 下，并且我们一直在按区域区分它们。但这并不理想。

我的问题实际上是关于其他团队如何使用 Scrum 1.0 来有效地同时运行多个 Sprint。我们真的很想至少有每个 Scrum 团队的 Sprint Burndown 和 Velocity 报告。

非常感谢，约翰

我知道最佳冲刺长度会因情况/公司而异。话虽这么说，有没有人成功使用灵活的冲刺长度？另外，我想知道是否有人对短（1 周）与长冲刺有强烈的看法？

背景：我们目前使用 1 周的冲刺进行开发。我们的产品负责人似乎对此很满意；但是，为了灵活起见，我曾多次要求增加某些项目的 sprint 长度。在所有情况下，我们都坚持短冲刺。

我们遵循敏捷开发方法。作为 SCRUM 大师，我正在维护 Sprint BackLog。我想知道在项目中间为特定任务增加工作量的最佳实践是什么。

例如，我正在做 ABC 任务，在 sprint 开始时，我估计需要 10 小时才能完成，但第二天我意识到它需要 20 小时，那么我将如何更新 Sprint Backlog。

迭代 2 的 scrum 计划是在迭代 1 的 sprint 审查（演示/回顾）之后还是之前？

我们已将 Team Foundation Server 2010 升级到 Team Foundation Server 2012，现在正在使用出色的 TFS2012 Web 访问来处理我们的产品待办事项、我们的 sprint 和我们的 Scrum 板。这一切都运作良好。除了这个：在我们的 TFS2012 网络访问中，我去工作，我看到了我的产品待办事项。但是，我只希望看到未分配给 Sprint（过去/当前或未来 sprint）的 PBI。但是我看到所有没有完成状态的 PBI。我希望 PBI 在移至 Sprint Backlog 时会从该 Product Backlog 中删除。对？

我想编辑工作项查询以进行更改，以便只有具有迭代路径的 PBI 不在 sprint 内。我可以这样做吗？

有一个按钮创建积压查询，当我单击该按钮时，将创建一个新查询。我可以编辑该查询 - 但它不用作积压/计划屏幕的查询。

我没有尝试查看此查询是否与新创建的 TFS2012 团队项目中的查询类似。它可能与 TFS2010 团队项目的升级有关。

提前致谢。

10 月 15 日编辑：

在创建这个问题时，我觉得 PBI 可以同时出现在 Sprint Backlog 和 Product Backlog 中是错误的。但是 - 在考虑如何完成计划时 - 这可能没问题。我应该将 Product Backlog 视为未完成的 PBI 的积压。PBI 可能会为 sprint（当前或未来，甚至是过去的 sprint）计划 - 但是它们还没有完成。

关于 Product Backlog 视图中的预测功能：这有一些问题。积压优先级比已经分配给 sprint 的 PBI 具有更高的优先级 - 这可以改进。我认为这个特性只能用于对未来的 sprint进行非常粗略的估计。如果您的 sprint 中有许多 PBI - 预测功能甚至可能会产生误导。这是我的意见。

这组问题试图引出关于如何使用 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 区域、优化定义和配置
• Team Foundation Server - 区域/迭代

我们计划申请区域的典型布局如下：

从概念上讲，我们对上述内容非常满意，因为它对我们的环境是合乎逻辑的。根据以上内容，我们将有以下团队：*“客户 A 团队”*“客户 B 团队”

问题 1)我们认为，由于我们的团队规模不大，并且为了使管理更易于管理，我们不想为每个产品定义团队，因为我们实际上每个客户都有团队，他们监督该客户的所有产品。这是一个错误，还是可以？

问题 2）假设上述团队配置正常，那么我们是否正确将上述每个区域“映射”到每个团队，即对于团队“客户 A 团队”，指定区域“客户 A”（以及所有子区域）为该团队拥有的区域。那么默认区域呢，将“客户端A”区域的根设置为团队默认区域可以吗？

至于迭代布局，我们计划类似的东西，像这样：

问题 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 积压等）的文件夹下都有预定义的查询，但似乎这些查询针对“Root Project\Release 1\Sprint 1”进行了硬编码——在给定针对迭代定义的日期的情况下，这些是否不应该自动发现当前的 sprint？如果不是，那么维护这些查询的最佳做法是什么？

您是否知道一些高质量的 TFS 2012 和 Scrum 2 特定培训/教程可能有助于解决这些问题，或者为成功的 Scrum 2 TFS 设置提供一些指导？

我们的团队将采用 Scrum 和敏捷技术。我们有一个产品，我们为多个客户开发。该客户向我们提供了必要的要求，因此采用敏捷技术一切都很好。

但是在某个时刻（例如在 sprint 期间），出现了新客户，他想要获得与我们现在的产品略有不同的产品演示。这可能是一些新功能或行为上的细微差别。例如，他想在一周内获得这个演示。展示我们的产品支持此功能非常重要（因为否则他将向我们的竞争对手发表讲话），因此我们必须在一周内开发此功能（可能是部分）。

我们必须如何用敏捷处理这种特性？将它们移至当前的 sprint 积压工作？或者将一个团队分成两个并创建另一个冲刺？或者可能有另一种方式？