Extreme Programming (XP) is an agile software development process designed for small to medium-sized projects. It focuses on adaptive planning, small releases, simple design, pair programming, and continuous refactoring. The core values of XP are communication, feedback, simplicity, and courage. XP aims to produce high-quality software through practices like writing tests before code, continuous integration, and close collaboration between developers and customers.

1. eXtreme Programming
A lightweight development
process for small to medium-sized
projects (an Agile Process)
by Shahid N. Shah

2. Slide 2 of 18
Sampling of Available
Methodolgies
Waterfall*
Extreme
Programming
Crystal Family
(Alistair Cockburn)
Open Source
Adaptive Software
Development (Jim
Highsmith)
SCRUM
Feature Driven
Development (FDD,
Jeff De Luca and
Peter Coad)
Dynamic System
Development Method
(DSDM, $$)
Rational Unified
Process ($$)** Non-agile

3. Slide 3 of 18
XP Philosophy
Always ask yourself: “what is the simplest
thing that could possibly work?” -- Kent
Beck, XP Creator
Never do any more coding, more testing,
more process, or more documentation than
is absolutely necessary to delight the
customer.
Main values: Communication, Feedback,
Simplicity, and Courage
Formalize and do what has been known by
“smart guys” for years
Not a “license to hack”!

4. Slide 4 of 18
XP Key Practices
Adaptive, not predictive
The Planning Game -- Quick, up-date as needed,
80/20 rule, push out what doesn’t need to be
immediately decided
Small releases -- Get simple system into production
quickly, add features in small releases
Simple design -- Design as simple as possible
Refactoring -- Continuously restructure to simplify,
remove duplication
40 hour week
On-site customer -- collective ownership
Travel light -- No more documentation than needed
to support deployment of application

5. Slide 5 of 18
Customer’s bill of rights
To set objectives for the
project and have them
followed.
To know how long the
software project will take and
how much it will cost.
To decide which features are
in and which are out of the
software.
To know the project’s status.
To make reasonable
changes to requirements
throughout the course of the
project and to know the
costs of making these
changes.
To be apprised regularly of
risks that could affect cost,
schedule or quality.
To have ready access to
project deliverables
throughout the project.

6. Slide 6 of 18
Developer’s Bill of
Rights
To know the project objectives
and to be able to clarify
priorities.
To know in detail what product
I’m supposed to build.
To have ready access to the
customer, manager, marketer,
or other person responsible for
the functionality.
To work each phase of the
project in a technically
responsible way.
To approve effort and schedule
estimates for any work that I will
be asked to perform.
To have my project’s status
reported accurately to
customers and upper
management.
To work in a productive
environment free from frequent
interruptions.

7. Slide 7 of 18
Benefits of XP
Software stays soft
Handles changing requirements with
relative ease
Quickly produces something useful,
keeps making useful enhancements --
delivery is provided when customer is
ready
Average developers can produce great
software

8. Slide 8 of 18
Prerequisites
Flexible Project Management
Goal is to delight customers and not to
maintain process (though they are not
mutually exclusive)
Groups that can talk to each other
Close contact with users

9. Slide 9 of 18
Obvious things to do
Staged Delivery
continuous stream of value
feedback
adapt to change
Business people make business decisions
and technical people make technical
decisions
Regression testing, unit tests
Review designs and code

10. Slide 10 of 18
Extreme Programming
Analysis
Test
Code
Design
Project Management

11. Slide 11 of 18
Extreme Analysis
Describe system as a set of user stories
(storyboards)
Users write stories explaining one use of
the system (explain by example)
Like use cases, but informal (no special
tools are needed)
Realize that all artifacts created during
design will rarely be updated after
implementation

12. Slide 12 of 18
Extreme Testing
Write tests before code
 unit tests before each class
 end-to-end tests before any classes
Convert each user story into a set of tests
All unit tests must run 100% all the time
Don’t worry if you can’t test everything
 GUI
 real-time I/O
 complete coverage
Don’t worry if testing is expensive

13. Slide 13 of 18
Extreme Coding
Eliminate code in favor of configuration
Write code for test cases one at a time
Write the simplest thing that could possibly
work
Goal: make the tests work ASAP
 write new classes
 use/change old classes
 copy code
 add if statements
Enforce coding standards

14. Slide 14 of 18
Pair Programming
All code is written in pairs
Pairs talk continually
Pair switches driver frequently
People switch pairs several times a day
Continuous code review

15. Slide 15 of 18
Refactoring:
Extreme Design
Make sure each thing is done in one
place - eliminate all duplicate code
Make sure each class/function does
one thing
All code must be readable
All tests run

16. Slide 16 of 18
Extreme Design
Project starts with a few days of design
on white-boards/CRC cards
Major problems lead to group design
sessions (servers, objects, etc)
Documentation is after the fact, and no
more than necessary
Start simple, refactor to keep simple

17. Slide 17 of 18
Extreme Scheduling
Customer write stories
Developers estimate cost
Customer decides which to do next
Group a few weeks worth of stories into
an iteration
Developers implement stories one at a
time until iteration is finished

18. Slide 18 of 18
What is Extreme?
Extreme, but not unusual
user stories, schedule negotiation, staged
delivery, testing, simplicity
Extreme and unusual
pair programming
continuous refactoring

19. Slide 19 of 18
Conclusion
Produce consistently better applications
with fewer people (or less qualified
people), in less time, with higher quality
and significantly lower overall cost.