Arbeitsanweisung pseudo-pair-programming

[kartoffelsack]

Hab mal unserem Projektleiter vorgeschlagen, ob wir bei unserem nächsten größeren Projekt nicht mal ne abgeschwächte Form des Pair-programmings einführen sollten.

Damit Ihr kapiert, was ich meine, folgender Hintergrund:
"Projekt" ist bei uns eigentlich immer ein konklomerat aus ner Menge einzelner Programme (von Wep-Apps über Steuerungen) die's entweder schon gibt, oder komplett neu geschrieben werden müssen oder aus Programmen anderer Projekte zusammengeschustert werden.
Diese einzelen Programme sind meistens nicht soo groß (was an sich ja ein ganz gutes Desingmerkmal ist) haben recht getrennte Aufgabenbereiche und es ist immer ein einzelner Entwickler komplett dafür zuständig. Der sitzt da von 1 bis 6 Mann-Monaten dran und muss sich nur da, wo er irgendwie mit anderen Proggies zusammenarbeitet mit den anderen abstimmen. Das was das Programm genau zu tun hat, ist mehr oder weniger(!) genau festgelegt und wie man das implementiert ist dem entwickler ziehmlich selber überlassen. Letzteres klingt ansich nach nem Traum, nur haben wir z.T. mit extremen Qualitätsproblemen zu kämpfen. Diese sind zwar schon zu einem Großteil auf höherer Ebene anzusetzen, aber auch die Implementierung trägt Ihr scherflein dazu bei. Dazu kommt, dass man bei uns fast nicht mehr in Urlaub kommt, weil jeder soviel Exklusivwissen hortet (horten muss).

Deswegen hab ich vorgeschlagen, ob mans nicht so machen könnte: Immer zwei Entwickler (auch bei den kleinen Sachen). Diese sitzen zwar nicht zusammen an einem Compi aber sie entwickeln an einem einzigen Programm. Das Erzwingt dann dass man bevor man mit der tipperei anfängt, wirklich die Software durchdesigned, die Schnittstellen festlegt etc.

Ja. Nun fangen wir mit nem neuen Projekt an und der Projektleiter ist tatsächlich auf mich zugekommen. Ich soll mal bis nächste so ne Art kurze Arbeitsanweisung schreiben, wie man das jetzt genau machen sollte etc.

Deswegen bitte ich Euch, mal meinen ersten stichwortartigen, unformulierten und deutschfehlerbehafteten Grobentwurf durchzulesen und mir Eure Meinung/Kritiken und Vorschläge dazu sagen.

thnx

*Begriffsdefinition:

Code-Project (im weiteren auch einfach Projekt):
Programmeinheit in größerem Projekt entspricht 'Projekt' in einer Entwicklungsumgebung.

Vertikales Aufteilen (nach Funktionalität) eines Projests in möglichst unabhängige Units
direkt oberhalb der Klassenebene.

Vor Beginn der Implementation gemeinsames Festlegen der öffentlichen Schnittstellen
der Hauptelemente der Units (v.a. Klassen) nach Möglichkeit direkt mit entsprechenden
UML-Tools.

Festlegung der Zuständigkeit des einzelnen Programmierers. Möglichst deckend mit den
identifizierten Units, je nach eingeplanten Zeitresourcen, evtl. getrennt nach
Aufgabenbereichen.

Implementation (bzw. automatische Generierung bei Verwendung von UML-Tools) der
Schnittstellen (Codegerüst). Je nach Möglichkeit der Programmiersprache in compilierbarer
Form (C++: Headerdateien, Delphi: Interfaces und leere Funktionsrümpfe, Java: Funktionsrüpfe
mit entsprechden Dummy-Rückgabe, etc.).

Implementation der Units durch einzelnenen Programmier in möglichst enger Koordination um
gleichzeitig zusammengehörige Units fertigzustellen und einbauen zu können.

Implementation von unten nach oben, d.h. beginnend bei den Teilen, die am wenigsten abhängig
von anderen Units sind.

Gemeinsames benutzen von bei der Implementierung entstehender Hilfsklassen etc..

Bei Bedarf enge Absprache auch über Implementierungsdetails.

Implementation mit gleichzeitiger Erstellung von Testcode (Unit-Testing).

Feststellen der Funktionalität durch durch fehlerfreies durchlaufen des Unit-Tests.

Zusammenbauen der fertigen Unit jedes Entwicklers.

Mit dem Entwickeln Entwickeln/Debuggen/Unit-Testing der nächsten Unit Funktionsweise
der fertigen Unit des Partners kennenlernen/analysieren. Rücksprache/Kritik/Verbesserungen.

Implementierung der nächsten Unit.

Erwartungen an das Vorgehen:

