So you want to build a software team? Part 6: Task Ticketing

Trac's ticketing system is extremely basic, but it's easy to use and covers the basics well. It performs the key tasks of a ticketing system which are:

- Recording the work that needs to be done
- Prioritising these tasks
- Allocating tasks to specific components
- Assigning work to individuals

From this, you can:

- See how much work is being done in each section of a project
- List bugs, and refer directly to code and revisions where errors and their fixes can be found
- Provide each developer in a project with a personal, prioritised task list

One key aspect that the trac ticketing system lacks is time allocation to each task, but we'll cover why that might be particularly useful in a later post.

Trac tickets are are classified (by default) as defects, enhancements or tasks. Planned work is a task, feature requests are enhancements, and bugs are defects. Therefore, when you're starting a project, you need to identify and assign the tasks that need to be done.

I'm not going to go into massive detail now as project planning and scheduling is a huge topic which we'll continue to cover in upcoming posts. However, some guidelines:

Tasks should:

- consist of the work that can be done by one individual
- not consist of more work than can be done in 2-3 days
- be clearly defined

However in the initial case (particularly as you get used to using ticket systems) you may want to intially define larger pieces of work, which you can then split up to meet the above conditions.

The ticket system uses the same syntax as the trac wiki, so you can refer to revisions, source code, or ticket numbers using short syntax (eg, r123, source:/some/file or #13 respectively). This can be particularly useful in referring to related tickets (eg ones split down from a larger tasks as above, or a revision in which a task is completed or a fix applied).

By default, Trac has very generic names for its components, milestones and revisions. These can be customised in the command-line trac-admin tool which you used to initialise trac in the first place.

A milestone (and associated target date) serves to indicate the order in which tickets need to be completed. They may therefore be planned release numbers or, if you follow an agile methodology (again, more later), the sprint (or week) number in which the work should be done. Trac's "roadmap" view gives you a summary for work completed for each milestone, giving you a basic (but useful) display of project progress.

Priority does not determine order; it determines importance. It's down to the project manager to decide how importance relates to urgency (as any project manager will wryly reflect) and so assign tasks.

The task allocation process therefore tends to be:

- An admin sets up components, milestones and version according to project requirements
- Tasks, bugs or feature requests are added to the system, possibly from a range of source; usually a milestone or assignee will not be added at this point
- The project manager, probably in conjunction with the team, assigns the task to a milestone and possibly a developer. For each milestone project team can either build per-developer queues, or keep tasks in a common stack to be drawn off as developers become available.
- Developers then draw off tasks as they become available, mark them as accepted, and then as complete.
- If further detail or information is required, it can be added as a comment or attachement to the ticket.
- The project manager can then keep track of progress in the 'roadmap' view.

This is a relatively simple project management process, but it's effective. As such, I recommend it as a good first step for any project manager or team looking to improve the organisation of their work.
Posted by parsingphase, 2008-10-12 22:26

Anonymous user



Contact Richard