Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
se:extremeprogramming [2010-05-31 17:07] stefan |
se:extremeprogramming [2014-04-05 11:42] (aktuell) |
||
---|---|---|---|
Zeile 65: | Zeile 65: | ||
- Planung der nächsten Iteration bzw. des nächsten Releases | - Planung der nächsten Iteration bzw. des nächsten Releases | ||
- | ===== Pair Programming ===== | ||
- | **nach \cite{Haase2006}** | ||
- | * Ziele: Global Code Ownership, Mentoring/Training, höhere Codequalität | ||
- | * Regeln/Voraussetzungen | ||
- | * die Teilnehmer sollten das Keyboard alle 10-15 Minuten austauschen | ||
- | * die Sessions sollten nicht zu lange dauern (max. 3-4 Stunden) | ||
- | * beide Partner sollten ungefähr auf dem gleichen Wissensstand/Skilllevel sein | ||
- | * Möglichkeit/Gelegenheit, Pair Programming "einzuführen": bei auftretenden Bugs in vorhandenem Code, den Kollegen, der diesen Code geschrieben hat, bitten, mit ihm gemeinsam den Bug zu fixen. So verteilt sich Code Ownership auf beide Kollegen. | ||
- | |||
- | ==== Vorteile von Pair Programming ==== | ||
- | **nach \cite[S. 319]{Goodliffe2006}** | ||
- | * Wissenstransfer zwischen Entwicklern | ||
- | * zentriert den Fokus auf das Entwickeln (und vermeidet Tagträume) | ||
- | * erhöht die Disziplin | ||
- | * vermindert die Unterbrechungshäufigkeit (man stört zwei Personen, die arbeiten nicht so gerne, wie eine einzelne) | ||
- | * quasi "Echtzeit-Reviews" -> besserer Code als Ergebnis | ||
- | * sozialer Faktor: die Entwickler lernen sich besser kennen und das fördert die Moral | ||
- | * Collective Code Ownership | ||
- | * verteilt gute Codepraktiken und -standards unter den Entwicklern | ||
- | * unterstreicht den Entwicklungsprozess | ||