Introduction to eXtreme Programming

Contents
The problem
Problems in software development

eXtreme Programming (XP)

Values Practices Why XP works Benefits of XP

Conclusions Resources

Problems in software development

Risks: Schedule slips Business misunderstood Defect rate Project cancelled System goes sour Business changes

Schedule slips
Many projects are not delivered on time
Examples: Word 1.0, Netscape 6

Some deadlines cannot be moved

Example: Y2K

What if: most business value is delivered on time

Business misunderstood
Without direct communication, developers have to guess what the customer wants.
Example: The Orthodontics Project

What if: an on-site customer steers development

Defect rate
The software is put in production, but the defect rate is so high that it isnt used. What if: you have automated testing

Project cancelled
Size of project 1 function point 10 function points 100 function points 1,000 function points 10,000 function points 100,000 function points Average Early 14.68% 11.08% 6.06% 1.24% 0.14% 0.00% 5.53% On-Time 83.16% 81.25% 74.77% 60.76% 28.00% 13.67% 56.94% Delayed 1.92% 5.67% 11.83% 17.67% 23.83% 21.33% 13.71% Cancelled 0.25% 2.00% 7.33% 20.33% 48.00% 65.00% 23.82% Sum 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%

Table 1: Percentage of projects early, on-time, late, canceled (from Patterns of Software Systems Failure and Success, by Capers Jones)

Project cancelled
What if: short releases deliver at least some useful working software, reflecting investment to date

System goes sour

Software is put into production successfully, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced. What if: the design is simple and the code quality is high

Business changes
New laws, market changes: business priorities change What if: the customer can change their mind, substitute functionality, and change priorities

Economics of software development

cost of change

Requirements

Analysis

Design

Implementation

Testing

Production

What if
cost of change

Time

eXtreme Programming
A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.

eXtreme
Taking proven practices to the extreme If testing is good, let everybody test all the time If code reviews are good, review all the time If design is good, refactor all the time If integration testing is good, integrate all the time If simplicity is good, do the simplest thing that could possibly work If short iterations are good, make them really, really short

XP values

Communication Simplicity Feedback Courage

XP practices
The Planning Game* Small Releases Metaphor Simple Design* Testing* Refactoring* Pair Programming* Collective Ownership Continuous Integration 40-Hour Week On-Site Customer Coding Standards Open workspace Daily Schema migration

The Planning Game

Business writes a story describing desired functionality Stories are written on index cards Development estimates stories Velocity determines number of stories per iteration Business splits and prioritizes stories and determines the composition of releases Velocity is measured and adjusted every iteration Customer steers development

Testing
Unit Tests and Functional Tests Test a little, code a little
Test-first programming

Tests become the specification Tests give confidence in the system Tests give courage to change the system

Unit tests

Pair Programming
Two people looking at one machine, with one keyboard and one mouse Two roles: implementation and strategy All production code is written in pairs

Pair Programming Benefits

15% less output than 2 solo programmers Continuous code review: better design, fewer defects Confidence to add to or change the system Discipline to always test and refactor Teach each other how the system works (reduced staffing risks) Learn from partners knowledge and experience (enhances technical skills)

Simple design
Do the simplest thing that could possibly work Passes all the tests No duplicate code States every intention Fewest possible classes and methods

Refactoring
Design becomes everybodys daily business Continuously improve quality of the code Unit Tests and Pair Programming give courage Result: Fast development speed Code becomes easy to change

Why XP works
Light-weight: discipline without bureaucracy Under stress, people do what is easiest
All XP practices have short-term benefits as well as long-term benefits

Development as a Conversation The code is the documentation XP is fun

Who benefits from XP?

Programmers: Customers: get clear requirements get most business & priorities value first can do a good job get accurate feedback can make technical can make informed decisions business decisions dont work overtime can change their mind

Conclusions
Use XP on projects
with vague or changing requirements with small teams

XP works, and is very fast XP is fun to execute At Azzurri, we use XP as much as possible with clients, and exclusively for internal projects

XP books and papers

Extreme Programming Explained Kent Beck Refactoring Martin Fowler Planning Extreme Programming Kent Beck et al Extreme Programming Installed Ron Jeffries et al Extreme Programming Examined Giancarlo Succi et al Extreme Programming in Practice Robert C. Martin et al Extreme Programming Explored William C. Wake Extreme Programming Applied Ken Auer et al The Costs and Benefits of Pair Programming Alistair Cockburn et al

Web resources
www.junit.org www.xprogramming.com www.extremeprogramming.org www.refactoring.com www.pairprogramming.com

Thank you