Intro to Extreme Programming (XP)

John Arrizza

Mar 4/2004

Overview & Agenda

• John Arrizza: 18 years experience in C/C++, C#, Perl, etc. High reliability, multi-process, multi-threaded applications. Currently a Team Lead for Nokia UI Software using “mostly-XP ™”

AgendaWhat is XP?Why XP?XP in UseFeedbackTypical XP IterationRecommendations

Questions welcome throughout!

What is XP?

XP is a set of good software engineering practices

Other XP

Requirements Gathering (done once at start)

Continuous: Planning Game (every Iteration), Release Planning

Scheduling Continuous: Planning Game, Release Planning

Design (done once at start) Continuous: On-site Customer, Test Driven Development, Merciless Refactoring, Simple Design

Comparison (cont’d)Other XP

Code reviews, design reviews, design walkthroughs, structured walkthroughs, etc.

Continuous: On-site Customer, Pair Programming, Coding Standard, Short Iterations, Integrate Often

Integration (done once at end) Continuous: Integrate often, Small releases

Testing (done once at end) Continuous: testing throughout the project via TDD, UTs, and ATs

Why XP?

• XP has high exposure– It has been featured in IEEE magazine and

other mainstream S/W press– There are ~50 XP User groups around the

world. USA has the highest number, England, Germany and China are very high as well

– It is being taught in Universities (new grads will have XP exposure)

Why XP?

• Some companies using or investigating XP:– National: Verizon, Chrysler, Cisco, JPL,

StorageTek, Intel, Fannie Mae, IBM, NASA– SD Local: Systran, SAIC, Alaris, HP, Acelyris,

others?

Why XP?

• XP fits corporate goals– #1 Market immediacy

• I want it done

• I want it done now

• I want it done right (approx. zero bugs)

Why XP? (I want it done)

• XP delivers on these goals because of it’s high feedback:– A feature is done when the Acceptance Test

passes:• Not subjective, it either passes the test or not!

• Because of continuous integration, the onsite customer can actually see the new feature running immediately

Why XP? (I want it done now)

– Features are done in the order the customer asks for them. The timing is a business decision not a technical decision:

• If the customer wants it done now, it is done now.

• If the customer is willing to wait, it is done later.

Why XP? (I want it done right)

– The bug rate for XP projects is very low, typically near zero:

• Because of UTs and ATs, domino or spurious errors are detected very early, usually by the developer during development

• System integration errors, if any, are caught daily

• If an error does slip through, a test is immediately written to detect it. That error will never show up again.

XP in Use• Stories

– Similar to Use Cases and User Requirements.

– They capture a user request for new functionality. They are from the user & business point of view!

– They use informal language but are specific enough that the developers can design and code from them.

– They are estimable. There is enough information to decide how long it will take to complete the Story. If there is any ambiguity, the customer is on-site to ask more information.

– They are testable (so the developers can objectively determine whether they are done)

– They can be finished within one iteration (so every iteration accumulates completed business value)

XP in Use

• Iterations– An iteration is a fixed amount of development

time. Usually one or two weeks.

• Planning Game– Done at the start of an iteration, e.g. Monday– Customer determines what stories to do for that

iteration– Developers break those stories down into

Engineering tasks

XP in Use

• Release Planning– Customers write the Stories

– Customer orders the Stories in business value order to satisfy longer term goals (I.e. a release)

– Developers give feedback:• Estimates for each Story (in Points), Velocity (how many

Story Points the development team can do in one iteration)

• Is the Story testable?

• Will the Story fit in an iteration?

XP in Use

• Engineering Tasks– These are the units that the developers work in– A set of engineering tasks are used to satisfy

one or more Stories– Stories are comprised of one or more

Engineering tasks

XP in Use

• Unit Tests (UTs & Test Driven Development)– Unit test is written first for a particular Engineering

Task. The Unit Test fails…– Code is written... (usually very little code is necessary to

satisfy the Engineering Task)– …Until the Unit Test passes.

• Merciless Refactoring– Clean up the code to accommodate the new code just

written. Very quick, very safe (100% unit testing available)

– Clean up the design if necessary.

XP in Use

• Acceptance Tests (ATs)– When all Engineering Tasks for a Story are

complete, run the ATs.– Did the Story’s AT run successfully? If NO, fix

it! If YES:• check the code in

• integrate with the rest of the system

• run the entire AT suite

XP in Use

• Continuous Integration– Separate Integration machine– The Customer can see the running system with

