我们有MS Sharepoint - 这对于管理任务列表并不是一件坏事。数据是公开的,人们会收到有关变更和分配的通知。
我认为Bugzilla可能更容易用于管理和报告。虽然有一些不错的开源Scrum管理工具,但我已经用尽了很多政治资本,并且不能要求比我们现在拥有的更多。金钱不是对象 - 显然 - 我的团队有太多的专业工具。
Bugzilla是否会成为一个更通用的项目管理工具 - 在bug修复用例之外?
我是否会感到非常失望,并希望我下载了其他内容并为更好的项目管理工具提出了自己的理由?
答案 0 :(得分:9)
Bugzilla是一个很棒的bug跟踪系统。我们已经尝试将它用于其他项目管理任务,结果不那么出色。我建议你找一些符合你目标的东西。
答案 1 :(得分:5)
亲自试试吧。
在wush.net获得一个15美元/月的帐户并自己使用一段时间(除了满意的客户之外没有任何业务关系)。
Bugzilla非常强大,并且有很多配置选项,这可能令人困惑。
三年前,我亲自在一个正在进行的项目中使用它。我没有项目经理,而且我是开发人员,所以我需要一个非常轻量级的系统。 Bugzilla给了我那个。我将我的主要目标作为增强的“生产化系统”,然后我依赖于达到这一点。我最终有160个节点都相互依赖。这基本上是一种工作分解结构。我没有时间估计,我没有打扰创建任何其他类型的项目文档。
一个很酷的优势是,正如我编写的那样,如果我注意到需要完成某些事情,我会将其弹出到bugzilla(一旦设置完20秒),将其作为依赖关系,并回到我的身边正在做。
每当我完成一项任务时,我会查看依赖关系图并查找最外层的叶子(阻止其他但未被阻止的错误),并对其进行处理。
这个方法对我来说的优势在于,如果一个任务看起来很简单,并且有一个节点与它相关联,但是在做这件事本身时我意识到它更复杂,我只是把它分成不同的子任务。这只用了一分钟,绝对不涉及与项目经理的会面。
团队中的其他人可以通过查看开放的错误,按日期排序的错误等来跟踪我的进度。他们看到了行动,他们让我一个人呆着。当我有外部依赖时,我会制作一个错误,详细说明工作,并通过电子邮件向该人发送链接。然后,他们可以通过查看依赖关系图来了解为什么需要这样做。
请注意,除非事先达成一致,否则我没有将错误分配给他们。
它运作良好,系统已提前一个月准备就绪。
如何使用SCRUM?我只是粗略地看了一眼scrum,我无法告诉你。但那是我的经历。
使用专用主机将允许您做三件事:
请注意,bugzilla具有各种安全功能,因此可以轻松地将用户锁定到他们需要查看的内容。
答案 2 :(得分:3)
我们在几个项目中非常成功地使用了Trac和Subversion。
这里的主要优点是能够定制报告,特别是Scrum,为管理层提供信息。
答案 3 :(得分:3)
我的独立解决方案是DokuWiki + MantisBT + Subversion + Review Board,可以相对轻松地集成。托管替代方案是Bitbucket.org。理由是您在Wiki上编写用户故事并可以引用它们的具体任务。可以协同设计更大的错误,Mantis在错误报告中提供“wiki”链接。审核委员会允许您在提交更改之前对svn diff执行对等代码审核。