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

在我的工作中，有几个人组成了一个小组，他们的目标是分析实施一些敏捷软件开发/项目管理原则的好处

作为一名开发人员，我看到了用户故事带来的巨大好处。我们希望整合一个信息辐射器，用于监控当前版本的各个阶段并规划未来的版本。我想在这个过程中使用用户故事

现在，我们正在使用Bugzilla进行问题跟踪。大多数发布计划都是使用这个系统中的bug来完成的。Bugzilla的使用可能不会改变。它以合适的成本（0美元）提供了我们所需要的大部分东西

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

在一个用户故事有多个报告的Bug的场景中，一个想法是有一个用户故事Bug来解释故事，并设置对组成该故事的子Bug的依赖关系。我担心这可能会变得太复杂，在利益相关者、开发和QA之间造成混乱。而且，它会让Bugzilla变得杂乱无章

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

---

任何想法都将不胜感激。

我以前在Bugzilla中也做过类似的事情，我发现的解决方案不是实现分层的“故事bug”之类的；我们也认为这会引起混乱，对于我们想要的东西来说太复杂了。我以前使用的解决方案只是在bug描述中添加用户故事编号；您也可以在其中添加一个链接，以便于取消引用。这有点修补，但效果相当不错。

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

---

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

无论Bugzilla中的依赖链接是否用于故事跟踪，我强烈建议在故事中使用关键字。我们用“故事”。使用关键字可以灵活地轻松跟踪产品树中的故事和bug。我还建议在Bugzilla安装中使用时间跟踪；即使时间只被记录在故事上。

我在某种程度上同意你的观点，但我认为将用户故事分解成更小的用户故事的问题仍然增加了bugzilla中“用户故事bug”所能增加的间接层次；它只是将间接寻址移到用户故事工具，而不是bugzilla。并不是说这样做是错误的；什么最有效，实际上取决于企业。但如果你想尽量减少复杂性和深度，要认识到这只会将复杂性转移到其他地方。就像我说的，如果这是贵公司认为有效的方法，那么这没什么错。是的，正如我所说的，另一种方法对我们不太有效，但对许多人来说仍然是一个很好的解决方案。谢谢你的建议。我看到的一个问题是在一个相反的场景中，一个bug需要多个故事。我们的客户是内部的。我们使用Bugzilla的一个原因是，它允许每个用户提交一个bug，而无需额外的许可成本。我们将得到一个用户提交的bug映射到多个用户故事的情况。我们可以创建多个故事bug并关闭原始问题，但这仍然增加了一层我试图避免的复杂性。