Qualitätsbewusstsein

[Popov]

Wo wir bei der Zahl 3 sind

Goldene Regel: Teams sollten immer ungerade Zahlen haben, also 3, 5, 7, usw. Nie gerade wie 2, 4, 6, usw. Grund: erstens - sollte die Mehrheit in einem Team vernünftig arbeiten, kann sie zweites - die arbeitsfaule (oder sonstiges) Minderheit überstimmen. Die Minderheit wird immer mitgezogen. Bei einem Team mit einer geraden Zahl kann und wird es irgendwann einen Patt in den Meinungen geben. Sollte es dazu kommen, dass das Team aus einer ungeraden Zahl besteht und die arbeitsfaulen (oder sonstiges) die Mehrheit bilden, wird das irgendwann auffallen und das Team aufgelöst. Problem löst sich dann von alleine.

[Furtbichler]

Konsens ist der Tod von Effizienz. Auch wenn demokratische Mehrheitsentscheidungen toll sind, dauert die Entscheidungsfindung im schlimmsten Fall ewig und säht -speziell bei Glaubensdiskussionen- unnötigerweise Zwietracht. Die gleiche Entscheidung kann auch vom Teamlead in kürzerer Zeit erfolgen.

Ein Entscheider/Moderator ist daher imho wichtiger als die Anzahl der Teammitglieder. Er entscheidet und gibt die Richtung vor. Idealerweise im Konsens und in Rücksprache mit den Teammitgliedern. Aber im schlimmsten Fall (oder wenn es schnell gehen soll) auf Grundlage eigener Überlegungen.

Natürlich ist Diskussion, Meinungsaustausch und der positive Kampf um die Besten Ideen sehr wichtig, aber Entscheidungen müssen schnell erfolgen. Außer am Stammtisch natürlich.

[Popov]

@Furtbichler

Ich hab nichts von demokratischem Entscheidungsprozess gesagt (auch wenn ich es nicht ausschließe). Auf der anderen Seite, nicht jede Gruppe ist ein Team. Zwar wir heute stets mit Teamfähigkeit in Stellenanzeigen geworben, aber meiner Erfahrung nach versteht man darunter oft nur, dass derjenige einfach nur verträglich und kein Störenfried ist. Denn Teamarbeit ist für mich stets eine sich selbst organisierende Einheit. Das schließt einen Teamleader nicht aus, denn man kann nicht alles immer durchdiskutieren. Aber der ist dann vom Team gewählt.

[Furtbichler]

Zitat von Popov:

Ich hab nichts von demokratischem Entscheidungsprozess gesagt

War ja auch nicht gegen deine Anmerkungen. Das ist mir nur eingefallen, weil ich es neulich einem jungen Möchtegernteamleiter unter die Nase reiben musste, der zu mir meinte, das man immer alles im Konsens abstimmen müsse und ich ihn darauf fragte, ob er auch der Meinung sei, wenn morgen Deadline ist und sich das Team nicht einig wird, worauf hin er allen Ernstes 'Ja' sagte.

Zitat:

Denn Teamarbeit ist für mich stets eine sich selbst organisierende Einheit. Das schließt einen Teamleader nicht aus, denn man kann nicht alles immer durchdiskutieren. Aber der ist dann vom Team gewählt.

Na ja. In hierarchischen Strukturen (=Firma) wird der Teamleiter eher bestimmt und nicht gewählt. Aber sonst ist das schon richtig.

[Angel4585]

Zum Thema Qualitätsbewusstsein: Ich selbst habe in der Ausbildung nicht sehr viel übers Testen gelernt.
Testen bei uns hiess drei Schritte:
1. Compilieren
2. Starten
3. mind. einmal die neue Funktion aufrufen

Mit der Zeit wurden die Programme komplizierter und das genügte eigentlich nicht, jedoch wusste ich nicht was man mehr tun kann und im Unternehmen wusste das auch keiner.

