Bugzilla在管理Scrum项目方面的效果如何?[关闭]

Bugzilla是一个很棒的bug跟踪系统。我们试图将其用于其他项目管理任务,但结果并不理想。我建议你找到一些设计时考虑到你的目标的东西。

你自己试试吧。

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

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

三年前,我在一个正在进行的项目中亲自使用了它。我没有项目经理,我是开发人员,所以我需要一个非常轻便的头顶系统。Bugzilla给了我这个。我把我的主要目标定为增强“生产化系统”,然后我建立了依赖关系来达到这一点。我最终有160个节点,它们彼此依赖。这基本上是一种工作分解结构。我没有费心进行时间估算,也没有费心创建任何其他类型的项目文档。

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

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

对我来说,这种方法的优点是,如果一个任务看起来很简单,并且有一个节点与之关联,但在做事情本身时,我意识到它更复杂,我会把它分成不同的子任务。这只花了一分钟的时间,而且绝对不涉及与项目经理的会面。

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

请注意,除非事先达成一致,否则我没有将bug分配给他们。

它运行得很好,系统提前一个月准备就绪。

它将如何与SCRUM配合使用?我只是粗略地看了一眼草图,不能告诉你。但那是我的经验。

使用专用主机将允许您做三件事:

• 支持
• 轻松升级(除非你内部有专家,否则bugzilla管理并不容易——至少对我来说是这样)
• 跨越组织边界的用户。

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

我的独立解决方案是DokuWiki+MantisBT+Subversion+Review Board,可以相对轻松地集成。托管替代方案是Bitbucket.org。其基本原理是你在维基上写用户故事,并可以参考他们的具体任务。更大的bug可以协同设计,Mantis在bug报告中提供了“wiki”链接。审查委员会允许您在提交更改之前对svn-diff进行同行代码审查。

我们已经在几个项目中非常成功地使用了Trac和Subversion。

这里的主要优势是能够定制报告,其中一些报告非常针对Scrum,为管理层提供信息。