Introduction to
eXtreme Programming
Remko Popma
Azzurri Ltd.
http://www.azzurri.co.jp
1
Contents
• The problem
– Problems in software development
• eXtreme Programming (XP)
–
–
–
–
Values
Practices
Why XP works
Benefits of XP
• Conclusions
• Resources
2
Problems in
software development
Risks:
• Schedule slips
• Business misunderstood
• Defect rate
• Project cancelled
• System goes sour
• Business changes
3
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
4
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
5
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
6
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)
7
Project cancelled
• What if:
short releases deliver at least some useful
working software, reflecting investment to
date
8
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
9
Business changes
• New laws, market changes: business
priorities change
• What if:
the customer can change their mind,
substitute functionality, and change priorities
10
Economics of
software development
cost of change
Requirements
Analysis
Design
Implementation
11
Testing
Production
What if…
cost of change
Time
12
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.
13
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
14
XP values
•
•
•
•
Communication
Simplicity
Feedback
Courage
15
XP practices
•
•
•
•
•
•
•
The Planning Game*
Small Releases
Metaphor
Simple Design*
Testing*
Refactoring*
Pair Programming*
•
•
•
•
•
•
•
16
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
17
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
18
Unit tests
19
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
20
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)
21
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
22
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
23
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
24
Who benefits from XP?
Programmers:
• get clear requirements
& priorities
• can do a good job
• can make technical
decisions
• don’t work overtime
Customers:
• get most business
value first
• get accurate feedback
• can make informed
business decisions
• can change their mind
25
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
26
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
27
Web resources
•
•
•
•
•
www.junit.org
www.xprogramming.com
www.extremeprogramming.org
www.refactoring.com
www.pairprogramming.com
28
Thank you
• Questions?
29