The document describes the twelve core practices of extreme programming (XP). It discusses each practice in 1-2 paragraphs, covering pair programming, refactoring, simple design, collective code ownership, continuous integration, on-site customer, small releases, 40-hour work week, coding standards, system metaphor, planning game, and testing (including unit and acceptance testing). The advantages include customer focus, incremental releases, and continuous testing/integration improving quality. Disadvantages include being suited for a single co-located team and not working as well without customer involvement or for large scalable systems.

1. Twelve practices of XP
• 1. Pair programming
• 2. Refactoring
• 3. Simple design
• 4. Collective code ownership
• 5. Continuous integration
• 6. On-site customer
• 7. Small releases
• 8. 40-hour week
• 9. Coding standard
• 10. System metaphor (Imagine)
• 11. The planning game
• 12. Testing

2. 1. Pair programming
• In XP, pairs of developers write all production code. This
approach may sound inefficient.
• Pair programming provides many benefits:
• All design decisions involve at least two brains.
• At least two people are familiar with every part of the
system.
• There is less chance of both people neglecting tests.
• Changing pairs spreads knowledge throughout the team.
• Code is always being reviewed by at least one more person.
• Research also is showing that programming in pairs is
actually more efficient than programming alone.

3. Pair Programming
• All production code written with 2
programmers at 1 machine
– One tactical, one strategic
• Pairing should be dynamic
– Members in pair switch roles every 30-60
minutes
– Change pairs each task
• Experiments showing effectivenes

4. University of Utah Experiment: Pairs spent 15% more
time on the program than individuals

5. University of Utah Experiment: Code written by pairs
passed more test cases than code written by
individuals

6. University of Utah Experiment: Pairs consistently
implemented the same functionality produced by
individuals in fewer lines of code

7. University of Utah Experiment: Learning how to
program in an environment where there are rapidly
tangible results is fun and allows one to learn faster

8. 2. Refactoring
• Refactoring is the technique of improving code without changing
functionality.
• Refactoring lets you incorporate that learning into your code
without breaking the tests. That means it will survive longer.

9. 3. Simple design
• XP says design should not be done all at once. We always try to use the
simplest design that could possibly work at any point, changing it as we
go to reflect emerging reality.
• What is the simplest design that could possibly work?
• Runs all the tests
• Contains no duplicate code
• States the programmers' intent for all code clearly
• Contains the fewest possible classes and methods
• Don't include extra features that aren't being used. We call such things
YAGNI, which stands for "You Aren't Going to Need It."

10. 4. Collective code ownership
• Any person on the team should have the authority to make
changes to the code to improve it.
• Everybody owns all the code, meaning everybody is responsible
for it.
• Saying that everybody owns all the code isn't the same as saying
that nobody owns it.
• XP says, "You break it, you fix it." We have unit tests that must
run before and after each integration. If you break something,
it's your responsibility to fix it.

11. 5. Continuous integration
• Frequent code integration helps you to avoid integration
nightmares.
• XP teams integrate their code several times a day, after they
get all the unit tests for the system to run.
• Traditional approaches tend to work like this: code a
lot, do integration, then spend a significant amount of
time fixing the problems.
• When you integrate frequently, the cause of failure for any
particular integration is more obvious.
• Fixing is easier, takes less time, and keeps the team moving
at maximum speed.

12. 6. On-site customer
• An XP team needs to have a customer available on site to clarify
stories and to make critical business decisions.
• Developers aren't allowed to do that alone. It eliminates wait for
decisions.
• The idea is that communicating face to face minimizes the
chances of misunderstanding, unlike writing all the requirements
down in a static document.
• We have found that having the customer on site is the best
possible situation. Atleast the customer must be available
whenever needed to answer questions and to provide.

13. User Story #1
Story 1
A person registers with the agency by
providing personal information,
information,about the kind of person
they are seeking, an alias to conceal
Their true identity, and confidential
contact details.

14. 7. Small releases
• Releases should be as small as possible while still delivering
enough business value to make them worthwhile.
• This provides value to the customer as early as possible.
• Small releases also will provide concrete feedback to developers
on what meets customer needs and what doesn't. The team then
can include these lessons in its planning for the next release.

15. 8. 40-hour week
• Kent Beck says that he wants to be "...fresh and eager every
morning, and tired and satisfied every night."
• Tired developers make more mistakes, which will slow you down
more in the long run than keeping a "normal" schedule will.
• Even if developers could function well for longer periods.

16. A Day In XP

17. 9. Coding standard
• Without coding standards, it is harder to refactor code, harder to
switch pairs as often as you should, and harder to go fast.
• The goal should be that no one on the team can recognize who
wrote which piece of code.
• Make sure your code communicates clearly.
• Don't spend too much time. Create the simplest standard that
could possibly work.

18. 10. System metaphor (Imagine)
• A sort of map that lets developers see where new pieces will fit.
• The metaphor gives the team a consistent picture they can use to
describe the way the existing system works, where new parts fit,
and what form they should take.
• It is important to remember that having everyone understand
how the system fits together.

19. 11. The planning game
• The main idea behind this practice is to make a rough
plan quickly and refine it as things become clearer.
The development team determines:
• Estimates of how long it will take to develop a
module
• Cost implications of using various technology options
• Team organization
• The "risk" of each module
• Order of module development within an iteration
(doing risky items first can ease risk)

20. 11. The planning game
The customer determines:
• Scope
• Release dates
• Priority (which features get developed first, based on
business value)
• Planning happens often. This provides frequent
opportunity for either the customer or the developers to
adjust the plan as they learn new things.

21. 12. Testing
Unit testing
• Developers write the unit tests as they write code.
• Unit tests tell developers whether the system "works" at any
point in time.
• Developers write unit tests for every method that could
possibly break, before they write the code for those
methods. Then they write just enough code to get the test to
pass.
• Unit tests give developers confidence that their code works.
It leaves a trail for other developers to understand the
original developer's intent.
• Unit tests also give developers courage to refactor the code,
because a test failure tells the developer immediately if
something's broken.
• Unit tests should be automated and give a clear
pass/fail result.

22. Testing
Acceptance testing
• The customer writes acceptance tests after they define module.
• Acceptance tests tell the team whether the system does what
users want it to do.
• Customers are responsible for making sure each story has
acceptance tests to validate it. The customer can write the tests
himself or recruit other members of his organization to write
them, or combine the two approaches.
• Acceptance tests should ensure developers are not breaking any
existing features as they implement new ones.
• Customers will need some help from the development team to
write acceptance tests.

23. Advantages/Disadvantages
ADVANTAGES
• Customer focus increase the chance that the software
produced will actually meet the needs of the users
• The focus on small, incremental release decreases the risk
on your project:
– by showing that your approach works and
– by putting functionality in the hands of your users, enabling them to
provide timely feedback regarding your work.
• Continuous testing and integration helps to increase the
quality of your work
• XP is attractive to programmers who normally are unwilling
to adopt a software process, enabling your organization to
manage its software efforts better.

24. Advantages/Disadvantages
DISADVANTAGES
• XP is geared toward a single project, developed and
maintained by a single team.
• XP is particularly vulnerable to "bad apple" developers who:
– don't work well with others
– who think they know it all, and/or
– who are not willing to share their "superior” code
• XP will not work in an environment where a customer or
manager insists on a complete specification or design before
they begin programming.
• XP will not work in an environment where programmers are
separated geographically.
• XP has not been proven to work with systems that have
scalability issues (new applications must integrate into existing
systems).