Im Studium habe ich jetzt jede Menge gelernt über Unit-Tests, Kapselung,... was entweder direkt testet oder beim testen hilft.
Allerdings sind mir dort dann wieder andere Dinge begegnet mit denen ich nicht gerechnet hätte.
Obwohl wir das dort alles ausdrücklich gelernt hatten gab es einige Studenten, die nichtmal über Schritt 1 hinausgekommen sind und behaupteten, dass es funktioniert.
Nochmal andere haben eine Aufgabe lieber garnicht erst abgegeben bevor nicht 100% C1 Coverage erreicht war.
Man sieht, egal wo: Die Welten driften weit auseinander.
Mittlerweile bin ich der Ansicht, dass meine Ausbildung doch garnicht soo schlecht war

[Namenloser]

Zitat von Angel4585:

Im Studium habe ich jetzt jede Menge gelernt über Unit-Tests, Kapselung,... was entweder direkt testet oder beim testen hilft.
Allerdings sind mir dort dann wieder andere Dinge begegnet mit denen ich nicht gerechnet hätte.
Obwohl wir das dort alles ausdrücklich gelernt hatten gab es einige Studenten, die nichtmal über Schritt 1 hinausgekommen sind und behaupteten, dass es funktioniert.
Nochmal andere haben eine Aufgabe lieber garnicht erst abgegeben bevor nicht 100% C1 Coverage erreicht war.
Man sieht, egal wo: Die Welten driften weit auseinander.
Mittlerweile bin ich der Ansicht, dass meine Ausbildung doch garnicht soo schlecht war

Ja, so ähnlich ist das hier auch. In der Softwaretechnik-Vorlesung wurde ewig rumphilosophiert über Unit-Tests, Integration-Tests und so weiter und sofort und Code Coverage. Ist ja an sich auch ganz schön, ich setze Unit-Tests schon länger bei meinen Hobbyprojekten ein (wobei ich das nicht so streng von Integration-Tests und dem ganzen anderen Kram abgrenze, hauptsache überhaupt ein Test ist meine Meinung) und wollte bei diesem Projekt eigentlich auch durchsetzen, dass jeder für seinen Code Tests schreibt, nur leider bringt das wenig, wenn es nicht konsequent gemacht wird und anderswo zum Teil schon an den elementarsten Dingen hapert. Ich hab für meinen Code am Anfang noch Tests geschrieben, aber später hab ich es dann selber auch nicht mehr gemacht, weil die Zeit besser darin investiert ist, den Code von den anderen zu überarbeiten...

Achja und ich glaube, das hat mit der Ausbildung gar nicht so viel zu tun. Scheint mir eher eine Mentalitätssache zu sein.

[jaenicke]

Wir haben auch keine kompletten Unittests. Für viele unserer diversen Hilfsklassen gibt es die Tests aber, da die in mehreren Projekten verwendet werden.
Die eigentlichen Tests eines fertigen Programms passieren aber automatisiert per TestComplete und (vor allem wenn Hardwareansteuerungen involviert sind) manuell.

Ganz ohne Tests wäre keine gute Idee.

[Phoenix]

Zitat von Namenloser:

Ich hab für meinen Code am Anfang noch Tests geschrieben, aber später hab ich es dann selber auch nicht mehr gemacht, weil die Zeit besser darin investiert ist, den Code von den anderen zu überarbeiten...

Achja und ich glaube, das hat mit der Ausbildung gar nicht so viel zu tun. Scheint mir eher eine Mentalitätssache zu sein.

Naja, da beisst sich die Katze in den Schwanz. UnitTests sind ja eigentlich genau dafür da, das man Code überarbeiten / refaktorieren kann ohne das einem die Änderungen irgendwo anders auf den Fuss fallen.

Wenn das Unternehmen ein wirkliches Interesse an Code Qualität hat, dann kann man das auch recht einfach hinbekommen.
1.) Code Coverage automatisieren und die Reports regelmäßig nach den Checkins ausführen.
2.) Jedem Entwickler in die Zielvereinbarung schreiben, dass sich die prozentuale Testabdeckung permanent erhöhen muss.

Das sorgt für: Jeder neue Code ohne Tests verringert die Testabdeckung. Das senkt die Prämie des Entwicklers und geht direkt ans Geld. Der Entwickler wird im Umkehrschluss Unit Tests schreiben um seine Prämie zu sichern. Damit sichert er seinen Code auch ab. Win-Win