我们有 MS Sharepoint——这对于管理任务列表来说还不错。数据是公开的,人们会收到更改和分配的通知。
我认为 Bugzilla 对于管理和报告目的可能会更容易一些。虽然有一些不错的开源 Scrum 管理工具,但我已经用光了很多政治资本,不能要求比我们现在拥有的更多的东西了。金钱不是目标——显然——这是我的团队拥有太多专业工具的想法。
Bugzilla 是否会成为一个更通用的项目管理工具——在错误修复用例之外?
我会非常失望并希望我下载其他东西并为更好的项目管理工具辩护吗?
我们有 MS Sharepoint——这对于管理任务列表来说还不错。数据是公开的,人们会收到更改和分配的通知。
我认为 Bugzilla 对于管理和报告目的可能会更容易一些。虽然有一些不错的开源 Scrum 管理工具,但我已经用光了很多政治资本,不能要求比我们现在拥有的更多的东西了。金钱不是目标——显然——这是我的团队拥有太多专业工具的想法。
Bugzilla 是否会成为一个更通用的项目管理工具——在错误修复用例之外?
我会非常失望并希望我下载其他东西并为更好的项目管理工具辩护吗?
Bugzilla 是一个很棒的错误跟踪系统。我们曾尝试将其用于其他项目管理任务,但结果并不那么出色。我建议找到一些设计时考虑到你的目标的东西。
自己试试吧。
在 wush.net 上获得一个每月 15 美元的帐户并自己使用一段时间(除了满意的客户之外没有任何业务关系)。
Bugzilla 功能强大并且有很多配置选项,这可能会让人感到困惑。
三年前,我个人在我正在从事的一个项目中使用了它。我没有项目经理,我是开发人员,所以我需要一个开销很小的系统。Bugzilla 给了我这个。我将我的主要目标作为增强“生产化系统”,然后我建立了依赖关系以达到这一点。我最终有 160 个节点都相互依赖。这本质上是一个工作分解结构。我没有费心估算时间,也没有费心创建任何其他类型的项目文档。
一个很酷的优势是,当我编写代码时,如果我发现需要做某事,我只需将其放入 bugzilla(设置完成后需要 20 秒的进程),将其作为依赖项绑定,然后回到我正在做的事情。
每当我完成一项任务时,我都会查看依赖关系图并找到最外层的叶子(阻止其他人但自己没有被阻止的错误),然后处理它。
这种方法对我来说的好处是,如果一个任务看起来很简单并且有一个与之关联的节点,但是当我自己做这件事时,我意识到它更复杂,我会把它分成不同的子任务。这只花了一分钟,而且绝对不涉及与项目经理的会面。
团队中的其他人可以通过查看打开的错误、按日期排序的关闭的错误等来跟踪我的进度。他们看到了行动,他们让我一个人呆着。当我有外部依赖时,我会做一个错误,详细说明工作,并通过电子邮件向那个人发送一个链接。然后他们可以通过查看依赖关系图来了解为什么需要这样做。
请注意,除非事先达成一致,否则我不会将错误分配给他们。
它运行得非常好,系统提前一个月准备就绪。
它将如何与 SCRUM 一起工作?我只是粗略地看了一眼 scrum,我不能告诉你。但那是我的经验。
使用专用主机将为您带来三件事:
请注意,bugzilla 具有各种安全功能,因此很容易将用户锁定到他们需要查看的内容。
My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.
我们已经在几个项目中非常成功地使用了 Trac 和 Subversion。
这里的主要优势是能够定制报告,一些非常特定于 Scrum,以向管理层提供信息。