Brengt pair programming nu op of niet? Beter met 2 of alleen...

1. Pair Programming
1+1=3?

2. Disclaimer !
 Opgelet: voor U staat GEEN Agile Goeroe
 1 jaar intensief pair-programming achter de rug
 Geëvolueerd van “hater” naar “believer”
Page  2

3. Misverstand #1
 “Pair Programming dient om juniors op te leiden”
- Pair Programming is geen opleidingstool
- Wie zegt dat je zelf geen fouten maakt?
- Wie zegt dat je zelf alles 100% begrepen hebt?
- Ook experts moeten hun kennis onderling delen
Page  3

4. Misverstand #2
 “Pair programming is duur”
 “Waarom zou ik 2 mensen het werk van 1 persoon laten doen?”
- Hoe beter de programmeur, hoe duurder de bugs die hij schrijft
- (functionele bugs worden veel later in het proces ontdekt dan bv compilatiefouten)
- Doordat pairs meer overleggen, wordt ook de requirement nog eens herkauwd
en de implementatie is meer doordacht
- De kennis geraakt wijder verspreid, dus het onderhoud wordt goedkoper
- Een pair neemt veel minder technische short-cuts
Page  4

5. Misverstand #3
 “Pair programming is niks voor mij”
 “Het zou niet werken bij ons”
 “Ik kan me zo lang niet concentreren”
- Pair programming levert hogere kwaliteit, de prijs is comfort
- Moeilijk in het begin maar het went snel
- Ping-Pong (zie later) zorgt voor afwisseling
Page  5

6. Misverstand #4
 “We hebben onze manier van werken, het omgooien is te veel werk”
- Geleidelijk invoeren is perfect mogelijk
- Bv per week “pairt” iedereen minstens 1 dag
- “Pair-modeling” en “Pair-reviewing”
- Enkel refactoring per twee, bv 1 dag per sprint
Page  6

7. Wat werkt?
 Overleg
- Geen letter tikken voor de functionaliteit en de geplande implementatie in detail
begrepen zijn
 Ping pong
- Persoon A schrijft eerst unit test
- Persoon B implementeerd
 Babystapjes
- Van stabiel punt naar stabiel punt
Page  7

8. Wat werkt niet?
 Keyboard hugging
- Het toetsenbord moet vaak van eigenaar veranderen
 Dictator
- Elke mening moet tellen
 Dromer
- Beide developers moeten bij de les zijn
- Spreek pauzes af als het moeilijk wordt
 Purist
- Implementeer zware refactorings in een eigen story
- Gebruik het als leermiddel voor de groep
- Beperk kleine refactorings tot de code in story-scope
Page  8

9. Conclusie
 1 + 1 = 3 of 0
- Pair programming kan een bonus zijn als iedereen de focus op kwaliteit heeft
 Continu bijschaven
- Geen 2 teams zijn gelijk
- Meten = Weten
Page  9