问题标签 [sprint]

让我为你画出有问题的场景：

我正在使用 Trello 完成我的每周冲刺。我的董事会：

已是最新。唉! 这里出现了一个新的关键业务功能要求（例如跳舞的仓鼠动画）。我的冲刺只有 2 天！我该做这些选项中的哪一个！？

1. 放下我正在做的事情，将关键功能添加到 sprint 并立即开始工作
2. 放下我正在做的事情，通过将其他卡片（又名工作）移到下周的冲刺中来为新的关键功能腾出空间。开始研究关键功能。
3. 告诉产品负责人我的 sprint 已锁定，我会将其添加到下一个 sprint
4. 惊呼“嘿！我的 Scrum Master 在哪里，他应该保护我免受这一切的伤害！” （这是个笑话，我们是 3 个开发人员，没有 scrum master）。

目前我们实施选项 2。这样，sprint 仍然是一个可管理的工作单元，并具有定义的发布日期。冲刺完成后，我们（开发团队）将审查冲刺并与业务团队跟进，看看我们是否可以避免这种情况继续发展。

哪个选项“最好”或大多数人推荐？我知道这取决于您对敏捷、看板和 Scrum 的实施以及所有这些，但我正在寻找我们处理 sprint 修改的最佳方式。

请温柔一点，我们正在学习敏捷方法。请不要过于教条，因为这种方法被称为“敏捷”——不是每个人都必须以同样的方式去做。

非常感谢！

我的公司实施了一个新流程，让团队负责在 sprint 中定义完成。

在 Sprint Review 会议上，PO 第一次展示了工作，他们在团队面前处理了每个问题，然后对问题发表评论，例如“它是否按预期工作。如果没有，如何？缺陷创建.. 。”

读了很多关于 Scrum 的文章，这似乎不是“Scrum”要做的事情，实际上很多资源都明确表示，将评审会议作为验收会议是一件坏事，应该是关于反馈的。

问题是 PO 什么时候应该看到工作？我们什么时候接受/拒绝冲刺？

由于以下几个原因，我们目前没有在 sprint 中进行 PO 测试：

• 如果 PO 在 sprint 期间进行测试，那么确保问题被理解的所有权不在团队中，他们可以理解一半并实施一些东西，然后在向他们展示之后从 PO 那里得到解释。
• 团队也不需要测试他们自己的工作，因为他们有 PO 来抓东西。
• PO 在 sprint 期间有很多事情要做，例如 Backlog 梳理、会见客户，如果我们在 sprint 期间添加测试，那么可能有太多事情要做。

同样，这些都是我们所做的假设，因此对这些的任何想法都会非常有帮助。

所以基本上，在我的工作场所，我们将更改 Team Foundation Server 2015 中敏捷迭代/冲刺中的常规“状态”。我们将从“新、活动、已关闭”状态变为“新、编码、测试，UAT，完成”。将编辑任务的 WIT 以反映新的工作流程，并且将编辑流程配置文件以反映我们正在添加/编辑的新状态。我的问题是，我添加的新状态是否会自动出现在报告中？或者，是否需要执行其他步骤才能将新状态包含在报告中？

只是想从其他人那里得到一些输入，这些人也在他们的任务迭代中完成了自定义状态。

谢谢你。

对于我在 VSTS 中的项目，我设置了开始和结束日期的 SCRUM Sprint。我在每个用户故事下创建了用户故事和任务，并根据优先级安排了任务，还根据优先级安排了用户故事。

我想知道在 VSTS/VSO/TFS 中是否有一些方法或免费工具，我可以在其中连接到 VSTS/VSO/TFS 并导入 Sprint，我可以看到用户故事和任务以及任务启动和根据每个任务的初始估计小时数和 Sprint 的开始/结束日期自动结束日期。

它们是兼​​容的概念吗？如果有，有没有在 IT 行业使用的例子和案例？是否有任何工具支持和自动化这种过程。

我是 Scrum 新手，我正在尝试将其用于网站支持和维护。

对于网站的支持和维护，我们经常会收到一些小任务，比如：更换首页的banner、更改联系页面的电话号码、删除文章123上的图片xyz等等……我不知道如何处理这些小任务Scrum 中的任务。

目前，我在 backlog 中创建了一个任务，并为每个任务创建了一个 Sprint。然后，分别执行每个任务。我对吗？

在 Atlassian JIRA 中，“Fix Version”和“Release Version History”这两个字段有什么区别，什么时候应该使用什么？我似乎无法在网上找到这些字段的任何定义和推荐用法。

这种区别对我来说非常有用，尤其是对于跨越修复版本的 Epics。例如，如果我的 Epic 功能分阶段发布，例如 1.2.0、1.2.1、1.2.4 和 1.3.0，那么我应该：

1. 每次发布后将每个发布版本号添加到“修复版本”中，或添加到“发布版本历史记录”中，或两者兼而有之？
2. 如果我在 Epic 正在进行时仅添加“发布版本历史记录”，那么在关闭 Epic 时，我应该只使用最后一个发布版本号更新“修复版本”，还是使用所有以前的版本更新“修复版本”？

（旁注：我意识到也许我没有正确创建 Epic，理想情况下 Epic 应该在单个版本（版本）中推出？如果是这种情况，请纠正我。）

我的团队想要衡量积分承诺可靠性指标，这就像冲刺中交付的积分与计划交付的积分一样简单。

事实上，我们有两个查询分别显示它，我们想知道是否有可能在 Visual Studio Team Services 中对这些指标的比率进行百分比可视化？

在 VSTS 的“工作”下，我创建了一些测试冲刺。现在我想删除它们。如何删除 sprint？

因此，我正在尝试编写一个查询，该查询将向我显示已完成的错误、已完成的 PBI，这些错误是在同一个 sprint 中处理的。换句话说，我们引入了新功能的错误，但在完成迭代之前也关闭了。

问题是对迭代路径的硬引用。我想要的是像@ThisIteration 这样的变量，我会将它放在两个突出显示的位置。这样我就可以一直返回在迭代中解决的所有错误和 PBI。

我认为这在 TFS 查询中不存在，所以我正在寻找解决方法或聪明的解决方案，如 WIQL 等。

谢谢，德文