我们拥有MS Sharepoint-这对管理任务列表并不都是不好的。数据是公开可用的，人员会收到有关更改和分配的通知。

我认为Bugzilla可能更易于管理和报告。虽然有一些不错的开源Scrum管理工具，但我已经用掉了很多政治资金，不能要求比现在更多的东西。金钱不是目标-显然-这是我的团队拥有太多专门工具的想法。

Bugzilla是否可以作为更通用的项目管理工具(错误修复用例之外)使用？

我会不会很失望，希望我下载了其他内容并提出了一个更好的项目管理工具的依据？

解决方案

Bugzilla是一个很棒的bug跟踪系统。我们已尝试将其用于其他项目管理任务，结果却不那么出色。我建议我们找到一些符合我们目标的设计方案。

我们已经成功地将Trac和Subversion用于多个项目。

这里的主要优点是能够定制一些报告，这些报告非常特定于Scrum，以向管理人员提供信息。

自己尝试一下。

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

Bugzilla功能强大，并且具有许多配置选项，这可能会造成混淆。

三年前，我亲自在一个正在进行的项目中使用了它。我没有项目经理，而我是开发人员，所以我需要一个非常轻便的系统。 Bugzilla给了我。我将主要目标放在增强的"生产化系统"上，然后做出依赖来达到这一点。我最终拥有160个相互依赖的节点。这本质上是一个工作分解结构。我没有理会时间估计，也没有理会创建任何其他类型的项目文档。

一个很酷的优点是，按照我的编码，如果我发现需要做的事情，我将其弹出到bugzilla(设置完成后需要20秒的过程)，并将其作为依赖项进行绑定，然后返回到我正在做的事情。

每当我完成一项任务时，我都会查看依赖关系图并找到最外面的叶子(阻塞了其他对象但本身并未被阻塞的错误)，并对其进行了工作。

这种方法对我来说的好处是，如果一个任务看上去很简单并且有一个与之关联的节点，但是当我自己做某件事时，我意识到它比较复杂，我会将其分解为不同的子任务。这只花了一分钟，绝对没有与项目经理会面。

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

请注意，除非事先达成协议，否则我不会将错误分配给他们。

它运行得非常好，而且系统提前一个月就可以准备就绪。

SCRUM如何使用？我只是粗略地浏览了Scrum，我不能告诉你。但这是我的经验。

使用专用主机将为我们提供三件事：

• 支持
• 轻松升级(除非我们拥有内部专家，否则Bugzilla管理并不容易-至少对我而言)
• 跨组织边界的用户。

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

我的独立解决方案是DokuWiki + MantisBT + Subversion + Review Board，可以相对轻松地集成。托管替代项是Bitbucket.org。基本原理是我们在Wiki上编写用户故事，并可以引用他们的特定任务。可以协同设计较大的bug，Mantis在bug报告中提供了" wiki"链接。审核板使我们可以在提交更改之前针对svn diff进行对等代码审核。