eXtreme Programming (XP) is an agile software development methodology that focuses on rapid software development and delivery through practices like continuous integration, pair programming, and frequent refactoring. It aims to address common software project problems like schedule slips, high defect rates, and changing requirements by having short development cycles, automated testing, and close collaboration between developers and customers. Key XP practices include planning game, small releases, simple design, testing, refactoring, pair programming, and on-site customer involvement. Adopting XP can benefit both developers through better requirements and technical empowerment, and customers through timely delivery of valuable software that can adapt to changes.

1. Introduction to
eXtreme Programming
www.talkwiseconsulting.com

2. Contents
The problem
◦ Problems in software development
eXtreme Programming (XP)
◦ Values
◦ Practices
◦ Why XP works
◦ Benefits of XP
Conclusions
Resources

3. Problems in
software development
Risks:
Schedule slips
Business misunderstood
Defect rate
Project cancelled
System goes sour
Business changes

4. 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

5. 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

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

7. Project cancelled
Size of project Early On-Time Delayed Cancelled Sum
1 function point 14.68% 83.16% 1.92% 0.25% 100.00%
10 function points 11.08% 81.25% 5.67% 2.00% 100.00%
100 function points 6.06% 74.77% 11.83% 7.33% 100.00%
1,000 function points 1.24% 60.76% 17.67% 20.33% 100.00%
10,000 function points 0.14% 28.00% 23.83% 48.00% 100.00%
100,000 function points 0.00% 13.67% 21.33% 65.00% 100.00%
Average 5.53% 56.94% 13.71% 23.82% 100.00%
Table 1: Percentage of projects early, on-time, late, canceled
(from Patterns of Software Systems Failure and Success, by Capers Jones)

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

9. 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

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

11. Economics of
software development
cost of change
Requirements Analysis Design Implementation Testing Production

12. What if…
cost of change
Time

13. 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.

14. 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

15. XP values
Communication
Simplicity
Feedback
Courage

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

17. 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

18. 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

19. Unit tests

20. 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

21. 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 partner’s knowledge and experience
(enhances technical skills)

22. 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

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

24. 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

25. 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
don’t work overtime can change their mind

26. 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

27. 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

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

29. Thank you