我工作的一些人聚集在一起组成了一个小组,其目标是分析实施敏捷软件开发/项目管理原则的好处.
作为一名开发人员,我看到了用户故事的巨大好处.我们正在寻找一个信息散热器,可用于监控当前版本的阶段和规划未来版本.我想在这个过程中使用用户故事.
现在,我们正在使用Bugzilla进行问题跟踪.大多数发布计划都是使用此系统中的错误完成的.Bugzilla的使用可能不会改变.它以合理的成本($ 0)提供我们所需的大部分内容.
一个问题是用户故事到错误的映射.发布管理目前使用错误号完成.问题是一个用户故事可能包含三个错误,反之亦然.
在针对单个用户故事报告多个错误的情况下,一个想法就是拥有一个用户故事错误,用于说明故事并设置构成该故事的子漏洞的依赖关系.我担心这可能会导致过于复杂,并在利益相关者,开发和QA之间造成混淆.此外,它会使Bugzilla混乱不堪.
有没有人走过这条路？如果是这样,你做了什么？我是否应该在Bugzilla中放弃用户故事的想法？有更简单的解决方案吗？
任何想法将不胜感激.