Aus Sicht der Frührungsebene
* Bessere Planung und Dokumentation durch notwendige Absprache (+)
* Qualitativ hochwertigerer, fehlerfreierer Code durch automatisches Review(+)
* Weniger Aufwand als beim klassischen Pair-Programming (+)
* Weniger Abhängigkeit vom Exklusivwissen eines einzelnen Programmierers (+)

Aus Sicht des Entwicklers

* Einblick in mehr Projekte, da einzelnes Projekt für den einzelnen
schnelle abgewickelt ist (+)
* Größerer Lerneffekt durch enge Zusammenarbeit mit Entwicklern die
mehr oder andere Erfahrungen/Kenntnisse haben (+)
* Bessere Ansprechpartner für auftretende Probleme (+)
* Weniger eigenes Exklusivwissen (-/+)

[illuminator]

Hi,

hört sich gut an.
Ist auf jeden Fall besser als das was ihr bisher macht. Jedenfalls ist das mein Eindruck, ich weiß ja nicht wirklich, wie chaotisch das bei euch ist.
In kleinerem Ausmaß kenn ich das auch, man verabredet mit einem Kollegen, wer was wie macht, manchmal nicht mal schriftlich, ein woche später, mittendrin stellt man fest, dass die Umsetzung mit nem anderen Konzept viel besser geklappt hätte, oder man sich irgnedwo missverstanden hat.

Nochwas zum Exklusivwissen: Wenn bestimmte Dinge einfach nicht laufen, wenn man weg ist, ist das verdammt nervig, aber andererseits, merkt man(und vorallem die Vorgesetzen ) da, das die eigene Arbeit schon ziemlich ordentlich Gewicht hat -> das kann sich eventuell ganz positiv auf einen
a) sicheren Job
und
b) ein ordentliches Gehalt
auswirken

[kartoffelsack]

-> das kann sich eventuell ganz positiv auf einen
a) sicheren Job
und
b) ein ordentliches Gehalt
auswirken

Ja schon. Aber es kann auch nicht sein, dass jeder Durchschnittliche Programmierer der länger als n Jahr da ist (mir eingeschlossen) praktisch unersetzbar wird, weil keiner nen Plan hat, z.T. noch nicht mal davon, was der macht. Unersetzbarkeit ist zwar schon was tolles aber es stimmt auch was mit der Firma nicht, wenn das laufend so geht. Meine utopische Traumvorstellung ist halt, dass ich unersetzbar bin, weil ichs besser kann als die anderen, nicht weil die Organisation einfach so scheiße ist. Und besser werden kann ich halt v.a. auch dadurch, dass ich von anderen was lerne. Und zwar nicht nur aus so nem Forum wie hier (hab hier schon seeeeehr viel gelernt ) sondern auch in der Projektarbeit. Und wenn in solchen Projekten einer an ner zentralen Stelle müll baut (so geschehen) hat halt auch keiner was davon. Und auch ich würd gern manchmal mit jemandem Rücksprache halten. Bedeutet zwar weniger Spaß bei Spielereien aber ...
Ja, langer Rede kurzer Sinn: wenn dauernd Leute aus dem Urlaub geholt werden müssen bzw. nicht gehn dürfen, hat man auch als Mitarbeiter mal genug von der Unersetzbarkeit.

[Prof84]

@kartoffelsack:

Jeder der sich mal mit XP auseinandergesetzt hat, kommt in die Versuchung pair-programming als Mittel für Ausfallsicherheit und Schulungen zu missbrauchen.
Spordisch eingesetzt ist dies vielleicht ein probates Mittel, aber langfristig, unter den von Dir aufgeführten Prämissen, wird es nur die Betriebs-Performance schwächen.

<ot>
Ist wie Wirtschaftsprotektionismus: Man subventioniert den Binnenmarkt, sanktioniert den Import, um kurzfistig unrentable Betriebe am Leben zu erhalten. Langfristig wird aber ein Leistungsgradienten geschaffen, der stetig steigt und für die Aufrechterhaltung immer mehr Energien bedarf. Irgendwann übersteigen die Kosten den Nutzen. Aber dann hat man nicht mehr die Mittel das System zu ändern und dann kommt früher oder später zum Dammbruch!
Ich denke jeder Deutsche weiß heute wovon ich rede ...
</ot>

Zurück zum Thema:
Was Du bereiben willst ist Symptomkosmetik!
Die Wurzel des Übels ist das Projektmanagement.
Laufe Amok und schicke die Leute in Urlaub und zwar Bildungsurlaub. Z.B.:
http://www.asqf.de/deu/tester/lehrplan.php#
In den PDF-Lehrplanen findest Du auch ein paar Anhaltspunkte zu deinen Problemen.

