如何处理用户故事接受标准的变化？ [关闭]答案

【问题标题】：How to handle a change in acceptance criteria for a user story? [closed]如何处理用户故事接受标准的变化？ [关闭]
【发布时间】：2014-07-22 07:25:36
【问题描述】：

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

例子：

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

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

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

编辑：

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

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

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

【问题讨论】：

【解决方案1】：

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

【讨论】：

感谢您的回复。我不确定这是否可以作为一个故事。我们所有的故事都有验收标准和可用于测试的步骤。如果您在 1.2 版的产品规范中有原始用户故事和新用户故事 - 测试原始用户故事的验收标准将始终失败，因为超时作为新用户故事的一部分增加了。

【解决方案2】：

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

1 分钟超时而不是 30 秒

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

但是：

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

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

【讨论】：

【解决方案3】：

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

我们最终得出以下原则/步骤：

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

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

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

【讨论】：

【解决方案4】：

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

作为一个我想更改脆弱的 thrunge 括号操作的超时值就这样

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

【讨论】：

感谢您的意见。恐怕您的解决方案在我们的场景中不起作用。超时值不是我们希望用户能够更改/修改的值。它是一个固定值，在 1.0 版之后我们发现它需要与实现的值不同。我自己添加了一个答案，其中包含我们现在用来涵盖这些更改的流程。

【解决方案5】：

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

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

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

【讨论】：