Extreme Process Extreme ProcessThe customers can't possibly really know what they need at the beginning: observing and using the system is part of learning what they actually needed. The real Business Value of the software that exists, and that could exist, is learned, not known up front.
The developers can't possibly get everything designed right the first time. Actually implementing the thing is the best way to learn what you should have done. (Thus Brooks: "Hence plan to throw one away; you will, anyhow.")
A development process that can EmbraceChange can thrive where one that tries to hold back change will falter.
Any real software development effort has NotEnoughTime, or TooMuchToDo. There are many ideas with Business Value, and it's necessary to determine which ideas have the most value and try to do those sooner than those with less, BusinessValueFirst.
A development process that can manage the TimeConflict? in a public fashion can thrive, where one that tries to sweep this topic under the carpet will falter.
Any real software development effort needs to know when it is complete, with high enough quality.
Developers need to know when to stop developing on one feature (i.e. when it's complete enough and of high enough quality) and to move on to the next.
Customers need to know that the system is of high enough completeness and quality to deploy. In addition, without clear insight into how complete, and how good the project is, customer confidence in the project will decline, leading to problems.
A development process that makes completeness and quality publicly visible can thrive, while one that cannot identify completeness and quality will falter.
How does ExtremeProgramming deal with these issues, you're probably asking yourself.
ExtremeProgramming is people-centric, not paper-centric. It tries, wherever possible, to go with the natural inclinations of people, not against them. XP does that on purpose, and we think it's a good thing.
Over-simplifying, customers like to ask for stuff and receive value, and developers like to code stuff and know they did well. That's what XP is about.
An ExtremeProgramming project must have customers and developers on the team. Let's begin with how they interact.
Customers define requirements with UserStories, and give them priorities based on Business Value. Customers can change the priority of any story at any time.
Developers examine all the stories, asking questions until they understand what they mean. They then estimate the time required to implement each story. Using these estimates, and the priorities, and a LoadFactor for converting estimates to real time, the team arranges the stories into the CommitmentSchedule.
The schedule may be "too long". The customers (who own the concern for Business Value) move important stories forward and less important ones back, loading Business Value toward the front of the project. Customers cannot change the estimate on any story: they can change the requirements and ask for a new estimate. This process provides a CommitmentSchedule with sufficient Business Value for deployment at the earliest possible date.
[XP recognizes that the estimates will not be perfectly accurate, especially at the beginning. Read on to see how the estimates are improved.]
Note at this point that the developers provide the input as to how long things will take (and customers can't change those estimates). Customers provide the knowledge of what is valuable, and choose what should be done first. The result is a schedule that development believes and that provides value to the customer as early as possible.
The CommitmentSchedule isn't development, it is an overall plan for development. Now we must do some development. We begin with the IterationPlan.
ExtremeProgramming breaks development into short increments of a few weeks, called "Iterations". Customers select stories from the beginning of the CommitmentSchedule for the iteration.
For each proposed story, developers state each EngineeringTask needed to implement the story. (Late on in the project, they just know. Early on they may need to use CrcCards or a SpikeSolution to determine the tasks.) Engineers sign up for and estimate the time they need to implement each EngineeringTask.
After all the tasks are estimated, a LoadFactor is applied to convert estimates to real time. If there's more time available, more stories are done. If there is TooMuchToDo, the customers decide which stories should be deferred. At no time does the customer (or anyone else) get to change a programmer's estimate. At no time do the developers get to decide what the customers will or will not get.
Now we know what is scheduled to be done in the next few weeks, who is going to do it, and how long they think it will take.
Customers proceed to define the AcceptanceTests that will show whether each chosen story is correctly implemented. Try to have the tests in place no later than half-way through the iteration. The developers use the tests to know when their work is complete.
Developers do any additional discussion, work with CrcCards, or SpikeSolutions to be sure just how they are going to do things. They implement the EngineeringTasks needed, building UnitTests for everything that could possibly not work as they go.
Developers release code to the development code base frequently, ideally daily. When they release, not only their UnitTests, but all the system's UnitTests must run at 100%. This gives great certainty that the new functionality works, and that nothing has been broken.
The team tester runs all the AcceptanceTests for this iteration frequently, graphing and displaying how things are going. She also runs all the past AcceptanceTests, making sure that nothing has been broken. When something breaks, it gets looked at immediately, while developers still have a good idea of what went wrong.
The team tracker (TrackerRole) checks in with developers a few times per iteration, asking how much time they have spent so far on each task and how much they have to go. This feeds back into the LoadFactor, increasing its accuracy for next time. Tracker also notes developers who seem to be in trouble, and gets them help.
The effect of this is that at the end of the iteration, you know very accurately what is done, what is not done, how well it all works, and how long it actually took.
Developers follow a specific discipline of development. They DoTheSimplestThingThatCouldPossiblyWork, which means that they choose simple solutions to the EngineeringTask's. They ensure that the code they create is well-factored, following the rule OnceAndOnlyOnce to make the system's code as simple as possible. They build with UnitTests as they go. All developers follow the same Coding Standards, which ensure good formatting, readable code, and a common base of naming conventions.
Developers work always in pairs, ensuring on-the-fly code review and ensuring that at least two developers are intimately familiar with every part of the system. XP teams generally use CollectiveCodeOwnership to spread cross-training even further.
Every three iterations, a new ReleasePlan is done. Many stories have been completed each time, and it is easy to get a good sense of whether progress has been as expected. If it is not, the LoadFactor is adjusted to deal with the facts of the situation (and, if appropriate, process improvements are put in place to try to improve the factor for next time).
An ExtremeProcess reports in terms of the FourVariables resources, scope, quality and time. Even when things are going poorly, the project uses the FourVariablesUnderStress. The facts of the situation are determined quite objectively: Resources is who and what you have; scope is the stories you have done; quality is shown in the graphs; time is on the calendar and projected by the current CommitmentSchedule.
Everyone knows exactly what has happened so far and has a projection, not a WAG, of what's going to happen.
Does some part of this seem undisciplined? If so, please leave a note here so that it can be improved. -- RonJeffries
Hard to say. I must admit that about half-way through the description my eyes start to glaze over because you've thrown so many things at me in so short a space I cant keep them all straight in my head at once. Is there anything you can do to add a little more structure to the descriptions and/or the steps within it? Something that prepares me with a little "mental schema" in my head of the overall structure would be good. A bit of an overview of the main pieces and their sequence, and then an overview of how each of those breaks down would be a big help to me before diving in to the rest of it. (Did that make any sense?) --BradAppleton
Hear, Hear! My 30 years programming votes for XP. Just visiting but I see no mention of TheMythicalManMonth. Old but not dated. Damn. I finally feel vindicated. -- AlbertWagner
Maybe what would help is a TransitioningToExtremeProgramming page? -- WilliamGrosso
I would love it if it had an introduction at the top to all the concepts I need to know before reading, so I don't keep on following links two or three levels up. Is like looking up a word in the dictionary just to find another one you don't know in the definition...it's still good though. -- JorgeHaro?
Have you checked ExtremeProgrammingRoadmap and ExtremeProgrammingSystem?
Is the ExtremeProcess applicable for SingleDevelopers? You know the Lone Coders in the dead of the night?
Is the use of deprecated LoadFactor intentional on this page? Can it just be replaced by ProjectVelocity? -- WojtekMurawski?
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006