Exklusivwissen ist ein betriebsinterner Protektionismus, der IMHO langfristig alle Beteidigten schadet. Aber das Hauptproblem liegt aber darin, dass das Projekt Knowhow nicht normalisiert wird.

[elise]

hatte pairprogramming auch anders im kopf

Pair Programming :

All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.
The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class. It takes time to get used to pair programming so don't worry if it feels awkward at first

aus:
http://www.extremeprogramming.org/rules/pair.html

es geht um qualitätssteigerung, die paare müssen sich auch projektbedingt immer wieder neu finden.
ich dachte immer, die schnittstellen müssen vorher klar sein, die struktur/aufbau mit dem projektleiter durchdiskutiert sein, und die seite an seite programmierer finden zu zweit den besseren algorithmus, die bessere implementierung.

bei euch scheint die verantwortung eines gesamten (unter)programmdesigns ebenso beim programmierer zu liegen, wenn ich es richtig verstehe, und ich kann gut nachfühlen, daß dort ein partner oder ein team zur diskussion des designs fehlt.

[kartoffelsack@home]

kommt in die Versuchung pair-programming als Mittel für Ausfallsicherheit und Schulungen zu missbrauchen.

Als Schulung will ichs ja nicht missbrauchen. Es geht ja nicht darum, dass einer nicht proggen kann, oder ich so das wissen in einer speziellen technologie einfach auf nen anderen übertragen will.

hatte pairprogramming auch anders im kopf

Naja, vielleicht hab ich mit pair-programming auch den falschen Ausdruck verwendet. Es geht auch nicht einfach ums programming sondern um eine Änderung unseres Entwicklungsprozesses ungefähr ab der Stufe des Feinentwurfs.

ich dachte immer, die schnittstellen müssen vorher klar sein, die struktur/aufbau mit dem projektleiter durchdiskutiert sein

Das ist eben bei uns so nicht der Fall

Ich wills mal konkreter beschreiben:
Wir haben beispielsweise ein System zur Verkehrsnetzsteuerung. Das besteht (ich reduzier es mal) aus drei Komponenten (=Programmen).
1. Zentrale Komponente ist ne Komponente, in der alle Daten eines ganzen Netzes (das kann ne ganze Stadt sein), eingespielt werden, die cacht, persistent speichert und über das verteiltes Objektmodell syz den ganzen Anwendungen die überall im Netz laufen zur Verfügung stellt.
2. Dann haben wir ein Programm, welches Daten von Detektoren erhält aus diesen Rohdaten, aggregierte Kennwerte errechnet (z.B. die Zahl der Fahrzeuge in der letzten Minute) und die dann in Komponente 1 reinspielt. Dieses Programm läuft in ner größeren Stadt an mehreren Computern physisch in der ganzen Stadt verteilt, da wo eben die Einzeldaten reinkommen.
3. Ein Steuerungsprogramm, welches aufgrund, welches aufgrund der aktuellen Verkehrsdaten (Verkehrsdichte & Stärke) nach irgendem Verfahren bestimmte Parameter für Gruppen von Ampelanlagen bestimmt. Die Daten bekommt es aus Komponente 1)

Soweit wird das System vom gesamten Team geplant. Dann heißt es Entwickler A macht Komponente 1 (x Mannmonate), B Komponente 2 (y Mannmonate) und C Komponente 3 (z Mannmonate).
Entwickler A plant dann die die konkreten Schnittstellen von Komponente 1, das wird dann vielleicht schon noch von Projektleitung etc angeguckt, B und C müssen diese Schnittstellen dann verwendet und haben natürlich auch noch gewissen Einfluss über Kritik und Vorschläge aber das wars im Endeffekt mit der Teamarbeit. Die Projektleitung wird vielleicht noch konsultiert, wenn es ums konkrete Verhalten der Programme geht (z.B. was macht Komponente B wenn sie aus einem Teilbereicht keine Daten bekommt? Versuchts sie fehlende Daten zu interpolieren, Standardwerte zu nehmen oder steuert sie solange einfach nicht) aber die gesamte Planung einer solchen Komponente vom Klassenentwurf bis zum Testen liegt in der Hand des einen Enwicklers.

Wir haben weder Senior Developer noch sind die Projekleiter in der Lage bei technischen Fragen (ob Design oder Probleme) wirklich zu helfen, da sie keine Entwickler sind bzw schon lange nicht mehr entwickelt haben.

