Extreme programming

1. What is
XP

2. What is XP?
● XP is a philosophy of software development
based on well laid out values, principles and
practices.
● Goal of XP is outstanding software
development at lower cost, with fewer defects,
high productivity and much higher return on
investment.

3. Activities
XP describes four basic activities that are performed within the software
development process.
● Coding
● The customer is always available, Code the Unit test first, Only one pair integrates
code at a time, Leave Optimization till last, No Overtime
● Testing
● Unit Test
● Acceptance Test
● Listening
● Programmers must listen to what the customers need the system to do, what
"business logic" is needed.
● Designing
● Good design will avoid lots of dependencies within a system.

4. History
●
Short history: KentBeck found himself dictating practice on a project for which he had assumed some
personal risk. Unsure of which to emphasize more, he chose to "turn all the knobs to ten."
●
More history: Kent drew on the experiences of many when he chose which knobs to turn. And the knobs
alone only set the course, many more made it work. Finally the technology, or at least the ideas motivating
the technology, played an important role too. At risk of writing myself too firmly into XP's history, I begin this
page with a summary of events. -- WardCunningham
● Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive
Compensation System (C3) payroll project.[6] Beck became the C3 project leader in March 1996 and
began to refine the development method used in the project and wrote a book on the method (in October
1999, Extreme Programming Explained was published).[6] Chrysler cancelled the C3 project in February
2000, after the company was acquired by Daimler-Benz.[7]
● Although extreme programming itself is relatively new, many of its practices have been around for some
time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-
first development, planning and writing tests before each micro-increment" was used as early as NASA's
Project Mercury, in the early 1960s (Larman 2003). Refactoring, modularity, bottom-up and incremental
design were described by Leo Brodie in his book published in 1984.[8]

5. Core
● Values
bring purpose to practices.
● Practices
are evidence of values.
● Principles
are domain specific guidelines for life.

6. Five Core Values
● Communication
● Customer – Developer, Developer – Developer
● Simplicity
● Start with the simplest solution. Extra functionality can then be added
later.
● Feedback
● From the system, the customer and the team
● Courage
● Refactoring
● Persistence
● Respect
● Respect other team members' work

7. Principles
● Humanity
People, What do people need to become good
developers?
● Economics
Every action should have business value.
● Mutual Benefit
Most important and most difficult to adhere to.
Extensive internal documentation.
● Self Similarity
You can copy structure of one solution to a new
context. Theme, story, tests.

8. Principles
● Improvement
In software development “perfect” is a verb not
adjective.
● Diversity
Teams need diversity.
● Reflection
How and Why of working.
● Flow
Steady flow of valuable software.
● Opportunities
Problems are opportunities.

9. Principles
● Redundancy
Do not remove redundancy that serves a valid purpose.
● Failure
Is failure a waste?
● Quality
Cost of quality? Quality ~ Productivity
● Baby Steps
Rapid small steps = leap.
● Accepted Responsibility
Responsibility cannot be assigned.

10. Activities and Practices
● Planning
● Planning Game
● Small Release
● Stories
● Designing
● Simple Design
● Refactoring
● System Metaphor
● Coding
● Pair Programming
● Continuous Integration
● Onsite Customer
● Testing
● Test First
● Acceptance Test
● Automation
● Team
● Informative workspace
● Collective Ownership
● Coding Standards
● Sustainable Pace

11. Primary Practices
●
Sit Together
●
Whole Team
●
Informative workspace
●
Sustainable Pace
●
Energized work
●
40-Hours Work Week
●
Pair Programming
●
Stories
●
Weekly Cycle
●
Quarterly Cycle
●
Slack
● 10 minute build
● Continuous Integration
● Test First Programming
● Incremental Design
● Planning Game
● Small Release
● System Metaphor
● Simple Design
● Refactoring
● Coding Standards

12. 40-hour week
● Kent Beck says that he wants to be "...fresh and
eager every morning, and tired and satisfied every
night."
● The exact number of hours isn't important - the
principle is. Burning the oil for long periods kills
performance.
● 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.

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

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

15. 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)
● 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.

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

17. Pair programming
● In XP, pairs of developers write all production code. This approach may sound
inefficient.
● As Martin Fowler says, "When people say that pair programming reduces
productivity, I answer, ‘that would be true if the most time-consuming part of
programming was typing.’ "
● 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 person.
Research also is showing that programming in pairs is actually more efficient
than programming alone

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

19. 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."

20. Refactoring
● Refactoring is the technique of improving code
without changing functionality.
● Developers try to make easier, if changing
existing code would make implementing the
new feature.
● Refactoring lets you incorporate that learning
into your code without breaking the tests. That
means it will survive longer.

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

22. Testing
a. 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.
● A developer cannot check code into the source code repository
until all the unit tests 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.

23. Testing
b. 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. Developed a reusable automated
acceptance test framework. The framework converts the input
to an XML file, runs the tests in the file, and spits out "pass" or
"fail" for each.

24. 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 a big-bang 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.

25. Corollary Practices
● Real Customer Involvement
No customer or proxy customer are not as
effective
● Incremental Deployment
Build little pieces and deploy it!
● Team Continuity
Do not shuffle the team too often.
● Shrinking Teams
● Root Cause Analysis
5 Why's

26. Corollary Practices
● Shared Code
Collective Code Ownership
● Code and Tests
The only artifacts
● Single code base
Avoid multiple streams
● Daily Deployment
● Negotiated Scope Contract
Ongoing negotiation on precise scope.