Paar-Programmierung

The Social Dynamics of Pair Programming

  • naturalistisch Studie, Professionelle Entwickler, 2 Teams (Startups, ungleich), 4 Monate, ~40h Verhaltensaufzeichnungen, 32 Besuche, Sitzung 1.5-3h
  • Team 1: Januar 2004, 6 + 3, duale Ausstattung, Juni - September, Erfahrung ~ gleich
  • Team 2: Anfang 2002, 9 + 1, nicht duale Ausstattung, Mai - August, 3 Monate - 20 Jahre Erfahrung
  • kein "driver - navigator" (dn) (schnelle Tastaturwechsel, duale Tastaturen / Mäuse), Erfahrung stark unterschiedlich
  • Ergebnisse
    • gleiches Verständnis --> dn (sonst selbes Abstraktionsniveau)
    • geteilter Kontext: nur kurz, kurze Sätze
    • duale Ausstattung --> aktivere Teilnahme
    • sver. Erfahrung --> Erfahrener dominiert Interaktion (Unerfahrener wird passiv --> kein Wissenstransfer)
    • "driver" macht kleine Entscheidungen (größere gemeinsam)
  • Gültigkeitsbedrohungen
    • intern: Erfahrung Team A?, PP nicht alleine (sondern mit anderen XP Praktiken),
    • extern: naturalistisch, nur 2 Teams

Are Reviews an Alternative to Pair Programming

  • gegenbalancierter Entwurf, 2 Experimente, 38 Studenten (19 PP, 23 Review Datenpunkte), keine Langzeiteffekte (Wissenstransfer, ...), Teil des XP-Kurs, Mai - Juni 2002, durchschn. 6 Jahre Programmiererfahrung, Java
  • Hypothesen: 1. Zuverlässigkeit 2. Aufwand (Paarprogrammierer = Entwickler + Review)
  • Ablauf Review: vorher nur Kompilierfehler, kein Ausführen, Review = Checkliste, nach Review: anfangen zu testen (Reviewer anonym)
  • Ablauf: Implementierung (Review oder PP) > Qualitätssicherung (großer Test + Akzeptanztest (95% Grenze, feste Untermenge des großen Tests)) > Fragebogen
  • Aufgaben: Polynomial, Shuffle-Puzzle
  • Gruppenaufteilung: Programmiererfahrung gleichmäßig aufgeteilt
  • Unterschiede Exp02 - Exp03: einer nur Review, einer nur Implementierung
  • Ergebnisse
    • Korrektheit: PP nach Implementierung (ohne QS) tendenziell besser (nicht signifikant)
    • Kosten: gesamt: PP etwas teurer bei vergleichbarer Qualität, nach IMP: PP teurer aber auch korrekter (nicht signifikant)
    • Schlussfolgerung: Reviews ungefähr selbe Qualität mit selben Kosten
  • Gültigkeitsbedrohungen
    • intern: müssen teilnehmen? Reviews vom Autor vorgestellt, gezwungen nur eine Methode?, geringe Güte (0.6), Review anderer gibt Hinweise, keine Rücksprache zu Reviewer, Teilnehmer bevorzugen PP, nicht verwertbare Datenpunkte
    • extern: keine Erfahrung, Studenten, kannten sich nicht, Zuteilung nicht randomisiert, Aufgaben komplexer als "tägliche", keine Ausführung

Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise

  • Motivation: widersprüchliche Aussagen über PP (Dauer, Aufwand, Korrektheit) + nicht vergleichbar
  • Quasi-Experiment (kombiniert 2x2x3 faktoriell), 2 Phasen (1: 2001, nur Individueen), 2: 2004-05, nur Paare), 98 Paare / 99 Individuuen (professionelle Java-Entwickler, Einteilung durch Informationen des Arbeitgebers), ver. Länder + ver. Firmen, Vortests (Fragebogen, Aufgabe), sehr realistisch (Bezahlung, ...)
  • unabh. Variablen: Programmiertechnik, Systemkomplexität, Programmierkompetenz
  • abh. Variablen: Dauer, Aufwand, Korrektheit
  • kontrollierte Faktoren: PP oder alleine, Kontrollstil (zentralisiert oder delegiert), Programmiererkategorie (Junior - Senior)
  • Modellspez.: GLM + ANCOVA (da Quasi-Experiment)
  • PP: selbes Skill-Level, unbekannte Partner (aber selbe Firma)
  • Aufgaben: Training, Vortest (immer alleine), 4 inkrementelle Hauptaufgaben (Kaffeemachine, letzte Aufgabe nicht in Analyse, Dauer ca. 8h, 5. unbewertet)
  • Ergebnisse (nur 139 Datenpunkte, da andere nicht korrekt)
    • Dauer: CC: PP schneller, DC: Individueen schneller --> PP abh. von Systemkomplexität
    • Aufwand: PP viel mehr Aufwand, --> PP abh. von Systemkomplexität
    • Korrektheit: CC: Individueen korrekter, DC: PP korrekter --> PP abh. von Systemkomplexität
    • Fazit: Systemkomplexität ist Vermittlereffekt, PP effektiv für Anfänger / ineffektiv für Fortgeschrittene
  • Gültigkeitsbedrohungen
    • intern: nicht randomisierte Gruppenzuteilung, ver. Entwicklertools, nur korrekte Lösungen ausgewertet, keine Erfahrung
    • extern: kleines System, kurze Aufgaben, nur Erweiterungsaufgaben
    • Konstrukt: nur homogene Paare, Zuweisung der Expertise durch Firma, Komplexität (zentral komplexer als delegiert?), nur funktionale Korrektheit
    • statistisch: Ergebnisse mit α=0.1\alpha = 0.1