Qualitätsbewusstsein

[BUG]

Zitat von Namenloser:

Ist das normal?

Gerade in einer größeren Gruppe von Leuten (>3) im Bachelor-Studium würde davon ausgehen. Ich bin immer gut damit gefahren, mit ein paar zuverlässigen Leuten zusammenzuarbeiten, welche ein ähnliche Arbeitsweise haben und die ähnliche Kurse belegen. Wenn dann zusätzliche Gruppenmitglieder nicht die erwartete Leistung bringen, musst du um sie herum planen: Leichte Aufgaben, die zur Not vom Kern der Gruppe schnell erledigt werden können, wenn es für euch alle eng wird.

Ich vermute stark, dass man auch im echten Leben () mit genügend Leute zusammenarbeiten muss, die den eigenen Ansprüchen an die Arbeit nicht gewachsen sind.
Abgesehen davon: Auch (gut) zu Pfuschen ist eine Kunst, die man lernen sollte.

[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

[pustekuchen]

Zitat von QuickAndDirty:

Ich habe auch ein wenig mit dem, folgendem Phänomen zu kämpfen.
1.Ich arbeite an Projekt A
2.Bei 75% muss ich Projekt A für das angeblich super dringende Projekt B unterbrechen.
3.Bei 40% muss ich Projekt B für das viel dringendere Projekt C unterbrechen.
4.Projekt B ist jetzt schon seit Monaten im Eisschrank, scheinbar war es gar nicht so wichtig....
5.Immer weitere Projekte die gerade "dringend" sind treffen ein.
6.Ich wechsle je nach dem welcher Kunde sich gerade meldet von Baustelle zu Baustelle und reagiere nur noch.

Ich glaub das ist völlig normal. Erst wird eine Prioriätenliste von 1 - 10 gemacht und irgendwann wird diese in 1.1, 1.2, 1.3, etc. geändert (Alles ist wichtig, muss so schnell wie möglich fertig sein und am besten noch gestern)

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

[Nersgatt]

Unittests sind sicher nicht das Allheilmittel in der Softwareentwicklung/Qualitätssicherung. Sie sind nur ein kleiner, hilfreicher Baustein.
Außerdem, wenn eine Software alle Tests besteht, heißt das noch lange nicht, dass die Software das macht, was der Kunde erwartet.