all the Stories completed to date at any time, I.e. fully tested, fully integrated, zero known bugs, etc.

XP in Use

• There are other practices:– Simple Design– Pair Programming– Collective Ownership– Coding Standard– Metaphor (out of use?)– 40-hour week

Feedback

• XP ties these practices together with a simple philosophy: high feedback

• Without feedback, we are blind mice. With feedback, “you can run but you can’t hide!”

• Try to find ways to increase feedback whenever and wherever we can:– Daily meetings– Bring the customer on-site– Etc.

Why High Feedback?

• People are fallible, feedback gives us confirmation of our beliefs and assumptions in real time– Does this feature actually work?– Is it what the user really wanted?– Does this function actually work the way we think it does?– I believe that by changing function X, that Jake’s function Y still

works. Is that true?– I believe I’ve coded everything I’m supposed to – I’m done. Is that true?

• Do all unmodified features continue to work exactly as they did before I made my change?

• Do all modified or new features work as I expect them to?

Why High Feedback?

• To allow us to predict the future with more accuracy:– The shorter the time frame, the more accurate the

prediction: The far future is a bad extrapolation of the past and the present. The near future is a pretty good extrapolation of the near past and the present

– The more feedback we have of the accuracy of our predictions the better our predictions can become

Typical XP Iteration

• During a prior Release Planning session:– The Customers have already broken the

application up into User Stories– The Developers have already roughly estimated

all the Stories

• We’ve done a few iterations already. So Developers know their Velocity

Typical XP Iteration

Day 1: The Planning Game• Customer:

– Determine the highest business value Stories to do for this iteration

• Developers:– Do quick design to break down the Stories identified by the

Customer into Engineering Tasks– Estimate the Engineering Tasks, re-estimate the Stories if necessary. – Provide the Customer with our current Velocity. If the total Story

Points is greater than Velocity, Customer chooses Stories to remove or replace with lower cost Stories.

(For more attend Carlton’s excellent Planning Game Presentation)

Typical XP Iteration

• Day 1:– Developers volunteer for as many Engineering tasks that they can

do in an Iteration

• Day 1 – 5:– 10-15 minute Morning meeting to discuss status and any issues

– Developers write Unit tests, write code and refactor mercilessly to satisfy the Engineering Tasks.

– When all Engineering Tasks for a Story are done, the Story’s AT is run.

– If successful, integrate and run entire AT suite. Fix any integration errors immediately

Typical XP Iteration

• Day 5 (assuming a 1 week Iteration):– Developers tally up the completed Story Points.

This is the Velocity used for next iteration.

• At any time:– A Developer can ask on-site Customer for

details, clarification, etc.– A Customer can see the working system– A Customer can write up a new Story for

submission at the next Planning Game

Typical XP Iteration

• Periodically:– Customer re-does the Release Plan to ensure:

• deadlines will be met.

• Stories are ordered in highest business value

– Every 6-8 iterations: re-estimate all remaining Stories:• Usually enough common code has been done to lower many

estimates.

• Developers have much more knowledge about the system. New estimates will be more accurate.

Typical XP Iteration• At any point, we have:

– 100% unit tested code with 0 bugs, 100% mercilessly refactored code, I.e. clean code, clean design

– All Acceptance Tests for completed Stories pass (there will be failing Acceptance Tests for Stories incomplete or not yet begun)

– A running system that contains as much business value possible to date and very little incomplete code

– The ability to stop the project with very little impact

– The ability to pause the project and temporarily divert resources with very little impact

Recommendations

• Read: the White book “Extreme Programming Explained”; Green book “Planning Extreme Programming”; many others available

• Hire an experienced XP Coach for the first project / first few iterations

Recommendations

• If you plan to use XP for a legacy project, introduce only one or two practices at a time. I recommend these as your first two:

• 1 week Iterations. Fall out:– Better build and development environment– Better planning and delivery (which can lead into

Stories, Release Planning, Planning Game)– Quicker turnaround times for errors and change requests– Pressure on QA to test recent changes (which can lead

into Acceptance Tests, Unit Tests)

Recommendations

• Automated Acceptance Tests. Fall out:– Bugs!

– Pressure to fix bad architecture, bad code, easier to maintain code (which can lead into Unit Tests, Merciless Refactoring, Simple Design)

– Shorter development cycle becomes a possibility

– Potential to safely rewrite/refactor for testability and maintainability

The End