敏捷：处理已实现功能的新用户故事和错误

Question

在最近的几次迭代中，我始终意识到，在客户开始使用APP之后，我们错过了某些实现功能的用户故事细节。

例如：

原来的要求是：“可以增加产品的迷你车（...增加产品的规则）”

原来的用户故事是：“可以增加产品的迷你车（...增加产品的加工）“

实际实现的功能是：”产品可以加入到微型车的需求，但它重置所有过滤条件和ref加入产品后页面“

客户希望它像：”产品可以添加到微型购物车作为要求。为了保持当前的过滤条件，刷新页面中添加产品后，”

这些要求被我们收集。 这些用户故事被我们的外包团队写道。

难道我认为这是一个错误或新的用户故事，或者我应该简单地重新打开老用户故事和编辑它占了新的要求？什么是“最佳实践”，什么是每种方法的利弊？

非常感谢！

从我的理解是，企业的要求总是很简单， 用户故事总是小而抽象。 有些时候，我们无法意识到上述问题，直到开发人员开始编码和开发人员告诉我们。 它是功能过程和技术问题，它应该在开发阶段提交给开发人员讨论。所以我认为这是错误。

Answer 1

用户故事故意保持简单和抽象。原因是它被认为是'邀请对话'。这意味着随着团队接近处理他们与产品负责人谈话的故事，开始充实故事的细节。这可能发生在积压优化中，或者可能作为冲刺计划会话的一部分发生。

这个想法是在恰当的时间在故事上获得恰到好处的细节。因此，当开发人员开始处理故事时，他们确信自己足够知道如何完成产品所有者请求的工作。

如果在用户故事中没有足够的细节，那么认为它不适合冲刺。这就是为什么开发团队和产品负责人如此密切合作，以及时获得细节的原因。

即使开发人员开始编写故事，他们仍然会与产品负责人进行交流。例如，他们可能会将产品添加到迷你手推车中，并将其展示给产品负责人并进行检查以确保其符合他们的要求。

这个过程对于Scrum来说至关重要。如果你发现故事需要重新工作，那么这是一个迹象表明这个过程无法正常工作。在你的回顾中谈论它，并试图找出如何最好地减少这个问题。

Answer 2

我看到这里我们所说的“现成的定义”一个故事一个问题，所以一个故事需要有才能的标准要考虑的规划和执行（例如INVEST：https://en.wikipedia.org/wiki/INVEST_(mnemonic)）。 我想对故事的一个适当的qa从未做过。在并置的团队中，这不是必需的，因为事实上故事的目的是建议与产品所有者进行对话，但对于离岸或外包开发，验证准备好故事的定义总是一个好习惯。

在你的具体情况下，假如你不在ISO认证的组织中，那么我不会那么在意方法论（错误或新故事），你需要做的事情就像你说的那样做:)但是更多关于什么是向客户提供承诺价值的最快方式。如果发现一个bug，修复它并部署修复程序，就是让客户满意的方法。后来把这个回溯过来并且找到根本原因并且修复那个。