Dime Developement Methodology

Abstract

This document presents a set of rules that we strive to follow in the Dime effort. They are mostly adapted from the Extreme Programming methodology.

2002-02-11 zzorn First version
2002-02-12 zzorn Some clarifications, added a lot of questions.

We use some of the rules of Extreme Programming that are suitable for distributed Free Software/Open Source projects.

We use a common coding standard to make it easier for developers to understand each others code.
There is a template header file that also specifies the coding style in the forge/clients/dime/doc folder in cvs. TODO: Move to separate coding standard document.
We also document the code with JavaDoc (or Doxygen) syntax, and generate the API documentation for it automatically.

XP relies on an always present customer. In the case of OS/FS it seems that the developers are often their own customers.
We could see the project meetings as the 'customer', and prioritize and decide features in them.
We could alternatively / also appoint one or more persons to represent the customer?

Represent features desired by the customer. The feature is described with just a few lines of text to make it possible to create a rough time estimate and priority for it.
Each story has an estimate of needed developement time, estimated by the developers. [in what units?]
Each story also has a priority assigned by the customer.
It seems that this might not be the easiest way to handle things in a distributed project. Perhaps just feature listings with priorities and possibly effort estimates collected at planning meetings could work.
Do we need separatate large stories/features and detailed tasks? It cantake a lot of time to divide stuff into tasks (XP does this after using CRC cards to design it?)
Is there any anology for CRC based design in distributed projects? IRC brainstorming, with a secretary? Should we design each feature together, splitting it up approximately into classes?
Letting the developers pick features to implement is of course important. The developer that selects a task / feature should assign him/herself to it in RT (?) and provide a time / effort estimate for the task, and update the RT entry when the task is done.

Tasks are more well defined parts of stories, that equal around 1-3 days (?) of ideal developer time.
Tasks are kept in the WF request tracker database.

The project is divided into iterations. Each iteration shold be short (2-3 weeks).
A set of tasks to implement in an iteration are selected in the Iteration Planning meeting. The total effort of stories that can be implemented depends on how much we got implemented in the previous iteration.
An iteration should result in a new set of working features (Hmm.. or was that a release??)

A release is bigger than an iteration. It contains a subset of the total functionality.
The features to implement in a release are agreed on in a Release Planning Meeting. If necessary, new Release Planning Meetings are held to re-evaluate the list of features to be implemented for the release.

Calculating the project velocity makes it possibly to more reliably estimate how many and complicated features we can implement in an iteration or release.
We don't have deadlines in the sense of commercial projects. Does it still make sense to try to predict the progress?
Collecting the project metrics can be a time consuming task, that possibly doesn't directly help development. Thus it should be automated as much as possible (this automation should be abstracted and implemented forthe new website too). Working on the automation is a task related to website development.