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 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
- 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
- You probably noticed there’s only half as many computers as people...
- XP advises pair programming
- 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
- 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?
- 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)
- 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
- 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
- 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
- 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
