10

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

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

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

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

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

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

任何想法将不胜感激。

4

3 回答 3

3

我之前在 Bugzilla 中做过类似的事情，我找到的解决方案不是实现分层的“故事错误”之类的；我们也决定这会引起混乱，而且对于我们想要的来说太复杂了。我之前使用的解决方案只是将用户故事编号放在错误描述中；您也可以在其中添加一个链接，以使其更容易取消引用。它有点拼凑，但效果很好。

于 2009-06-08T18:49:22.710 回答
2

我想说，如果您的用户故事需要多个错误案例 - 它们太大了。通过对所需功能的良好抽象，您可以将用户故事拆分为更小的用户故事，每个故事只需要一个案例，然后按此方式计划和进行。

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

于 2009-06-08T18:59:26.373 回答
2

无论是否将 Bugzilla 中的依赖链接用于故事跟踪，我都强烈建议在您的故事中使用关键字。我们使用“故事”。使用关键字可以灵活地轻松跟踪产品树中的故事与错误。我还建议在 Bugzilla 安装中使用时间跟踪；即使时间仅在故事上进行跟踪。

于 2011-02-26T04:29:27.330 回答