Paarprogrammierung

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Paarprogrammierung

Bei Paarprogrammierung (engl. Pair Programming) handelt es sich um eine Arbeitstechnik, die sich häufig bei agilen Vorgehensweisen zur Softwareentwicklung findet. So ist Paarprogrammierung beispielsweise ein wichtiger Bestandteil von Extreme Programming (XP).

Beschreibung[Bearbeiten]

Paarprogrammierung bedeutet, dass bei der Erstellung des Quellcodes jeweils zwei Programmierer an einem Rechner arbeiten. Ein Programmierer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, sofort anspricht.[1] Diese können dann sofort (im Gespräch zu zweit) gelöst werden. Die beiden Programmierer sollten sich bezüglich dieser beiden Rollen abwechseln. Auch die Zusammensetzung der Paare sollte sich häufig ändern.

Ziele[Bearbeiten]

Zunächst soll Paarprogrammierung die Softwarequalität steigern. Durch die Kontrollfunktion der zweiten Person sollen problematische Lösungen vermieden werden. Die Paarprogrammierung dient aber auch zur Verbreitung von Wissen über den Quellcode. Durch das regelmäßige Rotieren der Partner kann immer der jeweils neue Partner durch Learning by Doing etwas über die bearbeiteten Quelltexte lernen.

Positive Effekte[Bearbeiten]

Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Die fraglichen Angaben werden daher möglicherweise demnächst entfernt. Bitte hilf der Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Näheres ist eventuell auf der Diskussionsseite oder in der Versionsgeschichte angegeben. Bitte entferne zuletzt diese Warnmarkierung.
Weniger Fehler
Paarprogrammierung führt zu weniger Fehlern und somit zu weniger Fehlerbehebungsaufwänden. Üblicherweise rechnet man bei Paarprogrammierung mit 15% weniger Fehlern als bei herkömmlicher Programmierung.[2]
Kleinere Programme
Paarprogrammierung führt im Schnitt zu um 20% kleineren Programmen.[2]
Höhere Disziplin
Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen.
Besserer Code
Bei der Paarprogrammierung entwickelt man sich weniger leicht in Sackgassen und erreicht so eine höhere Qualität.
Belastbarerer Flow
Paarprogrammierung führt zwar zu einer anderen Art von Flow, ermöglicht diesen aber eher als der konventionelle Ansatz: Ein Programmierer kann seinen Partner jederzeit nach dem aktuellen Stand fragen und dort anknüpfen. Unterbrechungen werden auf diese Art besser abgewehrt.
Freude an der Arbeit
Paarprogrammierung ist oft spannender und interessanter als alleine zu arbeiten. 90% der Entwickler, die Paarprogrammierung betreiben sprechen von einer erfreulicheren Arbeit.[2]
Geringeres Risiko
Wenn das gesamte Projektteam mit der Methode Paarprogrammierung arbeitet und die jeweiligen Partner oft wechseln, erlangen alle Wissen über die gesamte Codebasis. Dies wiederum führt zu einem geringeren Projektrisiko hinsichtlich Mitarbeiterfluktuation und Mitarbeiterabwesenheiten. Es erhöht somit die Truck Number.
Wissensvermittlung
Jeder hat Wissen, das andere nicht haben. Paarprogrammierung ist eine Möglichkeit, dieses Wissen zu verteilen.
Teambildung
Die Leute lernen sich gegenseitig schneller kennen, wodurch die Zusammenarbeit verbessert werden kann.
Weniger Unterbrechungen
Paare werden seltener unterbrochen als jemand, der alleine arbeitet.

Nachteile[Bearbeiten]

Kosten
Paarprogrammierung führt zu einer geringeren Geschwindigkeit bei der Programmierung. Üblicherweise geht man davon aus, dass ein Paar um 15% weniger als doppelt so schnell eine Aufgabe umsetzt - das entspricht einer um 7,5% geringeren Produktivität in der Programmierung.[2] Da sich Vorteile wie gesteigerte technische und fachliche Qualität bereits während der Entwicklung und insbesondere im Test auswirken, werden diese Produktivitätseinbußen zumindest abgeschwächt, oft aber auch mehr als wettgemacht.
Teamfindung
Teamfindung kann aufwendig sein, wenn nicht alle Personen miteinander produktiv arbeiten können. Eingewöhnung der Teammitglieder kann Zeit erfordern.
Unterschiedliche Programmierstile
Eine Voraussetzung für Paarprogrammierung sind ein gemeinsam vereinbarter Programmierstil des gesamten Teams.
Urheberrecht
Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken, das Urheberrecht nicht für einzelne Personen angewandt werden.
Haftung
Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken zu Konflikten kommen, da später nicht unbedingt klar ist, wer für fehlerhaften oder urheberrechtsverletzenden Code haftet.

Produktivität[Bearbeiten]

Befürworter der Paarprogrammierung behaupten, dass die Produktivität durch diese Vorgehensweise nicht sinke, sondern im Gegenteil sogar deutlich steige. Grund dafür sei, dass die durch Paarprogrammierung gesteigerte technische und fachliche Qualität genau dort die Produktivität erhöhen, wo während der Softwareentwicklung am meisten Zeit verbracht wird: Beim Fehlerfinden und -beheben, sowie beim Lesen von Code. Üblicherweise geht man davon aus, dass Fehler, die erst im Test gefunden werden 10x so teuer in der Behebung sind, wie wenn sie bereits während der Entwicklung gefunden werden.

Voraussetzung für hohe Produktivitätssteigerungen durch Paarprogrammierung ist allerdings, dass die fachliche Kompetenz der Partner nicht zu sehr voneinander abweicht.

Verteilte Paarprogrammierung[Bearbeiten]

Verteilte Paarprogrammierung (Distributed Pair Programming, DPP) ist die softwaregestützte Durchführung von Paarprogrammierung an getrennten Computern beispielsweise an unterschiedlichen Orten. Bekannte Werkzeuge für DPP sind Saros[3] und XPairtise[4].

Quellen[Bearbeiten]

  1.  Kent Beck: Extreme Programming Explained. Embrace Change. 2 Auflage. Addison-Wesley Longman, Amsterdam 16. November 2004, ISBN 978-0321278654, 10, S. 58 ("There are two roles in each pair. One partner, the one with the keybaord and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically: Is this whole approach going to work? Wht are some other test cases that might not work yet? Is there some way to simplify the whole system so the current problem just dissappears?").
  2. a b c d  Alistair Cockburn, Laurie Williams: The Costs and Benefits of Pair Programming. In: University of Utah Computer Science (Hrsg.): Extreme programming examined. Addison-Wesley, 2001, ISBN 0-201-71040-4, S. 223 - 243 (http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF, abgerufen am 10. November 2013).
  3. Arbeitsgruppe Software Engineering, FU Berlin: Saros - Distributed Collaborative Editing and Pair Programming (Webseite)
  4. The XPairtise Team: XPairtise - A Distributed Pair Programming Plug-in For Eclipse, (Webseite)

Literatur[Bearbeiten]