How best to do Agile Development with Trac? [closed]
Asked Answered
V

10

33

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?

Vonnie answered 28/10, 2008 at 15:30 Comment(2)
Are you married to Trac? If not there are some great bug tracking solutions out there for teams doing agile.Hairdo
Well, unless there's a great way to migrate all our wiki pages and tickets to those other solutions I think we're married. What other solutions are you thinking about?Vonnie
B
23

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.

Bestiary answered 31/10, 2008 at 23:12 Comment(3)
-1. your answer can be more persuader ,if you send him by offline mail.Redolent
-1 for using 'incubator'..ughMorphology
Beware the wind and falling cards :)Labefaction
A
18

This is how we use Trac for our scrum like sprints:

  • We use the milestones in Trac to identify sprints.
  • There is a default Backlog milestone where we gather all new tickets.
  • Before each sprint we move tickets from the backlog the current release.
  • On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.

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.

Auxiliaries answered 17/2, 2009 at 20:16 Comment(1)
Does the Roadmap get unweildy after a year or two of this?Cashier
M
5

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.

Monopode answered 1/5, 2009 at 9:20 Comment(0)
M
3

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.

Maldonado answered 17/2, 2009 at 2:9 Comment(1)
New URL: agile42.com/agiloDruid
H
2

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.

Hemophilia answered 11/3, 2009 at 21:18 Comment(0)
B
1

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).

Berget answered 28/10, 2008 at 22:24 Comment(0)
P
1

We use the Trac wiki for:

  • List of requirements for each feature
  • List of technical specs (if any) for the features
  • List of Releases and their features
  • Deployed environments, with links to all instances
    • There's a macro for making web requests, so we can list which version, etc. each env have
    • (there's a GraphViz plugin which is quite helpful for simple drawings)

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.

Posting answered 16/2, 2009 at 0:3 Comment(0)
A
1

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.

Assuage answered 17/2, 2009 at 21:19 Comment(0)
F
1

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 :-)

Flotow answered 3/7, 2009 at 14:30 Comment(0)
M
0

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).

Melancholy answered 6/1, 2013 at 16:7 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.