By now I’ve been using Trac more than two years for managing various projects – from very small ones with just a few people involved (combining in themselves developers, testers and product owners) to large ones with more than 20 people (both in private projects and in Nokia – yes, yes, some Nokia projects are also using Trac).
In agile projects, especially in large organizations, one needs to find the right balance between “post-it management” bordering with chaos and monstrous tools and processes for requirements and defect management and project documentation and reporting. Choosing the right tool can have a significant impact on team performance.
There are multiple commercial tools available for project tracking in agile environment, but I still choose Trac in most of the cases for its openness, simplicity and customizability. Below I explain the reasons for this choice and highlight limitations we faced in large scale projects.
Quite often, especially in large organisations, document processes are disconnected from development. Developers don’t like to write documentation because of the heavy review and approval process, and latest versions of official documents are stored somewhere, where developers don’t usually check.
We use Trac integrated wiki for documenting virtually all aspects of the project – from the team roaster and tips and tricks on development environment setup to release notes and architecture documents. Wiki allows to keep all documentation visible, easily accessible, and easily modifiable – which removes the barriers to sharing the information.
Trac has an extremely flexible ticket system, that allows to manage requirements, defects and you-name-it.
Everything in Trac is a ticket. Tickets can have different types. When setting up a new project, I typically define “stories”, “tasks” and “defects” as ticket types.
- “story” – is a high level requirement, describing functionality on a general level, like “implement Facebook application”; stories can have complexity estimates in story points (a custom field can be created for that)
- “task” – when stories are analysed in detail, they are split into “tasks”, which are smaller pieces of work, usually doable in a few days.
- “defect” – well, you all know these ones – this is what software developers create for a living 😉
Usually during life cycle of a project there arises a need for additional ticket types. For example, in one of the projects, we defined a ticket type “customer care”, which extended Trac to be a care tool as well. When a need to manage change requests came up, we created a new ticket type “Change Request”.
It is also possible to define custom work flows for the tickets, if the default ones are not completely satisfying present project needs.
Trac is not Bugzilla, but it doesn’t have to be. For most projects using Bugzilla is a total overkill. In Trac it is possible to define custom priorities and severities for “defect” tickets and easily link defects to each other and to change sets in version control, using wiki syntax in the description or comment fields.
Complete integration of all/most aspects of the project life is one of the strongest points for choosing Trac. Documentation, requirements, defects, releases, sprints, version control are all seamlessly integrated in one very lightweight tool. It is a dream of every technical lead come true – full traceability from requirements to code changes.
Naturally, as a web-based tool, Trac allows all tickets (defects, requirements, user-stories, etc.) and documentation to be easily linked to each other. Wiki syntax is allowed everywhere, so you can put “duplicate of #1432″ in defect resolution comment or “see a conflicting requirement #312 from Petri” in user-story discussion.
Trac in-built integration with Subversion (Git can be connected via plug-in) is also a really cool feature – referring to source code from wiki pages or tickets is as simple as placing  in the mark-up.
Sprint and Release planning
By default Trac defines Milestones and Versions. A simple, yet powerful system. There’s no hard linking between Milestones and Versions, so one needs to be careful how to name milestones, or use sequential numeration.
I usually use Milestones for tracking sprints and Versions for tracking releases, so that each story/task/defect/change request can be placed within a certain timeframe. In the beginning of the project I create “release 1″ and “future releases”, and define “Sprint 1″ and “product backlog” for milestones. As project progresses, new “Sprint N” milestones are created, and stories and tasks are moved from “product backlog” to “Sprint N” in sprint planning meetings.
In big projects, where backlog consists of hundreds of stories, it helps to define a custom numerical priority field, that can used for sorting stories in the backlog (just critical/major/minor is not always enough – there are always more critical and less critical stories).
Reporting capabilities in Trac might seem to be limited, if you take a look at the default reports, but with little SQL magic it is possible to extract all data that is required. It is possible to use colour coding and custom formatting in the reports.
Timeline. I probably should’ve started with it. This is the best feature in Trac. It displays an overview of everything that has been going on in the project in the chronological order. Tickets created/closed/re-opened, new commits/branches/merges in the version control, wiki pages edited or created. If you’ve been away from the project or just want to know what happened while you were so immersed in coding this last coolest feature – Timeline is the place to go.
Naturally, you can see the diffs for wiki pages/code change sets from the Timeline.
Source browser. Browsing source code is also quite nice – you can check or diff any file, in any branch or revision without having to check out – all is accessible via web interface.
Plug-ins make your life easier and richer
Trac is extensible, and has a large number of community contributed plug-ins and macros.
Plugins that are essential from my point of view are:
And nice to have ones:
One important thing with Trac – is that unlike many other similar tools, you can install it on your own server. If you start using a hosted solution a problem of ownership of data will eventually come up. Once you start hosting your data elsewhere, it is very difficult to switch to another solution.
Some things that can definitely be improved in future versions of Trac:
- better linking of the tickets – at the moment splitting requirements into stories and tasks requires either a special plug-in, or manual linking, which might be difficult to keep track of (it is possible to somewhat work around this with MasterTickets plugin)
- advanced search – searching only a subset of tickets would be great (e.g. only “closed”, or only “in progress”)
- batch editing (there is a plug-in for this, but I see it as essential functionality, that has to become a part of the core)
- better UI configuration – so that there’s no need to edit ini file manually (Ini admin plugin is definitely helping, but it is still not visual enough)
- better version control support: use of Subversion repositories located on different server than Trac itself and native support for Git
Trac proved to be a lightweight, but powerful tool for managing projects, especially ones using agile methodology. It sure has some things that can be improved, but it also has a very active development team, and an active and growing community, that keep working and contributing to this amazing product.
One important thing to remember when choosing a tool for your new project – it has to support your way of working, not dictate it.