Introduction to Extreme Programming Joe Drumgoole 10-December-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

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

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

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

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

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

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

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

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

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

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

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

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

The Simplest Possible Solution

Spike solutions for thorny situations

Refactor for simplicity and clarity

No Design for tomorrow

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

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

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

Write Tests First

Tests force user view/integration view/interface view

Tests demonstrate progress

Tests prove existence

Automated test for everything that could break

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

Many customers

No Customer

Reluctant Customer

Team skill set

Release Constraints

User Training

No time for tests

Architecture Astronautics

Waterfall Documentation

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!

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!