如何最好地使用Trac进行敏捷开发?

32
我们使用Trac作为我们的漏洞跟踪/开发/维基系统。我想知道是否有人有经验并使用了一些Trac敏捷/Scrum插件或功能?你能推荐什么吗?
还是将Trac工单复制为纸质用户故事索引卡和手绘燃尽图表更好?
请注意,我在这里找到了一个类似的问题here,虽然它是关于Scrum的。他们推荐使用Agilo。有人尝试过Agilo吗?

你是否已经和Trac结婚了?如果没有,那么对于采用敏捷开发的团队来说,有一些很棒的缺陷跟踪解决方案可供选择。 - jonnii
1
除非有一种很好的方法可以将我们所有的wiki页面和工单迁移到其他解决方案,否则我认为我们就是绑在一起了。你还考虑过哪些其他解决方案? - Epaga
10个回答

23

有一个共同的团队时,我总是会在索引卡上复制用户故事。一堵卡片墙比任何软件工具更具协作性和简单易用性。而且最重要的是,它就在你的面前

同样的道理也适用于燃尽图表。根据我的经验,软件图表只会被少数人在线查看,并且通常是通过拉动方式。一个大型的手绘海报(定期更换)会被每个人注意到,并作为特别讨论的孵化器。

在每日冲刺会议期间能够指向它们也非常有价值。


2
如果您通过离线邮件发送,您的回答可能更具有说服力。 - Avram
1
-1 for using 'incubator'..ugh - Damien Roche
1
小心风和掉落的卡片 :) - Christophe Roussy

18

这是我们如何使用Trac进行类似Scrum的冲刺:

  • 我们使用Trac中的里程碑来标识冲刺。
  • 有一个默认的Backlog里程碑,我们在其中收集所有新的问题。
  • 在每个冲刺之前,我们将问题从积压列表移动到当前版本发布中。
  • 在里程碑页面上,我们可以使用wiki语法添加关于冲刺的回顾和其他信息。

因此,现在只使用默认的Trac功能而没有任何插件来保持轻便。随着我们变得更加熟练,我们可能会添加像燃尽图这样的功能,或者可能切换到另一个工具,但我们首先要确立流程。


这个路线图在一两年后会变得难以管理吗? - lmat - Reinstate Monica

5
回答有些晚,但这更多地是分享我使用Trac+Agilo到目前为止的经验。
快速回答你的问题,也许Agilo是使用Trac进行敏捷开发的最佳选择。
现在来安装和使用,安装非常容易。我们使用了他们的最新版本0.7.3.3。它可以在Trac 0.11和Python 2.5上无缝安装。不要忘记安装libjpeg和Python图像库。需要注意的是,我们使用了virtualenv,这使得事情变得更加简单。
进一步的用法非常简单。对于维基百科,我更喜欢Trac的旧版清爽外观而不是Agilo的自定义外观。除此之外,所有的东西都可以正常工作。
在他们的邮件列表中,我注意到他们计划在未来提供多项目支持。总的来说,我推荐使用Trac的Agilo插件。

3

是的,我在我们的 Trac 安装上安装了 Agilo。

看起来非常不错,包括漂亮的燃尽图。

不幸的是,在我能够认真使用它之前,我已经离开了我安装它的公司。

安装很麻烦(Ubuntu Ibex) - 我在 Agilo Google Group 上记录了精确的步骤。

问题(像往常一样)是将其集成到项目管理人员和首席执行官喜欢看到的业务端中(例如预计与实际工时对比)。还有其他产品可以解决此问题(我认为 FogBugz 可以解决此问题),但是我和我的团队喜欢 Trac,所以我们绕过了这个问题。

哦,还有一件事;看起来它引入了相当多的额外开销(即你需要在 Trac 中花费更多时间才能最大程度地利用它),但是就像我所说,我没有机会真正愤怒地使用它。


新网址:http://www.agile42.com/agilo/ - Tr1stan

2

我们之前使用过带有燃尽图插件的Trac,然后转向了Redmine。我们发现Redmine在代码库查看和问题界面方面非常糟糕。我们实际上正在考虑再次回到Trac。


1

Agilo for Scrum非常棒,最新版本使用客户端生成的图表,因此不再有依赖性,安装更加容易 :-) agile42刚刚发布了一个专业版,通过一个漂亮而直观的Planning Board增强了Agilo的体验,非常酷的屏幕录像 :-)


1

Bitten是一个Trac插件,用于持续集成,可以在提交时进行自动构建,这提供了敏捷过程(快速反馈)的关键部分。我个人没有使用过其他Trac插件,所以无法对它们发表评论。然而,里程碑的本地Trac功能可以相当容易地利用,我猜想,可以将其用作迭代标记(其中每个里程碑表示迭代的结束)。由于里程碑已经可以用来标记功能的“截止日期”,因此您不需要太多修改就可以将其用作此类目的。

从那里开始,使用票证作为用户故事,并将它们与里程碑联系起来(最坏的情况下,我相信这可以手动完成),将为您提供一种基本的跟踪速度和让团队了解进展(以及需要进行的更改)的方法。


1
我们使用Trac wiki来:
  • 每个功能的需求列表
  • 每个功能的技术规格列表(如果有)
  • 发布版本和其功能列表
  • 已部署环境,包括所有实例的链接
    • 有一个用于进行Web请求的宏,因此我们可以列出每个环境具有哪个版本等信息
    • (有一个GraphViz插件非常有助于简单绘图)

对于每个“功能”,我们的票务系统中也有一个工单,用于保持总体积压和当前/下一个冲刺计划。

然后我们在冲刺计划期间为每个功能编写一堆卡片。

还有更多的运营方面。我们每个冲刺都会留一个人在运营上,这样我们就有一个专门负责被团队外部人员打断的人。其余团队成员可以专注于交付功能。

每个错误/运营任务都会获得一个工单,但是一旦我们开始处理它,它就会获得一个卡片并开始在看板上移动。这样它就能得到可见性,我们也不会忘记涉及测试人员等。

Scrum相当注重实践,所以我认为在物理工作环境之外放置过多的东西可能不会起到太好的效果。但归根结底,你的团队需要找到一个适合他们的平衡点。


1

对于完全不同的事情,使用Trac进行敏捷开发的最佳方法可能是将所有内容简单迁移到Redmine。它支持Trac的核心功能,并提供一些额外的功能,包括多个项目、甘特图、论坛、DCVS等,尽管看起来它还没有完全到位。有一些好东西正在路上。

Daniel Srb(在评论中)有一个redmind agile plugin,他一直在开发,看起来很有前途。您可以联系他并了解他是否计划发布它(已经很久了)。

我们过去曾成功地将两个产品结合使用,Trac 用于问题跟踪,xplanner 用于计划。


0

我们最近开始使用Scrumban。

基本上是一个看板,每天的站立会议涵盖了经典的敏捷Scrum问题 - 你昨天做了什么?你今天计划做什么?你有任何障碍吗?

我们在物理看板周围进行这项工作,这对于可视化工作流程和团队协同非常有帮助,但我们还希望我们的看板以数字形式存在,以便能够双重检查trac使用情况与物理看板相比。

在寻找适合我们的东西时,我发现了这个聪明的在trac中重新创建看板的数字版本的帖子

它非常简单明了,我能够轻松地将这种方法用于我们的工作流程,并且您可能可以根据自己的敏捷Scrum迭代方法进行调整(或者如果您能够放弃时间限制的方法,请尝试Scrumban)。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接