Benutzer-Werkzeuge
se:pairprogramming
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
|
se:pairprogramming [2010-07-26 12:32] stefan |
se:pairprogramming [2014-04-05 11:42] |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== 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 | ||
| - | * jeder Partner bekommt eine "rote Karte", die er ziehen kann, wenn er meint, dass gerade etwas passiert, das fachlich oder persönlich nicht tragbar ist ([[http://igloocoder.com/archive/2007/05/18/1215.aspx|IglooCoder]]) | ||
| - | * 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 | ||
| - | |||
| - | **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 | ||
| - | |||
| - | ===== Gründe gegen Pair Programming ===== | ||
| - | **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. | ||
se/pairprogramming.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
