Introduction to eXtreme Programming

1
Introduction to eXtreme Programming

• Remko Popma
• Azzurri Ltd.
• http//www.azzurri.co.jp

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 isnt used.
• What if you have automated testing

7
Project cancelled
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
12
What if
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
• 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

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 partners 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 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

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 priorities
• can do a good job
• can make technical decisions
• dont work overtime

• get most business value first
• get accurate feedback
• can make informed business decisions
• 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

• Questions?