Posts for the month of February 2009

Patch for Trac 0.11.3 now available

Support for  Trac 0.11.3 is now available.

For  Trac 0.11.3 use,

svn co http://svn.agile-trac.org/BRANCH/TRUNK/source/agiletracplugin/0.11/patch-0.11.3/trac/ trac

Starting with SVN revision 247 it is now possible to install Agile-Trac onto an exisitng environment

svn update required

Previously it was not clear how best to install Agile-Trac onto an existing trac environment - with existing tickets. After sufficient experience of Agile-Trac in the real world a simple strategy has been adopted to handle this scenario and has allowed ticket:44 to be finally addressed.

There are two key areas that have caused difficulties. First Agile-Trac relies on the data stored in the ticket_completion table to calculate information relevant to ticket groups (like milestones and iterations), and second, the milestones themselves have an additional priority field in Agile-Trac which is used to help order milestones on the Roadmap view.

Starting with SVN revision 247 ticket completion fields and milestone priorities are lazily created so it is not required that they exist in the database. For milestones this has actually not been an issue for some time now, but for ticket completion fields it was unclear what an appropriate default set of values were.

The approach taken is this:

  • If a ticket does not yet have a status of closed then the initial size values are considered to be undefined.
  • If a ticket has been resolved to a status of closed then the size values for the ticket are considered to be 0.

The reason for considering closed tickets to have a sizing of 0 is actually quite simple. We use the sizing only to associate the progress of a ticket with a time duration - an iteration, and since these tickets were closed previously that association does not exist. Hence we treat as having a 0 size. This aligns well with the notion of a fixed ticket being simply available. The recommendation in fact is to rename the fixed resolution to available and make another resolution, for example split or invalid the default resolution.

Brief Server Downtime Today (Feb 15th 2009) during Lenny Upgrade

We experienced some brief downtime (approx. 25 minutes) today while the server was upgraded to a shiny new Lenny install.

User Stories and Use Cases? Sure, it even makes sense.

source:/BRANCH/TRUNK/artifacts/presentations/agile_2008_logo.png I'm not sure why but somewhere along the way User Stories were branded 'agile' and Use Cases largely relegated to a high ceremony tool for non-agile methodologies. I gave a talk about this at Agile 2008 that set out to challenge that view by suggesting that both User Stories and Use Cases could, and should, co-exist as complimentary techniques in effective agile methodologies.

The terms User Story and Use Case are two pretty broad terms, so the first thing the talk does is to clarify just what I mean by each. It would of course be possible to adopt one term over the other. For example, we could call a User Story a Use Case Brief (a la Cockburn), but I believe it is helpful to keep a separation between the two terms. Another aspect of the talk was the idea that User Stories can be used to provide a uniform method of capturing functional requirements, as well as system constraints.

Having introduced the terms, I outline how, and when, User Stories and Use Cases can be used in a typical agile methodology, and importantly how one relates to (and compliments) the other. For example, typically User Stories are the technique of choice when Release Planning and Use Cases help a lot with Iteration Planning.

As User Stories and Use Cases can exist at different levels, from business use down to component interaction, I show how a User Story can relate to more than one Use Case, and how a Use Case can be related to more than one User Story. Similarly I also look at how Use Cases can sometimes provide a 'glue' between User Stories.

If you are an experienced agile developer you may not get a lot from this presentation, but I would hope it does get you thinking.

Agile Development in Globally Distributed Team

source:/BRANCH/TRUNK/artifacts/presentations/agile_2008_logo.png One of the great uses for tools like trac, and obviously agile-trac, is development in a distributed environment. Much of the initial design of agile-trac grew from an agile project where the whole team was distributed with team members on different continents and hence also in different time-zones. During that project a lot was learned about how to work effectively in a distributed setting.

A key observation is that the solution to distributed development is not co-location. You can effectively develop within a distributed team, and with reasonable tool support this can be quite pain free. I link to a  presentation here that was first given at Agile 2008 in Toronto last year. It captures many of the lessons learned from several years of working in agile distributed teams. It turns out that going agile can really bring benefits in a distributed setting as it helps focus both the nature and the quality of communication.

Foundations of Agile Development

When I am introducing agile development within a company, or within a team, I find it useful to give a brief overview of what I actually mean by agile development.

The reasons for this are simple. Most people have heard of the term agile development but yet there appear to be many different perspectives on what is meant by that.

For example, many people are of the opinion that to be agile means practicing one of the many canned agile methodologies, like XP, FDD or Scrum. Others have a very practice oriented view of agile development. That is, they see agile development as nothing more than a collection of practices, like TDD, pair programming and so on.

As a result of that I typically introduce the idea of agile development with a quick presentation of what I feel are the  foundations of agile development. I also try to tie into that discussion some of the terms with which most developers are already familiar with, such as use cases.

Of course agile-trac has been designed to support the foundations of agile development outlined in this presentation. Some of the screenshots in the presentation are from a heavily hacked wiki site which used perl scripts to try to simulate some of the functionality that is supported first class in agile-trac.

This presentation is a good starting point for understanding agile-trac and how it should be used. It is not intended as a replacement for documentation, but should nevertheless provide some useful insights.

Version 0.1.5 now available

NEW RELEASE - 0.1.5

Notable in this release:

  • the addition of date-picker controls for iteration dates, complete stage dates and milestone due dates
  • support for  Trac 0.11.2

To upgrade your installation use:

sudo easy_install -U http://svn.agile-trac.org/BRANCH/TRUNK/source/agiletracplugin/0.11/

You must also use svn update on your patch using:

sudo svn update

from the trac folder in your Trac installation.