我工作中的一些人聚集在一起组成了一个小组，其目标是分析实施敏捷软件开发/项目管理原则的好处。
作为开发人员，我看到了用户故事的巨大好处。我们正在寻找一个信息散热器，可用于监控当前版本的阶段和规划未来版本。我想在这个过程中使用用户故事。
目前，我们正在使用Bugzilla进行问题跟踪。大多数发布计划都是使用此系统中的错误完成的。 Bugzilla的使用可能不会改变。它以合理的成本（$ 0）提供我们所需的大部分内容。
一个问题是用户故事到错误的映射。发布管理目前使用错误号完成。问题是一个用户故事可能包含三个错误，反之亦然。
在针对单个用户素材报告多个错误的情况下，一个想法是拥有一个用户故事错误，用于讲述故事并设置构成该故事的子错误的依赖关系。我担心这可能会导致过于复杂，并在利益相关者，开发和QA之间造成混淆。此外，它会使Bugzilla混乱不堪。
有没有人走过这条路？如果是这样，你做了什么？我是否应该在Bugzilla中放弃用户故事的想法？有更简单的解决方案吗？
任何想法都会受到赞赏。
答案 0 :(得分：3)
我之前在Bugzilla做过类似的事情，我找到的解决方案不是实现分层的“故事错误”之类的东西;我们也决定这会造成混乱，而且对于我们想要的东西来说太复杂了。我之前使用过的解决方案只是将用户故事编号放在bug的描述中;你也可以在那里放一个链接，以便更容易解除引用。它有点拼凑，但效果很好。
答案 1 :(得分：2)
我想说，如果您的用户故事需要多个错误案例 - 它们太大了。通过对所需功能的良好抽象，您可以将用户故事分成较小的用户故事，每个故事只需要一个案例，然后按照这种方式进行规划和进行。
我们尝试使用@McWafflestix描述的方法，从案例链接到用户故事的官方（维基）文档，但经过一段时间我们发现，创建较小的用户故事更好 - 它还可以实现更好的应用程序设计，因为每个用户故事都尽可能抽象实现，从而提供更好的代码可测试性和可维护性。
答案 2 :(得分：2)
在Bugzilla中使用依赖关系链接是否用于故事跟踪，我强烈建议您在故事中使用关键字。我们使用'故事'。使用关键字可以灵活地跟踪故事与产品树中的错误。我还建议在Bugzilla安装中使用时间跟踪;即使时间只跟踪故事。