Zielsetzung

• Ständiges Review von Code und Design
• Verbreitung der Wissensbasis im gesamten Team

Fahrer und Navigator (Driver and Navigator) ist eine Metapher, bei der die Insassen eines Fahrzeuges für das gemeinsame Erreichen eines Zieles stehen, wobei der Fahrer aktiv das Fahzeug lenkt und der Navigator ihn dabei unterstützt.

Programmierpaare bilden sich je nach Lust und Bedürfnissen meist mehrmals täglich neu.

Gute Gelegenheiten, den ProgrammierPartner zu wechseln:

• eine Aufgabe wurde abgeschlossen
• Hilfe von einer anderen Person wird benötigt
• der momentane Partner geht mir langsam auf den Keks
• regelmäßige Zeitintervalle (alle 60 Minuten suche ich mir einen neuen Partner)

• BesprechungenImStehen sind eine gute Gelegenheit, passende Partner für anstehende Aufgaben zu finden
• eine OffeneArbeitsumgebung hilft dabei, die Paarzusammensetzung dynamisch zu halten
• ProgrammierStandards klären Stilfragen zwischen den Partnern

Innerhalb weniger Tage habe ich mich so sehr an das ProgrammierenInPaaren gewöhnt, dass ich mir zu Beginn der Aufgabe, die ich als nächstes allein zu bewältigen hatte, vollkommen verloren fühlte. Es zogen bestimmt ein, zwei Stunden ins Land bis ich wieder 'auf mich allein gestellt' freiauf entwickeln konnte. Seitdem ich diese Technik verstärkt verwende, stelle ich darüber hinaus ein chronische Unlust fest - insbesondere Designentscheidungen - allein treffen zu müssen. Es geht zu zweit weit mehr als doppelt so schnell und liefert obendrein noch ein befriedigenderes Ergebnis. Warum also sich allein 'abmühen'? -- SandraSieroux?

Zudem macht ProgrammierenInPaaren mindestens doppelt so viel Spaß! :-) -- IljaPreuß

Zumindest beim DesignInPaaren? stimm ich Dir voll zu ... will ich nicht mehr missen. Aber ProgrammierenInPaaren iss mir bei Trivialproblemen dann doch zu oede. -jerger@jerger.org-

Wie schon an anderer Stelle erwähnt: Wenn der Partner anfängt zu gähnen, ist das meines Erachtens meist ein Zeichen dafür, dass man lieber etwas automatisieren sollte...

Zudem - wenn man TestgetriebenesDesign praktiziert (wie in ExtremeProgramming), dann gibt es gar keine zeitliche Trennung mehr zwischen Designen und Programmieren. -- ip

Ist es tatsächlich möglich - wie oben beschrieben - mehrmals täglich den Partner zu wechseln? Dies würde doch bedeuten, dass zumindest 2 Paare einigermassen gleichzeitig ihre aktuelle Arbeit beenden. Das scheint mir ein ziemlich großer Zufall.

Ich kann (leider) nicht mit Erfahrung in dieser Hinsicht aufwarten, möchte aber dennoch zwei Punkte zu bedenken geben:

In einem Projekt gibt es meistens auch andere Dinge zu tun als Produktionscode zu schreiben, so dass nicht jeder Entwickler zu jedem Zeitpunkt zwangsweise einen Partner benötigt.

Durch FortlaufendeIntegration kann ich zu sehr vielen Zeitpunkten den Partner wechseln, auch 'mitten in einem Task'. Unter Umständen ist ein neuer Partner, dem ich ersteinmal den aktuellen Stand erklären muss, durch seine neue Sichtweise sogar hilfreicher als jemand, der durch die gemeinsame Arbeit bereits in den selben Schienen denkt wie ich. -- ip

''schaut Euch mal das an: WardsWiki:TriProgramming Hab ich den Witz nicht verstanden, oder ist das eine ernsthafte Diskussion? --jd''

Ich glaube, das ist zu 80% Ernst! -- hl

Was an der Diskussion macht den Eindruck, es könnte nicht ernst gemeint sein? -- IljaPreuß

Vielleicht die Einleitung "...who have tried ... report ... pairing is better..." in der Nebenbedeutung "...sich zu Paaren..." gefolgt von einigen flachgründigen Argumenten: "body space", "less boring", "Astaire and Rogers"... -- hl

• WardsWiki:PairProgramming
• WardsWiki:PairProgrammingTipsAndTricks
• http://pairprogramming.com
• The Costs and Benefits of Pair Programming, http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
• The Joel on Software Forum: Pair Programming successes and failures (JoelSpolsky)