Inhalt	Abbildung	PDF	Source	Projektmanagement
\|<	<	>	>\|	Generated by CoCoDiL

2.9 Pair Programming und Collective Code Ownership

2.9.1 Was ist Pair Programming?

Aus der Homepage von * Frank Westphal:

Die Regel lautet: Wer um Hilfe bittet, dem wird Hilfe geboten. Tatsächlich wird keine Zeile Produktionscode geschrieben, ohne daß zwei Paar Augen auf den Bildschirm gerichtet sind. Das bedeutet, Sie programmieren zu zweit an einem Rechnern mit einer Tastatur und einer Maus. Sie sitzen nebeneinander, führen ein intensives Gespräch über den entstehenden Code und wechseln sich regelmässig an der Tastatur ab. Sie dürfen dabei sogar Spaß haben, denn Programmieren soll Spaß bringen. Sie wechseln häufiger Ihre Programmierpartner und am Ende der Woche haben Sie idealerweise mal mit jedem Ihrer Kollegen zusammengearbeitet, damit sich das aufgebaute Wissen über das gesamte Team verbreitet.

Bemerkungen:

Ich habe Erfahrung mit wöchentlichen Tausch des Partners gemacht. Die Dauer der sinnvollen Zusammenarbeit hängt davon ab, wie stark die Aufgaben in Teilaufgaben gebrochen werden können.
Die Programmierer einigen sich selber darauf wer mit wem zusammenarbeitet.
Pair-Programming ist i.a. anstrengender als alleine zu programmieren, macht aber mehr Spass. Die meisten die es ausprobiert haben, wollen es nicht mehr missen.
Durch Pair Programming eignet sich der einzelne Programmierer sehr schnell Wissen an.

2.9.2 Was ist Collective Code Ownership

Der gesamte Code gehört dem Team. Jedes Paar soll jede Möglichkeit zur Codeverbesserung jederzeit wahrnehmen. Das ist kein Recht sondern eine Pflicht. Da die Funktionalitaet mit automatisierten Tests abgedeckt ist, ist die Gefahr dass das Programm bei der Codeverbesserung zerstört wird, gering. Eine weitere Sicherheit ergibt sich durch die Versionierung von Code.

Collective Code Ownership hilft den Code so zu schreiben, dass er selbst kommentierend ist.

2.9.3 Gefährlichkeit von genialen Lösungen

Ich habe in einige Projekte Entwickler getroffen, die sehr schnell und auch fehlerfrei entwickelten. Oft haben gerade diese Leute dem Projekt mehr geschadet als genutzt.

Diese Entwickler haben oft die existierenden Frameworks nicht benutzt, und "by the fly" eigene entwickelt.
Management Fehler sind oft überdeckt worden. Da die Anforderung unklar sind, verwenden diese Entwickler oft "Goldrandloesungen"
Der Erfolg von einem Projekt hängt von wenigen Mitarbeitern ab. Ein Projekt sollte immer in einem Zustand sein, dass jeder Mitarbeiter austauschbar ist.
Der Code ist von weniger genialen Mitarbeiter schwer zu warten

Die Loesungen von heute, sind oft die Probleme von morgen

2.9.4 Vorteile Pair Programming und Collective Code Ownership

schnelle Wissensverbreitung
hoher Lernfaktor
geringer Frustrationsfaktor (Never walk alone gegen Jeder wurschtelt alleine fuer sich rum).
gleichmaessigere Auslastung

2.9.5 Wissenschaftliche Studien

Pair Programming kann auch ausserhalb von Extreme Programming angewendet werden. Es gibt einige Forschungsarbeiten, die den Erfolg von Pair Programming beweisen.

Diese Forschungsarbeiten sind * hier veroeffentlicht.

Siehe speziell auch den Artikel von Laurie Williams und Alistair Cockburn * The Costs and Benefits of Pair Programming

Geringere Abhängigkeiten von einzelnen Mitarbeitern.
Möglichkeiten in Urlaub zu gehen.
Synergieeffekte nutzen (Ein ähnliches Problem hatten wir ja schon gelöst)

Inhalt	Abbildung	PDF	Source	Projektmanagement
\|<	<	>	>\|	Generated by CoCoDiL