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.
    

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

nach \cite[45:00]{Haines2009}

• kontinuierliches Code-Review
• man muss zwei Leute überzeugen, wenn man Schrott programmieren will
• langweilige Aufgaben werden interessanter
• schwierige Aufgaben werden leichter
• weniger Fehler im Code
• Code kann schneller in Produktion gehen
• saubererer Code
• zwei Leute "kennen" den Code → Truck Factor

nach \cite[50:00]{Haines2009}

• "Das Management will kein Pair Programming!" → Das ist keine Ausrede! Wir als Entwickler sind verantwortlich für guten Code und müssen/dürfen entscheiden, wie dieser erstellt wird. Wir schreiben den Managern auch nicht vor, wie sie ihre Diagramme zeichnen sollen. Wer PP will, wird einen Weg finden, z.B. zwei Wochen lang ausprobieren und Management die Ergebnisse in Zahlen vorlegen, oder einfach den Job wechseln.