问Bugzilla在管理Scrum项目方面做得如何？

EN

Bugzilla是一个很棒的bug跟踪系统。我们已经尝试将其用于其他项目管理任务，但效果不是很好。我建议你找到一些考虑到你的目标的东西。

你自己试试吧。

在wush.net上获得每月15美元的账户，并自己使用一段时间(除了满意的客户之外，没有业务关系)。

Bugzilla功能强大，有很多配置选项，这可能会让人感到困惑。

三年前，我在一个项目中亲自使用了它。我没有项目经理，我是开发人员，所以我需要一个非常轻量级的系统。布格斯拉给我的。我把我的主要目标作为一个增强的“产品化系统”，然后我进行了依赖以达到这一点。我最终拥有160个节点，所有节点都相互依赖。这本质上是一个工作分解结构。我没有为时间估算而烦恼，也没有为创建任何其他类型的项目文档而烦恼。

一个很酷的优势是，当我编码时，如果我注意到需要做什么，我会把它弹出到bugzilla (一旦它设置好，需要20秒的过程)，将它绑定为依赖项，然后返回到我正在做的事情。

每当我完成一项任务时，我都会查看依赖关系图，找到最外面的叶子(阻止了其他人但本身没有被阻止的bug)，并对其进行处理。

这种方法对我的好处是，如果一个任务看起来很简单，并且有一个与之关联的节点，但当我做事情本身时，我意识到它更复杂，我只会将其拆分成不同的子任务。这只花了一分钟，绝对不涉及与项目经理的会议。

团队中的其他人可以通过查看打开的bug、按日期排序的关闭的bug等来跟踪我的进度。他们看到了行动，就离开了我。当我有外部依赖时，我会做一个bug，详细说明工作，并通过电子邮件发送给那个人一个链接。然后，他们可以通过查看依赖关系图来了解为什么需要这样做。

请注意，除非之前达成一致，否则我没有将bug分配给他们。

它工作得很好，系统提前一个月就准备好了。

它将如何与SCRUM一起工作？粗略地看了一眼scrum之后，我不能告诉你。但那是我的经验。

使用专用主机将允许您完成以下三件事：

• support
• easy升级(除非你有内部专家，否则bugzilla管理并不容易--至少对我来说是这样)跨组织边界的
• 用户。

请注意，bugzilla具有各种安全功能，因此很容易将用户锁定到他们需要查看的内容。

我的独立解决方案是DokuWiki + MantisBT + Subversion + Review Board，它可以相对容易地集成。托管的替代方案是Bitbucket.org。其基本原理是，您可以在Wiki上编写用户故事，并可以引用它们的特定任务。可以协作设计更大的bug，并在Mantis的bug报告中提供"wiki“链接。审查委员会允许您在提交更改之前针对svn diff进行同行代码审查。