我应该如何在Bugzilla中实现用户故事？

Question

我的工作中有几个人聚集在一起形成一个团队，其目标是分析实施一些敏捷软件开发/项目管理原则的好处。

作为一名开发人员，我在用户故事中看到了很大的好处。我们正在寻找一种信息散热器，可用于监测当前版本的各个阶段并规划未来版本。我想为这个过程使用用户故事。

现在，我们使用Bugzilla进行问题跟踪。大多数发布计划是使用此系统中的错误完成的。 Bugzilla的使用可能不会改变。它以合适的成本（$ 0）提供我们所需的大部分。

一个问题是用户故事到错误的映射。发布管理目前使用bug数量完成。问题是一个用户故事可能包含三个错误，反之亦然。

在单个用户故事中存在多个报告错误的情况下，有一个想法是有一个用户故事错误，说明故事并设置构成故事的子错误的依赖关系。我担心这可能最终会变得太复杂，并在利益相关者，开发和QA之间造成混乱。另外，它会让Bugzilla变得相当混乱。

有没有人已经走过这条路？如果是这样，你做了什么？我应该推动放弃Bugzilla中的用户故事的想法吗？有一个更简单的解决方案吗？

任何想法将不胜感激。

Answer 1

我以前在Bugzilla做过类似的事情，我发现的解决方案并不是实现分层的“故事错误”等;我们也决定这会造成混乱，并且对于我们想要的而言太复杂了。我之前使用过的解决方案只是简单地将用户故事编号放入错误描述中;你也可以在那里抛出一个链接，以便更容易取消引用。这有点拼凑，但它工作得很好。

Answer 2

我会说，如果你的用户故事需要多个bug的话 - 它们太大了。通过对所需功能的良好抽象，您可以将用户故事分为较小的用户故事，每个故事只需要一个案例，然后按照这种方式进行规划和执行。

我们试图使用@McWafflestix描述的方法，将案例链接到用户故事的官方（wiki）文档，但经过一段时间我们发现，创建更小的用户故事更好 - 它也会导致一个更好的应用程序设计，因为每个用户故事都尽可能抽象地实现，从而提供更好的代码可测试性和可维护性。

Answer 3

无论是否使用Bugzilla中的依赖关系链接进行故事跟踪，我强烈建议在故事中使用关键字。我们使用'故事'。使用关键字可以灵活地轻松跟踪故事与产品树中的错误。我还建议在Bugzilla安装中使用时间跟踪;即使时间只在故事中被追踪。