„Paarprogrammierung“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
K r2.7.3) (Bot: Ändere it:Programmazione di coppia zu it:Pair programming |
Keine Bearbeitungszusammenfassung |
||
| Zeile 8: | Zeile 8: | ||
== Positive Effekte == |
== Positive Effekte == |
||
{{Quelle}} |
|||
; Höhere Disziplin |
; Höhere Disziplin |
||
: Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen. |
: Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen. |
||
Version vom 22. Februar 2013, 17:34 Uhr
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
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
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
- 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.
- Verbreitung von Projektwissen
- 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.
- Mentoring
- 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
- Kosten
- Da sich Vorteile wie gesteigerte Qualität teils erst in späteren Phasen des Produktlebenszyklus bemerkbar machen, sind in der ursprünglichen Entwicklungsphase die Kosten durch die doppelte Besetzung meist höher, was sich aber dadurch ausgleicht, dass der produzierte Code weniger Fehler enthält, die später aufwändig gesucht werden müssen.
- Teamfindung
- Teamfindung ist aufwendig, nicht alle Personen können miteinander produktiv eingesetzt werden. Eingewöhnung der Teammitglieder erfordert Zeit.
- Autoritätsproblem
- Wer hat die Kompetenz, bei konträren Problemlösungen zu entscheiden, welche implementiert wird?
- Zeitliche Belastungen
- Wenn zusätzliche Aufgaben wie Mentoring während der Programmierung wahrgenommen werden müssen, kann es zu Verzögerungen in der Entwicklung kommen. Die Teilnehmer müssen sich an unterschiedliche Programmierfähigkeiten und -stile gewöhnen.
- Urheberrecht
- Es kann zu Konflikten kommen, da später nicht unbedingt klar ist, wer Urheber der einzelnen Passagen des Codes ist.
- Haftung
- Es kann zu Konflikten kommen, da später nicht unbedingt klar ist, wer für fehlerhaften oder urheberrechtsverletzenden Code haftet.
- Teamgröße
- Bei steigender Zahl von Programmierern wird es schwieriger zu kommunizieren, wie Probleme zu lösen sind. Deshalb ist diese Arbeitsweise eher für kleinere Teams geeignet.
- Arbeitsaufkommen
- Je mehr verschiedenartige Aufgaben zu bewältigen sind, desto mehr muss der Programmierer wissen.
Produktivität
Befürworter der Paarprogrammierung behaupten, dass die Produktivität durch diese Vorgehensweise nicht sinke, sondern im Gegenteil sogar steige. Voraussetzung sei allerdings, dass die fachliche Kompetenz der Partner nicht zu sehr abweicht.
Verteilte Paarprogrammierung
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 Sangam[2], Saros[3] und XPairtise[4].
Quellen
- ↑ Kent Beck: Extreme Programming Explained. Embrace Change. 2. Auflage. Addison-Wesley Longman, Amsterdam 2004, ISBN 978-0-321-27865-4, Kap. 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?").
- ↑ Sangam Webseite
- ↑ Arbeitsgruppe Software Engineering, FU Berlin: Saros - Distributed Collaborative Editing and Pair Programming (Webseite)
- ↑ The XPairtise Team: XPairtise - A Distributed Pair Programming Plug-in For Eclipse, (Webseite)
Literatur
- Laurie Williams: The Collaborative Software Process (PDF, Englisch)
- Tilman Walther: Pair Programming (PDF)
- Chih-wei Ho et al.: Sangam - A Distributed Pair Programming Plug-in for Eclipse (PDF, 200KB)