我们使用 Trac 作为我们的错误跟踪/开发/wiki 系统，我想知道是否有人有经验并使用一些Trac Agile/Scrum 插件或功能？ 有什么可以推荐的吗？
或者将 Trac 票证复制为死树用户故事索引卡和手绘燃尽图会更好吗？
请注意，我在此处发现了类似的问题。 尽管它是专门针对 Scrum 的。 他们推荐Agilo。 有人尝试过Agilo吗？
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
发布评论
评论（10）
在同一个团队中，我总是会在索引卡上复制用户故事。 卡片墙比任何软件工具都更具协作性且易于使用。 最重要的是，就在你的脸上。
燃烧图也是如此。 根据我的经验，软件图表会在网上被少数人查看，通常是一种拉动媒介。 一张巨大的手绘海报（定期更换）会引起每个人的注意，并充当临时讨论的孵化器。
能够在每日 Scrum 会议中指出这些问题也是非常有价值的。
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
这就是我们使用 Trac 进行 scrum（如冲刺）的方式：
因此，目前仅使用默认的 Trac 功能，无需任何插件，以保持轻量级。 随着我们变得更好，我们可能会添加燃尽图等功能，或者可能切换到其他工具，但我们希望首先让流程到位。
This is how we use Trac for our scrum like sprints:
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
回答晚了，但这更多的是分享我迄今为止使用 Trac+Agilo 的经验。
为了快速回答您的问题，也许 Agilo 是使用 Trac 进行敏捷开发的最佳选择。
现在开始安装并且使用安装非常简单。 我们使用他们的最新版本 0.7.3.3。 它可以在 Trac 0.11 和 Python 2.5 上完美安装。 不要忘记安装 libjpeg 和 python 图像库。 值得注意的是，我们使用了 virtualenv，这让事情变得更容易。
进一步的使用非常简单。 对于 wiki，我更喜欢 Trac 的旧式干净外观，而不是 Agilo 的定制。 除此之外，一切都正常。
在他们的邮件列表中，我注意到他们计划在未来提供多项目支持。 总之，我推荐 Trac 的 Agilo 插件。
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
是的，我在 Trac 安装上安装了 Agilo。
看起来很酷，包括漂亮的燃尽图。
不幸的是，在我能够认真使用它之前，我就离开了安装它的公司。
安装很痛苦（Ubuntu Ibex） - 我在 Agilo Google 群组。
问题（一如既往）是整合到 PM 和 CEO 喜欢看到的业务端（例如估计时间与实际时间）。 有（正如已经提到的）其他产品可以解决这个问题（我相信 FogBugz 解决了这个问题），但我（和团队）喜欢 Trac，所以我们解决了这个问题。
哦，还有一件事； 看起来它引入了相当多的开销（即你必须在 trac 上花费更多时间才能充分利用它），但就像我说的，我没有机会在愤怒中真正使用它。
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
我们之前使用 Trac 和 Burndown 插件，然后使用 Redmine。 我们发现 Redmine 在存储库查看和问题界面方面表现不佳。 我们实际上希望再次搬回 Trac。
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten 是一个用于持续集成的 Trac 插件，可用于在签入时进行自动构建，它提供了敏捷过程的关键部分（快速反馈）。 我个人没有使用过 Trac 的任何其他插件，所以我无法对它们发表评论。 然而，我怀疑，里程碑的原生 Trac 功能可以相当容易地用作迭代标记（其中每个里程碑代表迭代的结束）。 由于里程碑已经可以用来标记功能的“截止日期”，因此您不需要进行太多修改就可以使用它们。
从那里开始，使用票证作为用户故事，并将它们与里程碑联系起来（我确信这在最坏的情况下可以手动完成）将为您提供一种跟踪速度并让团队了解进度（以及需要进行的更改）的基本方法。也制作了）。
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
我们将 Trac wiki 用于：
每个“功能”的票证系统中还有一张票证，用于保留总积压和计划的当前/下一个冲刺。
然后我们在冲刺计划期间为每个功能编写一堆卡片。
事情还有一个更具操作性的方面。 我们在每个 sprint 中保留一个人负责运维，因此我们有一个人专门负责被团队外的人打断。 团队的其他成员可以专注于交付功能。
每个 bug/ops 任务都会得到一张票，但一旦我们开始处理它，它就会得到一张卡片并开始全面移动。 这样它就可以获得可见性，并且我们不会忘记让测试人员参与进来，等等。Scrum
是非常有触觉的，所以我认为在物理工作环境之外放置太多东西不会有很好的效果。 但最终您的团队需要找到有效的平衡点。
We use the Trac wiki for:
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
对于完全不同的东西，使用 Trac 进行敏捷开发的最佳方法可能是 简单地将所有内容迁移到 Redmine。 它支持 Trac 的核心功能以及一些附加功能，包括多个项目、甘特图、论坛、DCVS 等，尽管它看起来像是 尚未完全实现。 一些好的事情正在酝酿之中。
Daniel Srb（在评论中）有一个 redmind 敏捷插件 他一直在开发，看起来很有前途。 您也许可以联系并查看他是否计划发布它（很久以前）。
过去，我们成功地使用了两种产品，Trac 获取门票，xplanner 用于规划。
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum 很强大，最新版本使用客户端生成的图表，因此不再有依赖关系，安装起来更容易:-) agile42刚刚发布了一个专业版本，通过良好且直观的规划板，非常酷的截屏视频:-)
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
我们最近开始使用 Scrumban。
基本上是一个看板，每天的站立会议涵盖经典的敏捷 Scrum 问题 - 你前一天做了什么？ 你今天打算做什么？ 你有拦截器吗？
我们围绕物理看板进行此操作，这对于可视化工作流程和团队协同作用非常有用，但我们也希望看板的数字形式能够与物理看板进行双重检查跟踪使用情况。
在寻找可行的东西时，我发现了这篇关于重新创建数字版本的聪明的帖子trac 中的看板。
它非常直接和简单，我能够轻松地在我们的工作流程中操纵这种方法，并且您可能可以根据您的敏捷 Scrum 迭代方法对其进行定制（或者如果您能够放弃时间限制方法，请尝试 Scrumban） 。
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).