Introduction to Extreme Programming

Joe Drumgoole

10-December-2004

Global Product Engineering Slide 2 10-Dec-2004

What is Extreme Programming?

Doing things we know work to the extreme! Testing is Good –

– Write tests for everything– Write tests first– Write tests that fail and then fix them

Code Review is Good –– Review every line of code by ensuring that all code is written by

programmers working in pairs (pair-programming)

Integration is Good –– Integrate as often as possible (daily, hourly builds)– Use tests to identify regressions

Global Product Engineering Slide 3 10-Dec-2004

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan

That is, while there is value in the items on the right,we value the items on the left more

Global Product Engineering Slide 4 10-Dec-2004

XP – The Players

The Customer– Onsite– Engaged– Writes user stories– Defines Priorities

The Programmer– Volunteers to implement specific stories– Provides estimates– Splits stories where required– Identifies risks/difficulties– Implements

The Project Manager– Removes obstacles– Tracks Progress– Plots Project Velocity

Global Product Engineering Slide 5 10-Dec-2004

XP – Planning – User Stories

Requirements = User Stories User Stories are :-

– Short (Capture on a post-it sized note)– High level– Always express end-user functionality and/or features

User Stories are always written by the Customer User Stories lead to the creation of Acceptance Tests Acceptance Tests are executable demonstrations of features The complete set of stories is then used to create Release Plan

Global Product Engineering Slide 6 10-Dec-2004

XP – Planning – Release Planning

Each programmer gives an estimate as to the time need to complete a given story

The development cycle is divided into Iterations Each iteration should span about 2 to 3 weeks Programmers plan each iteration when it starts Customer assigns priority at the start of each iteration Number of Stories per Iteration = Project Velocity Project Velocity for the next iteration is defined by what

happened in the last iteration

Global Product Engineering Slide 7 10-Dec-2004

XP - Coding

Customer is always available Coding is to agreed standards Test driven development Code is written in pairs (Pair Programming) Code is owned by everybody One pair integrates at a time Integration is continuous throughout the project NO OVERTIME

Global Product Engineering Slide 8 10-Dec-2004

XP - Design

The Simplest Possible Solution Spike solutions for thorny situations Refactor for simplicity and clarity No Design for tomorrow

Global Product Engineering Slide 9 10-Dec-2004

XP - Testing

Test Driven Development– Inverts your point of view– Forces you to think about integration– Leads to cleaner interfaces– Tests prove existence

All code must pass unit tests prior to integration All bugs lead to unit tests GUIs are code free, put the code in the model Acceptance Tests are run weekly and the score is a progress

measure What to test ? Test everything that might break

Global Product Engineering Slide 10 10-Dec-2004

Test Driven Development

Write Tests First Tests force user view/integration view/interface view Tests demonstrate progress Tests prove existence Automated test for everything that could break

Global Product Engineering Slide 11 10-Dec-2004

XP - Problems

Many customers No Customer Reluctant Customer Team skill set Release Constraints User Training No time for tests Architecture Astronautics Waterfall Documentation

Global Product Engineering Slide 12 10-Dec-2004

Conclusions

XP has a proven track record Its easy to implement Has excellent tool support Might be a good fit at Oracle if we can engage our customers!