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
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.
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
University of Utah Experiment: Pairs spent 15% more time on the program than individuals
University of Utah Experiment: Code written by pairs passed more test cases than code written by individuals
University of Utah Experiment: Pairs consistently implemented the same functionality produced by individuals in fewer lines of code
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
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.
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."
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.
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.
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.
User Story #1
A person registers with the agency byproviding personal information,
information,about the kind of person they are seeking, an alias to concealTheir true identity, and confidential
contact details.
Story 1
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.
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.
A Day In XP
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.
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.
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)
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.
12. TestingUnit 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.
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.
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.
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).
