XP Practices

xp practice

Collective ownership
• Nobody owns any part of the code
• Anyone can work on anything
• Anyone’s code can be changed / deleted by anyone else

On-site customer
• Customer is considered to be an essential part of the team in XP
• Customer is a domain expert
• Always available (”on site”) to answer queries or make small-scale decisions
• Takes business and scheduling decisions
• May act on behalf of many users of system

Stories
• Customers or users write stories
• Each story captures one requirement scenario
• Typically recorded on standard index card for ease of management

A story card


Acceptance tests


Planning game

• Planning happens once at the start of each iteration
• Plan for just one iteration at a time
• Planning game is the main interface between customer and development team

How it works

• Customer provides all the story cards that have been written
• Developers write on each card an estimate of how long it will take to implement
• Developers provide an estimate of available developers X time (= “velocity”)
• Customer chooses stories by priority to fill the available time

Load factor

• Load factor is the multiplier that connects how long you think things will take to how long they actually take
• e.g. you think 2 days, it takes 6, so load factor is 3 (which is fairly typical!)
• You probably don’t need load factor calcs in this workshop because time units are small

Ideal time

• When load factor is in use, estimate in “ideal time” e.g. ideal days
• Divide velocity by load factor
• Commit to this amount of work per iteration
• After iteration, divide real time spent by ideal time estimated to get new load factor

Pair programming

• You probably noticed there’s only half as many computers as people...
• XP advises pair programming

Advantages

• Problems are solved much faster by 2 people
• Most trivial but annoying mistakes are caught immediately
• People learn from their partner
• coding techniques
• new parts of the system

Roles in a pair

• Typically, programmers take it in turns
• One codes or writes tests
• The other watches for mistakes, gives advice or thinks about the bigger picture
• They often talk about what they are working on and the next step they will take
• Is this what you’re experiencing?

Automated testing

• Testing is important in ensuring software is reasonably reliable
• If you release frequently a manual testing phase is a serious overhead
• In some scenarios it is difficult to reproduce test cases by hand
• Better to automate your tests and run them regularly (even almost continuously)

Simple design

• What’s the simplest thing that could possibly work?
• 90% of the time this is all you need
• It is easier to add complexity than to take it away
• Problems become more clear-cut when you already have a partial solution

Coding standards

• The code is the only guaranteed-correct documentation for a system
• You may have other documents and comments, but:
• these can get out of date
• they can become misleading

Refactoring

• Changing the way code is written / structured without changing what it does
• Enables
• readability improvements
• restructuring for testing
• just-in-time design
• Use tests to back up refactoring steps

40-hour week

• Don’t work more than a 40-hour week
• Long hours make more productivity only for a very short time
• System quality suffers a lot through long hours over long periods
• In XP, you go fast by maintaining the quality & fluidity of system

Practice interactions