此特定需求的用户故事或用户故事

Question

我必须为一个需求编写一个用户故事，其中包括将搜索过滤器传递到相同的URI并检索相应的结果。

我有5个过滤器。

我计划编写5个不同类型的故事:作为URI用户，我可以按#filter1 1进行搜索，这样就可以根据#filter1 1检索结果。

然后是第六篇故事，它涉及在一起搜索一个或多个或全部六个过滤器。

这是一条明智的路线吗？

Answer 1

如果您将其保存为一个用户故事，并且只在sprint结束时完成了4/5筛选，那么您的单个故事是不完整的。如果你把它分开，那么如果你完成了4/5过滤器，那么5层中就有4层可以标记为完成。

当我得到这样的故事，有类似性质的n个特性(比如你的5个过滤器，或者一些转换，或者一些数据处理器，.)我喜欢为每个特性将它们分成一个单独的故事，这样如果其中一个特性遇到意外的问题，我可以将其他的故事移到完成。我想，这更多是出于管理方面的原因，而不是技术上的原因，而且这样做的话，管理开销会更大一些，但它可以更容易地跟踪已经完成或没有完成的工作，以及每个故事的进展情况。

Answer 2

当我被灌输到UML (这是一种不同的方法，但我仍然喜欢这一课)时，用例的前提是：“有人来到系统，做一些有商业价值的事情，然后离开。”这在用例之间提供了一个很好的边界，因为它将工作划分为多个或多或少完整的过程流。

从A开始，做这个和这个，在B结束，如果你到不了B，抛出一个异常。从B到C，或者从A到X，是不同的流。

出于同样的原因，我喜欢敏捷故事的相同界限。因此，从上面的示例中，用户可能会来到系统，调用过滤器3，然后离开。他们可能永远不会调用过滤器2，这意味着两个不同的故事。