Thursday, 18 September 2008

Extreme Programming - Getting Started

Just a few words about the theory. There are a couple of concepts I want to introduce and a few Rights and Responsibilities I wish to present. I will try to keep the theory to a minimum in this blog, only explaining enough to keep non-experienced readers up to speed. I will introduce each as it impinges on that part of the project and they may not be in the order that they are presented in the texts I am reading.


In the background I have selected the project, I have briefed the client on the approach taken and have assembled the team. The client, who I’ll keep under wraps for now, is somewhat keen to experiment with this method.


Firstly a few basic concepts.


Customer Centric Development and the Circle of Life


XP puts the customer firmly at the centre of the projects in terms of defining requirements (user stories), getting involved in the testing and choosing project priorities. The programmer is equally important and in refining the scope, diagrammatically the interaction is meant to look like this..



There are four variables we can control in the project: cost, time, quality and scope. They are interdependent. Take a minute to look at these variables and play around with increasing or decreasing each one. What happens?

Getting the customer involved as in the circle of life above allows honest decisions to be made about what can be achieve in the limits of the four variables. Cost, in most of our experience, is the limiting constraint. The other variables adjust to suit.


Ideally XP insists on the customer being on-site and available. This is an ideal we shall have to work around. One rule we must adhere to is that “communication is king”. There will be misunderstandings, we must plan for them. Email communication is error prone, verbal communication (meetings, telephone conversations etc.) is ideal. Communication shortens project timescales!


User Stories and the Beginning of the Project Scope


User Stories are customer requirements. Customers define User Stories, programmers, however tempting it is, don’t. XP suggests that the customer defines the stories on cards, with each card representing a piece of functionality that the system will need to accomplish. Stories should encompass one or two weeks of work. All the stories don’t need to be defined at the beginning. XP “embraces change” and have ideas in place to meet them. User stories will grow, shrink, change and split over the lifetime of a project.

User stories will be picked up by a programmer and developed. More on that later!

Testing, Testing


XP demand that testing is carried out strategically, continuously by developers and customers. Customers define tests as well as programmers. Programmers should aim to automate the testing as much as possible.

Testing should be done all of the time to keep the development on track and the quality of code to a maximum.

Oh, and it might be an idea to consider parallel testing, stress testing and monkey testing (idiot users and nonsensical input etc.) as well.

Releasing


XP plans for frequent releases. Frequent releases to the customer allow them to check functionality, see progress, refine stories and choose priorities. Releasing at the end of a project runs the risk of delivering something the customer did not want. XP is the antidote to this.

Each release should be as small as possible and should contain the most valuable business requirements.

Thoughts and Progress


We are all in agreement with the concepts and have begun to implement the process. I have had a look at some of the software packages available to manage the process but for now we have opted for a purist, pen and paper approach.

Do I agree with everything?



I’m not sure. Some of the terminology isn’t sitting right with me. I have something against the word “stories”.

The testing and releasing concepts hold no problems for me and the team.
The customer centric approach is great but I envisage a time when we drift away from the ideal and the customer gets detached from the development cycle.

Measurement of success is on our minds at present, both for this project and for XP as a whole. I shall have to delve into the theory more.

So we are off… We have our project, team, customer room, whiteboards, cards and coffee. We have defined our first user stories and have are at the beginnings of implementing some of the features.

The next blog will present a more developer focused view of XP.


References:
Extreme Programming - Explained

Extreme Programming - Installed

Labels:

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home