Hier setzt mein Vorschlag an:
Es kann nicht sein, dass einer alleine eine solche Komponente entwickelt, ohne dass ihm jemand auf die Finger schaut. Es würde aber schwer akzeptiert werden, wenn C dafür bestimmt werden würde, regelmäßig den Code von A anzugucken. C hat ausserdem selber genug zu tun hat und sich auch nicht übermäßig dafür interessieren. Auch kann B nicht freiwillig zu A gehn um ihm mal seinen Entwurf zu zeigen weil der sich ja noch nicht genauer damit beschäfigt hat oder ihn gar mal mal nen halben Tag mit ihm zu debuggen, weil A ja keine Zeit hat und ja auch nicht die geringste Ahnung vom Aufbau des Programms, dass sich das rentieren würde etc..

Wenn jetzt aber ab dieser Stufe, wo bei uns die gemeinsame Teamarbeit aufhört (also Festlegung welche komponente es gibt und was die machen sollen) zwei Entwickler für ein solches Programm zuständig sind und dieses ab dem Feinentwurf über die Implementierung bis zum Test gemeinsam betreuen (ja ich weiß, testen sollte sowieso noch eine ganz andere Abteilung) und deren Vorgehen dann noch ein bisschen regelt, dann ergeben sich Sachen wie ein detaillierter Entwurf, eine halbwegs anständige Dokumentation der Klassen, das Feslegen von Detailverhalten, Code-Review etc. fast schon zwangsweise, weil man das einfach braucht um sich abzustimmen und zusammenarbeiten zu können. Alleine bringt man das bei noch so guten Vorsätzen nie wirklich fertig wegen Zeitdruck und weil man meint sich das sowieso alles merken zu können und weil man auch nicht die Veranlassung hat seinen Klassenentwurf, den man mit Bleistift und Papier gemacht hat in nem UML-Tool zu zeichnen und aktuell zu halten.

PS.: ich denke auch nicht, dass wir mit dem Vorgehen, das bei uns praktiziert wird, so alleine dastehen, sondern dass das in vielen kleinen Softwareklitschen so oder ähnlich abgeht (Haben 10 Entwickler), weil man eben nicht ne eigene Testabteilung beschäftigen kann etc.. Und das ganze muss auch immer wunderbar geklappt haben, solang wir nur relativ kleine Projekte hatten (da war ich noch nicht da), die immer von einem, max. zwei, drei Leuten gemacht wurden, wo das noch überschaubarer ist. Aber bei unserem letzten Projet (und beim nächsten auch) sind halt alle Entwickler und auch noch 1 zwei Externe + Werkstudenten irgendwie mit beschäftigt (zwar alle nicht ausschliesslich damit, aber egal).

[peterchen]

Erst mal - wenn du mir das vorlegen würdest, wäre ich skeptisch - zuviele "plusse" in der Zusammenfassung, das glaub ich nicht.

Was du vorschlägst ist nicht eigentlich "pair programming", sondern klassisches Aufteilen eines Projekts auf zwei Coder - da gibt es weitreichende Unterschiede. Ich hab ein schönes Projekt hier, das mit ähnicher (wenn auch weniger formeller) Aufteilung zu einem ziemlichen Biest geworden ist, weil beide probleme, die sie nicht lösen konnten, auf den anderen geschoben haben.

Der zentrale Effekt von "Pair Programming" ist, den Aufmerksamkeitsspeicher (die berühmten sieben Dinge) zu verdoppeln. Das geht aber nur, wenn man eben zu zweit vor dem Rechner sitzt, die beiden gut aufeinander eingespielt sind, ihre Stärken und Schwächen gut kennen, und nicht grad einer andauern Knobi-Döner frist.

Wenn ihr kaum Erfahrung mit dem Aufteilen von Projekten habt, werdet ihr erstmal richtig Lehrgeld zahlen müssen. Die zwei müssen sich aufeinander einstellen, einer muß den Hut aufhaben, das coden dauert trotzdem länger, es gibt hunderte neue Fehler die man machen kann, die abhängigkeiten zwischen den beiden werden euch wohl ziemliche Kopfschmerzen bereiten. Du brauchst jemand mit guten technischen und Organisations-Talenten, und evtl. mit der nötigen Erfahrung. Das erste Paar-Projekt wird wohl fast genauso lang dauern und (damit fast das doppelte kosten) wie ein Single-Projekt.

Laß' mich ein paar Minuspunkte ergänzen:

- höhere Anforderungen an Projektplanung und -Leitung
- höhere Abhängigkeiten zwischen Terminen
- schwächere Verantwortlichkleiten der einzelnen Mitarbeiter
- höhere "Toleranzanforderungen" (das geht los beim Einrück-Stil....)

Ich will's euch nicht ausreden - im Gegenteil: es ist definitiv besser, das Wissen aufzuteilen - für beide Seiten. Nur erwartet nicht zuviell, vor allem keinen "magischen pair-programming"-Effekt. Zwei Mann pro Projekt is definitiv besser, aber ihr müßt 'ne Menge für tun. Fangt mit einem kleinen, einfachen, unkomplizierten Projekt an.