jira - 如何处理用户故事接受标准的变化？

Question

我有兴趣了解人们如何在流程级别处理用户故事接受标准的变化。

例子：

您编写了一个用户故事，其中包含功能 XYZ 的接受标准。该用户故事在 1.0 版的冲刺中实现。一段时间后，对于 1.2 版本，产品负责人希望验收标准有所不同（例如 1 分钟超时而不是 30 秒）。

你如何处理这种变化？它如何改变原始用户故事的状态？我们正在使用 JIRA/JIRA Agile，如果您重新打开已关闭的用户故事并在新的 Sprint 中处理它们，我会特别感兴趣。

我们正在使用 Confluence 编写我们的产品规格，并且 PS 中的用户故事是通过查询直接从 JIRA 加载的。如果要更改原始用户故事的接受标准并重新打开它——如何确保 1.0 版的产品规范不会改变？

编辑：

我需要添加一些关于我们流程的更多信息：每个用户故事以及验收标准都有一些可用于测试这些标准的步骤。这些步骤用于生成验证/测试协议，用于检查所有产品规范是否已正确实施。

现在这意味着用户故事的更改将直接影响甚至已经审查和签署的产品规格和测试协议，因为数据是通过 jira 查询加载的。我想这可能不是将内容拉入 Confluence 的适当方式，更永久的东西似乎是可取的。

即使我们没有使用这些直接/动态查询，问题仍然有效：需求/验收标准的变化如何影响用户故事？

score 2 · Accepted Answer

我认为这是一个新的用户故事，例如“作为用户，我希望超时增加到 1 分钟，原因我自己最清楚”。

score 1 · Accepted Answer

因此，在产品发布后，产品负责人会回复您并说他们希望：

1 分钟超时而不是 30 秒

这可能被视为一个问题；这不是错误，因为超时功能可以正常工作，只是他们的时间段有问题。因此，您可以创建一个问题，将其与原始故事相关联，然后将其分解为任务以实施此更改。

然而：

如何确保 1.0 版的产品规格不会改变？

如果最初的产品规格说明超时时间为 30 秒，但您现在将其更改为一分钟，那么规格已更改的事实是无法回避的。创建问题并将其链接到原始故事将意味着您无需编辑原始故事。

score 1 · Accepted Answer

谢谢大家的回答。从那以后，我们找到了一种适合我们处理用户故事更改的方法。

我们最终得到的是以下原则/步骤：

这样，我们就有了包含未更改用户故事的 v1.0 产品规范和包含更新用户故事的 v2.0 产品规范。

重要的事实是，多年后，您可以选择任何版本的产品规范并根据验收标准对其进行测试，并且仍然获得通过。如果原始用户故事已被修改，则不会出现这种情况。

我希望我能够足够清楚地解释这一点。如果我需要详细说明解决方案的任何部分，请告诉我。

score 0 · Accepted Answer

我会说你的原始故事仍然很好。鉴于更改超时是有价值的，您显然需要更改原始故事的接受标准。在您的测试是自动化的情况下尤其如此。我会创造一个新的故事：

作为一个我想改变脆弱的thrunge括号操作的超时值所以

写下这个新故事将使人们的注意力非常集中在这种变化将带来的价值上。如果它没有增加价值，那就不要这样做。

score 0 · Accepted Answer

一旦完成，您就不能更改用户故事的接受标准（是的，请参阅完成的定义）。

如果产品所有者需要更改用户故事接受标准，他/她必须创建具有“接受标准”的新功能/用户故事。

如果更改发生在 sprint 中间，并且现有的验收标准对项目没有任何意义，请从 sprint backlog 中删除用户故事并将其添加到新的（不应在 sprint 中间接受更改）sprint带有新的/修改的验收标准。

5 回答 5