A Pattern For Task Focus

Newcomers to an XP style of development, and especially completer finishers, often have trouble breaking down tasks. It is a much underrated skill.

The warning flag is the discussion mentions classes outside of the class being worked on, or, in other words 'the big picture' keeps looming up to hide the work.

So here is a behaviour pattern I'm working on:

1. State the story in multiple single sentences. These are the use cases that will be used to the automated user acceptance tests (UATs).
   
2. Now break the story in developer tasks, each a simple sentence of the form: "When ..... (set/tell) .... to .....". Smaller the better, do not be shy to have many.
   
3. Implement each task.
4. Run the UATs ... gosh it works!
   

Understand the customer requirements, break them down to short stories (a real kill), then divide it up into developer (not customer tasks). It is another view of ask not what you need to do to the code but what the code needs of you. When you are at task level the task tells you the unit test and from then on the code tells you what it needs.

The anti-patterns here are hearing talk of 'how to do it' rather than what is needed. For example 'inject object X into Y'. This stuff is how, but does not add functionality. Make the code tell you to do this.