32

我们使用Trac作为我们的错误跟踪/开发/wiki 系统，我想知道是否有人有经验并使用了一些 Trac Agile/Scrum 插件或功能？你有什么推荐的吗？

或者将 Trac 票证复制为死树用户故事索引卡和手绘燃尽图会更好吗？

请注意，我在这里发现了一个类似的问题。尽管它专门针对 Scrum。他们推荐Agilo。有人试过Agilo吗？

4

10 回答 10

23

对于一个并置的团队，我总是在索引卡上复制用户故事。卡片墙比任何软件工具都更具协作性和易用性。而最重要的是，它在你的脸上。

燃烧图表也是如此。以我的经验，软件图表会被少数人在线查看，通常是一种拉动媒介。一张大的手绘海报（定期更换）会引起每个人的注意，并作为临时讨论的孵化器。

能够在您的每日 Scrum 会议中指出它们也是非常有价值的。

于 2008-10-31T23:12:10.727 回答
18

这就是我们将 Trac 用于像 sprint 一样的 scrum 的方式：

  • 我们使用 Trac 中的里程碑来识别 sprint。
  • 有一个默认的 Backlog 里程碑，我们收集所有新票证。
  • 在每个 sprint 之前，我们将积压的工单移至当前版本。
  • 在里程碑页面上，我们可以使用 wiki 语法添加有关 sprint 的回顾和其他信息。

所以现在只是默认的 Trac 功能，没有任何插件来保持它的轻量级。随着我们变得更好，我们可能会添加诸如燃尽图之类的功能，或者可能会切换到另一个工具，但我们希望首先让流程到位。

于 2009-02-17T20:16:17.783 回答
5

回答晚了，但这更多的是分享我迄今为止与 Trac+Agilo 的经验。

为了快速回答您的问题，Agilo 可能是使用 Trac 进行敏捷开发的最佳选择。

现在来安装和使用安装非常容易。我们使用了他们的最新版本 0.7.3.3。它可以完美地安装在 Trac 0.11 和 Python 2.5 上。不要忘记安装 libjpeg 和 python 映像库。需要注意的是，我们使用了 virtualenv，它使事情变得更容易。

进一步的使用非常简单。对于 wiki，我更喜欢 Trac 的旧式简洁外观，而不是 Agilo 的自定义。除此之外，所有事情都可以正常工作。

在他们的邮件列表中，我注意到他们计划在未来提供多项目支持。总之，我推荐用于 Trac 的 Agilo 插件。

于 2009-05-01T09:20:11.047 回答
3

是的，我在 Trac 安装中安装了 Agilo。

看起来很酷，包括漂亮的燃尽图。

不幸的是，在我能够真正使用它之前，我离开了我安装它的公司。

安装很痛苦（Ubuntu Ibex）——我在Agilo Google Group上记录了精确的步骤。

问题（一如既往）是集成到 PM 和 CEO 喜欢看到的事物的业务端（例如，估计时间与实际时间）。有（如前所述）其他产品可以解决这个问题（我相信 FogBugz 会解决这个问题），但我（和团队）喜欢 Trac，所以我们解决了这个问题。

哦，还有一件事；看起来它引入了相当多的开销（即，您必须在 trac 上花费更多时间才能充分利用它），但就像我说的那样，我没有机会真正在愤怒中使用它。

于 2009-02-17T02:09:12.890 回答
2

我们之前使用 Trac 和一个燃尽插件，然后去了 Redmine。我们发现 Redmine 对于存储库查看和问题界面来说很糟糕。我们实际上希望再次搬回 Trac。

于 2009-03-11T21:18:49.217 回答
1

Bitten是一个用于持续集成的 Trac 插件，可用于在签入时进行自动构建，它提供了敏捷过程的关键部分（快速反馈）。我个人没有使用过任何其他的 Trac 插件，所以我无法评论它们。但是，我怀疑里程碑的本地 Trac 功能可以很容易地被用作迭代标记（其中每个里程碑代表迭代的结束）。由于里程碑已经可以用于标记功能的“到期日期”，因此您不需要太多的修改方式来使用它们。

从那里开始，使用工单作为用户故事，并将它们与里程碑联系起来（我确信这可以在最坏的情况下手动完成）将为您提供一种跟踪速度并让团队了解进度（以及需要进行的更改）的基本方法也做了）。

于 2008-10-28T22:24:18.503 回答
1

我们将 Trac wiki 用于：

  • 每个功能的要求列表
  • 功能的技术规格列表（如果有）
  • 版本列表及其功能
  • 已部署的环境，带有指向所有实例的链接
    • 有一个用于发出 Web 请求的宏，因此我们可以列出每个 env 具有的版本等
    • （有一个 GraphViz 插件，对简单的绘图很有帮助）

每个“功能”的票务系统中还有一张票，用于保持总积压和当前/下一个冲刺的计划。

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

事情还有一个更具操作性的方面。我们在 Ops 的每个 sprint 中保留一个人，所以我们有一个人专门负责被团队以外的人打断。团队的其他成员可以专注于交付功能。

每个 bug/ops 任务都会得到一张票，但一旦我们开始处理它，它就会得到一张卡片并开始全面移动。这样它就可以获得可见性，我们不会忘记让测试人员等参与进来。

Scrum 是相当有触觉的，所以我认为把太多的东西放在物理工作环境之外不会很好。但最终你的团队需要找到一个有效的平衡点。

于 2009-02-16T00:03:57.397 回答
1

对于完全不同的事情，使用Trac进行敏捷开发的最佳方法可能是将所有内容迁移到Redmine。它支持 Trac 的核心功能以及一些附加功能，包括多个项目、甘特图、论坛、DCVS 等，尽管它看起来还没有完全实现。一些好事正在酝酿中。

Daniel Srb（在评论中）有一个他一直在研究的redmind 敏捷插件，看起来很有希望。您也许可以联系并查看他是否打算发布它（很久以前）。

过去我们已经成功地使用了两种产品，Trac用于门票，xplanner用于规划。

于 2009-02-17T21:19:55.183 回答
1

Agilo for Scrum 摇滚，最新版本使用客户端生成的图表，因此不再有依赖关系，安装更容易:-) Agile42刚刚发布了一个 Pro 版本，它通过漂亮直观的规划板丰富了 Agilo 体验，非常酷截屏:-)

于 2009-07-03T14:30:28.190 回答
0

我们最近开始使用 Scrumban。

基本上是看板，每天的站立会议涵盖经典的敏捷 Scrum 问题——你前一天做了什么？你今天打算做什么？你有任何阻滞剂吗？

我们围绕物理看板执行此操作，它非常适合可视化工作流程和团队协作，但我们还希望看板的数字形式能够仔细检查跟踪使用情况与物理板。

为了寻找可行的方法，我发现了这篇关于在 trac 中重新创建看板的数字版本的聪明帖子。

它非常直接和简单，我能够轻松地为我们的工作流程操纵这种方法，并且您可以根据您的敏捷 Scrum 迭代方法对其进行调整（或者如果您能够放弃时间盒方法，请尝试 Scrumban） .

于 2013-01-06T16:07:07.720 回答