$KK(Pair Programming und Collective Code Ownership)

$KKK(Was ist Pair Programming?)



Aus der Homepage von [e|Frank Westphal>www.frankwestphal.de]:



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.



<b>Bemerkungen:</b>



* 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.



$KKK(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.



$KKK(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 



<b>Die Loesungen von heute, sind oft die Probleme von morgen</b> 



$KKK(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 



$KKK(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 [e|hier > http://www.pairprogramming.com ] veroeffentlicht. 



Siehe speziell auch den Artikel von Laurie Williams und Alistair 

Cockburn [e|The Costs and Benefits of Pair Programming > http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF]



* Geringere Abhängigkeiten von einzelnen Mitarbeitern. 

* Möglichkeiten in Urlaub zu gehen. 

* Synergieeffekte nutzen (Ein ähnliches Problem hatten wir ja schon gelöst)