Pair Programming XP Rule of Thumb “When something is difficult or painful, do it more often until it becomes easier.”

Download Report

Transcript Pair Programming XP Rule of Thumb “When something is difficult or painful, do it more often until it becomes easier.”

Pair Programming
XP Rule of Thumb
“When something is difficult or painful, do it
more often until it becomes easier.”
Roles
• Driver
▫ Controls mouse and keyboard
• Navigator/Observer
▫ Actively reads and reviews code while it is being
written
▫ Thinks about the bigger picture
▫ Provides strategic direction
▫ Help ensure quality and minimise defects
• Switch frequently
Rules
• All production code must be developed by a pair
▫ Conversely, this means that are plenty of other
activities that you can undertake in the absence of a
pair.
• It's not one person doing all the work and another
watching
▫ Keyboard should be moving back and forth between
the two participants several times an hour
• Don’t pair for more than 75% of the day
• Switch pairs frequently
▫ At least daily
Start with a defined task
• The task should be something you are confident
that you can complete in an hour or two
Agree on one tiny goal at a time
• Something you can complete in minutes
• Ping pong with red, green, refactor works well
Talk lots!
• When people are pairing well, they are
talking back and forth almost non-stop.
• Stating the problem in words to another
person helps focus your mind and helps
engage your partner's mind. It also ensures
that you both know what you are working
on right now.
• Here are some common things to say while
pairing:
▫
▫
▫
▫
Do you think this is a valid test?
Does that look correct to you?
What’s next?
Trust me (when writing code to illustrate
your point rather than trying to explain)
Rely on and support
your partner
• Driver
▫ Complete current goal (tiny task) as quickly as possible
▫ Trust the observer to notice larger issues
• Observer
▫ Pay attention
▫ Think about possible bugs, larger issues, and ways to
simplify or improve the design.
▫ Bring up errors and code that you find unreadable
right away.
▫ Bring up larger issues and ideas for design
improvement after the driver is done.
▫ Jot later tasks down so that driver can stay focused.
Sync frequently
• It is normal to get out of sync
▫ Be unsure of what your partner is doing
▫ Be unclear on the current (tiny) task
• When it happens, TALK and sync up again
Celebrate
• Celebrate completed tasks and overcome
problems, e.g.
▫ High five when a test passes
▫ High five when you write failing test
Switch roles often
• At least every half an hour
Suggested:
1. Driver writes failing test
2. Switch roles
3. New driver writes code to
help test pass
4. Chat about what can be
refactored and make
changes together
5. Driver writes next failing
test
6. Switch roles
7. Loop