Softwareentwicklung im Team
-
Geht es euch da genauso? Bei mir ist das fast immer sich über schlechte Software oder Ideen (die dann auch noch umgesetzt werden) der Anderen aufzuregen.
-
Siehste, und genau deswegen sind Softskills so wichtig.
Fachliche Lücken kann man fast immer schließen, aber wenn die Chemie net stimmt, is det allet fürn Arsch.
-
Wir setzen viele Komponenten des Extreme Programming um. Unter anderem
auch Pair Programming. Wir haben damit richtig gute Erfahrungen gemacht.
-
Es ist eine hohe Kunst, einem Mitprogrammierer oder Teammitglied auf die richtige Art und Weise zu sagen "Dein Code ist Mist, und Deine Vorgehensweise veraltet". Das ist fast so schwierig (mit ähnlich fatalen Folgen) wie der Frau oder Freundin zu sagen "das Kleid das Du gerade anhast steht Dir überhaupt nicht und Du siehst aus wie eine Tonne".
Um Verständnis für dieses Problem zu erwecken helfen Codereading (die Programmierer lesen gezielt den Code von anderen und machen dazu Anmerkungen, am besten wird der Code dazu auch gedruckt), oder die eXtreme Ausprägung - wie schon genannt - ist Pair-Programming, wo 2 Entwickler zusammen vor dem Computer sitzen.
Vorteile:
- Verständnis für anderen Code
- Verständnis für die Denkweise anderer Programmierer
- es wird eine bessere Atmosphäre geschaffen um Kritik am Code auszudrücken und vorzutragen
- Qualität steigt, da Fehlerzahl abnimmtMan darf die Bedeutung von Kritik am Code psychologisch nicht unterschätzen: da steckt jemand (bis zu) 100% seiner Geistesleistung in ein filigranes Werk, verwendet darauf seine Zeit, und jemand kommt und sagt "das ist Scheiße". Dadurch geht der Kritisierte sofort in eine Abwehrhaltung und blockt weitere Kritik, damit aber auch Ratschläge und fremdes Wissen.
Vor der Kritik muß also die Zusammenarbeit am Code geändert werden. Erst dann wird Kritik am Code überhaupt erst möglich. Mit der Zeit erkennen die Teammitglieder dann auch Stärken von anderen, und werden bei Problemen sich leichter tun um Rat zu fragen.
Eine besondere Gefahr kommt noch bei älteren Teammitgliedern hinzu - insbesondere wenn dies der Teamleiter ist - die ihre ersten Erfahrungen mit anderen Tools und Sprachen machten, und sich nicht mehr weitergebildet haben. Diese Leute von neuen Verfahren oder Vorgehensweisen zu überzeugen ist eine zusätzliche Hürde.
Aber es gibt eben die Falle: Techniker fängt man am leichtesten mit Technik und Spielereien (so wie die Mäuse mit dem Speck). Und Codereading und Pairprogramming sind eben zunächst rein technische Kniffe und haben nichts mit Vorwürfen oder Reden zu tun, daher kann man diese noch relativ leicht einführen und durchsetzen. Ebenso kann es funktionieren, daß man Teamsitzungen am Beamer macht, und man diskutiert über bestimmte Codefragmente. Offiziell dient dies natürlich der Überbrückung von Ausfällen, wenn jemand krank wird, daß sich noch andere mit dem fremden Code auskennen. Der Entwickler muß dann ein Codefragment oder eine bestimmte Lösung am Bildschirm erklären. Durch den Vortrag (Selbsterkenntnis kommt oft durch das laute Reden über eigene Dinge) und die Fragen wird Nachdenken angeregt. Auch kann ein Teamleiter dies einführen mit der Begründung, er möchte mehr über die Arbeit seines Teams lernen, weil er nicht genug Zeit hat sich alles selbst beizubringen. Die Teammitglieder freuen sich natürlich, wenn jemand Interesse an ihrer Technik zeigt.
Vorteil von all dies ist aber, daß sich alles um die Technik dreht, und die Ebene von Vorwürfen nicht so stark im Vordergrund steht.
-
Hallo,
das hoert sich alles sehr interessant an, aber wie sieht es denn mit der Zeit aus,
die bei der Umsetzung der genannten Dinge drauf geht? Bei Pair-Programming kann
ich mir z. B. auch vorstellen, dass es kontraproduktiv ausfaellt, wenn man
staendig darueber diskutiert warum eine andere Technik evtl. besser ist. Ich meine
damit jetzt nicht, dass es schlecht ist sich darueber zu unterhalten und die
staerken und schwaechen einer speziellen Technik zu hinterleuchten, sondern
vielmehr meine ich die Gefahr die besteht, dass man zu sehr in Diskussionen
abrutscht und die Arbeit dann auf der Strecke bleibt.Hoffe ihr versteht was ich meine
mfg
v R
-
Hi,
wir haben letzten in der Firma auch Pair Programming verwendet.
Ging konkret um den Fall, dass ein festangestellter Programmierer Änderungen in ein Programm eingepflegt hat und ich (Azubi) daneben gesessen habe um die eingesetzte Technologie zu verstehen.
Das war echt genial!Erstmal fielen mir als Beobachter jede Menge Flüchtigkeitsfehler auf die nunmal so beim programmieren entstehen. Dadurch dass der ausführende Programmierer seine Ideen erläutert hat, hat er sie auch besser verstanden (siehe Mar++us sein Statement). Ich hatte (natürlich) als Beobachter den Anreiz den aktuellen Vorschlag zu überprüfen, Fehler finden, Verbesserungen vorschlagen etc..
Und das war auch gut so. Im Endeffekt wurde so trotz der (fachlichen) Diskussion über einzelne Implementierungen schneller, besserer Code erzeugt.
Dazu muss ich aber sagen, dass die Aufgabenstellung nicht trivial war, wie Pairprogramming bei Simpelstaufgaben aussieht kann ich nicht beurteilen.Ein abrutschten der Diskussionen gab es auch nicht, da eigentlich schon vor der Implementation klar war, was wie (in etwa) eingesetzt werden soll.
Reicht dir das als Antwort virtuell Realisticer?
Edit:
Mein persönliches Fazit aus Pair Programming:
Unterschätze nie deine eigene Dummheit beim programmieren.
-
@vR: ein gerne und oft gehörtes Argument, aber Hand auf's Herz: wieviel Prozent Deiner Zeit PROGRAMMIERST Du und wieviel Prozent Deiner Zeit bist Du auf FEHLERSUCHE und BUGFIXING?
Das sollte eigentlich als Wink mit dem Zaunpfahl bereits ausreichen... wenn Du die Zeit für Fehlersuche halbieren kannst, fällt eine (nominale) Verdopplung des Zeitaufwands für die Programmierung mindestens neutral aus, eher sparst Du sogar noch Zeit.
Je früher ein Fehler bemerkt wird, desto weniger kostet er.
-
Stimmt, da hast/habt du/ihr natuerlich vollkommend recht.
mfg
v R