Fachrat Informatik - Forum

Quoted

Original von Benjamin

Da sollte man dann eskalieren. Erst im Team und wenn man nicht weiter kommt auch eine Stufe nach oben. Eskalieren ist ja nichts schlimmes und mitunter das einzige Mittel was einem wirklich das Projekt rettet. Es find sich schon für jeden eine Aufgabe, die er auch bewältigt. Oder es müssen eben andere Maßnahmen gefunden werden. Ein Team wird nicht komplett durchfallen wegen einer Person, wenn es wirklich alles versucht hat.

Richtig. Ich habe damals das SWP auch noch am KBS gemacht und da hatten die Betreuer ein recht feines Gespür dafür, wer vielleicht ein wenig den "Slacker" spielte. Diejenigen wurden dann darauf aufmerksam gemacht, daß sie bitte beim nächsten Projekttermin mal mit einem Kurzvortrag über irgendein (vom Betreuer gestelltes) Thema auf sich aufmerksam machen sollten.
Trotzdem hatten wir einen Mehr-oder-Minder-Totalausfall im Team, der weder zum Programmieren ("Ich kann doch gar kein Java" - ach was, wir doch auch nicht!?!?) noch zum Dokumentieren oder Entwerfen oder was denn noch so da war, Lust hatte. Nachdem ich einmal die A-Karte gezogen hatte und die Zusammenarbeit mit dieser Person absolut unmöglich war (selbst nach Aufforderung durch uns keinerlei Arbeitsbereitschaft), habe ich mir den guten Mann in Absprache mit dem Gruppenbetreuer mal bei einem Gruppentreffen zur Brust genommen und eingenordet. Das muß IMHO auf jeden Fall sein, denn einfach durchschleppen und die Klappe halten ist unfair sich selber gegenüber (da krieg' ich Placque!) und verwässert die Ergebnisse.

Bei einem anderen Laborprojekt im Bachelorstudium hatte ich so etwas ähnliches mal mit einem Viererteam, bei dem 2/4 Leuten nicht so die rechte Bereitschaft gezeigt haben. Einer hatte ob seines fortgeschrittenen Semesters offenbar bereits Erfahrung mit der Vermeidung von Arbeit und der andere war kein Informatiker, hatte daher mit dem gestellten Thema wohl schlicht fachliche Probleme. Dumm war nur, daß wir keinen "Projektleiter" hatten, also durfte auch da ich mir den Hut aufsetzen und dafür sorgen, daß ich nicht zusätzlich zur eigentlichen Projektarbeit auch noch die ganze Doku machen mußte...

Quoted

Original von Benjamin
Meine Meinung: Bei soetwas nie schweigen und hinnehmen(!), sondern ruhig und gelassen klären aka. eskalieren. Gutes Training für das harte Projektleben nach der Uni.

Definitiv. Insbesondere muß man sich vor Antritt einer Stelle in der Wirtschaft - damit während des Studiums - meiner Meinung nach dringend von der in der Schulzeit durch Peer Pressure antrainierten Arbeitsvermeidungshaltung à la "Wenn ich mich jetzt freiwillig melde, gelte ich bestimmt als Streber", die im Studium recht zügig in "Wenn ich mich jetzt freiwillig melde, muß ich womöglich noch was leisten" übergeht, verabschieden. Denn hier schadet man dem Kommilitonen damit und das ist schlicht asozial.

Mir persönlich geht es tierisch auf den Sack, wenn da so ein paar lebende Gemüse in einer Projektgruppe rumhängen und außer Stoffwechsel nichts leisten; ich neige dann dazu, die Arbeit für die einfach mit zu erldeigen, sie also "durchzuschleppen". In dem zuletzt erwähnten Projekt habe ich sie jedoch nach ausreichender Vorwarnung einfach mal beim Betreuer auflaufen lassen, das hat leider genauso wenig was gebracht.

Denn: Im Endeffekt hat ja oft weder der Prüfer noch der Betreuer eines Labors viel davon, leistungsunwillige Leute durchfallen zu lassen, sie neigen ja meist dazu, dann einfach 2 Semester später wiederzukommen und noch eine Projektgruppe zu versauen. Das ist für die anderen Beteiligten (also den Studi, der für seine CP echt was tut, für die Betreuer und Prüfer), zumindest nach meinem Gefühl, ziemlich frustrierend.

Also, liebe Ersies (welchen Studiengangs auch immer), wenn Ihr dazu neigt, im Team einfach erstmal die anderen machen zu lassen, bis Arbeit unvermeidbar ist, dann wechselt bitte jetzt! Damit spart Ihr Euren Kommilitonen jede Menge Nerven, dem Land Studiengebühren und uns anderen Uni-Angehörigen einige Positionen in der Mensaschlange.

Just my €0,02...

Quoted

Natuerlich kannst du das, wenn du die Eier hast deinen Job zu riskieren. Es geht doch nicht um leiden,..., sondern um professionalitaet. Ob jemand seinen Job kann oder nicht. Du musst dich doch nicht immer an alles gewoehnen/anpassen. Manchmal hilf das ansprechen schon, um die Sitauation zu aendern.

Ich habe auch nicht davon geredet, sich alles bieten zu lassen. Was ich meinte ist, dass man auch mit Leuten arbeiten können sollte, die man von der persönlichen Seite aus wohlmöglich nicht so gut leiden kann.

Und manche Sachen kannste zwar ansprechen, aber nicht zwangsläufig ändern: Was machste z.B. denn wenn du irgendeinen Chef mit nem BWL-Background hast, der überzeugt ist er könne wunderbar bei der Softwareentwicklung mitreden (obwohl er davon nix versteht)?
Es gibt in der Wirtschaft (leider) nunmal Entscheidungsträger, die nicht vom Fach sind, aber trotzdem ihre eigenen Vorstellungen durchsetzen - egal, was andere sagen.

Wegen den event. unwilligen Teammitgliedern, wenn man sich nicht schon über sie beschwert hat, so bekommen sie doch eigentlich spätestens bei der Abnahme des Projekts eins auf den Deckel. Da die Betreuer eigentlich schon ganz gut überblicken können, wer was gemacht hat (ich spreche jetzt hier fürs KBS).

Daraus folgt dann, dass dann die Unwilligen mal ganz schnell noch eine Nachprüfung bekommen oder schon von vorne herein das Projekt nicht bestehen.

Quoted

Original von hyperion
Daraus folgt dann, dass dann die Unwilligen mal ganz schnell noch eine Nachprüfung bekommen oder schon von vorne herein das Projekt nicht bestehen.

Schön wär's, aber die Unwilligkeit, am Projekt produktiv mitzuarbeiten, paart sich oft mit einer ungewöhnlichen Leistungsbereitschaft, wenn es darum geht, Aktivität vorzutäuschen...

Hm, habs ja jetzt noch vor mir, ... aber gelten die KBS-Projekte wirklich als einfacher als die vom SE?! Hatte in der Infoveranstaltung eher das gegenteilige Gefühl. Außerdem wirken sie ein bisschen weniger, als würde man direkt in den Mülleimer entwickeln, also nur um des Entwickelns wegen.

Ich denke nicht, dass sie einfacher sind. Im Gegenteil, alle Aufgaben haben da oft einen Anwendungsbezug und werden scheinbar wirklich benötigt, was im SE eher nicht der Fall ist. Dafür wird dort viel methodischer gearbeitet, du musst Lastenhefte, Pflichtenhefte schreiben, Reviews durchführen, durch Quality Gates kommen....und so weiter. Müsst eben alles, was man bei SWQ/SWT so gelernt hat, einmal richtig durch"spielen".
Beim KBS bekommst Du eine Aufgabe, und den Leuten ist es egal wie ihr als Gruppe darangeht, was ihr tut. Ihr braucht keinerlei Doku schreiben, Design Pattern etc braucht ihr nicht benennen, könnt coden wie ihr wollt. Hauptsache, bei der Deadline habt ihr euer Programm fertig...

So interessant die Diskussion sonst auch ist und so ich mich da sonst auch raushalten sollte:

Quoted

Original von julianr
Außerdem wirken sie ein bisschen weniger, als würde man direkt in den Mülleimer entwickeln, also nur um des Entwickelns wegen.

Wie gesagt sind die Aufgaben bei uns auch ernst gemeint und sie werden eingesetzt werden. Das war bisher bei allen Aufgaben so, die wir gestellt haben (nicht nur im SWP, sondern auch BSc/MSc-Arbeiten, Labore etc.). Die mögen zwar ein wenig spielerischer aussehen, aber ich habe z.B. schon vor damit eine Keysigningparty durchzuführen und die Testabdeckung von studentischen Projekten zu visualisieren. Dito für die anderen Projekte...

Daniel

Ups — gerade das Keysigning habe ich dann zu wenig ernst genommen, ich dachte da gäbe es mittlerweile schon jedes Tool doppelt. Bei UMLPaint & XML-Editor hat man den Realitätsbezug auch gehört, aber ich stelle es mir bei so hohen Usability-Anforderungen schwer vor, am Ende wirklich konkurrenzfähig zu sein. Bin jedenfalls gespannt.

War aber auch nicht so böse gemeint, mein Zweitprojekt ist das Keysigning trotzdem

Quoted

Original von julianr
Hm, habs ja jetzt noch vor mir, ... aber gelten die KBS-Projekte wirklich als einfacher als die vom SE?! Hatte in der Infoveranstaltung eher das gegenteilige Gefühl. Außerdem wirken sie ein bisschen weniger, als würde man direkt in den Mülleimer entwickeln, also nur um des Entwickelns wegen.

Habe damals beim KBS das SWP gemacht. Dadurch kenne ich (wie wohl jeder hier) auch nur die eine Seite. Aber als easy-going empfand ich unser Prohekt damals eher nicht. Daher würde ich der pauschalen Aussage "KBS ist leicher" prinzipiell erstmal widersprechen. Wahrscheinlich gibt es hier wie dort solche und solche Projekte.
Und mit dem "in den Mülleimer entwickeln", keine Ahnung was für Aufgaben es dieses Jahr gibt, aber bei uns damals hörte sich dass nicht so an, als würden die Dinger in den Mülleimer gehen. Das waren eher solche Sachen wie "Wir würden gerne dazu mehr wissen, aber haben eigentlich keine Zeit/Lust das selber zu machen". Wir mussten zB ein Tool schreiben, mit denen man WebRatio Projekte in UML Diagramme 'parsen' kann. Dazu gehörte dann auch sich selber Gedanken zu machen, wie eine logische entsprechung der Diagramme in URL aussieht. Und aus Kommentaren wie "Den Ansatz hatte ein Kolege von mir auch im Kopf" hatte man schon herausgehört, dass dem Betreuer die Ergebnisse schon interessierten.

Mal meine 3€ zum Thema. Und zu dem 'Durchschleppen' von Gruppenmitgliedern .... naja, dass kennt wahrscheinlich 50% der Studenten. Die anderen 50% sind dann die, die sich schleifen lassen ...

Quoted

Original von DrChaotica
Dafür wird dort viel methodischer gearbeitet, du musst Lastenhefte, Pflichtenhefte schreiben, Reviews durchführen, durch Quality Gates kommen....und so weiter. Müsst eben alles, was man bei SWQ/SWT so gelernt hat, einmal richtig durch"spielen".
Beim KBS bekommst Du eine Aufgabe, und den Leuten ist es egal wie ihr als Gruppe darangeht, was ihr tut. Ihr braucht keinerlei Doku schreiben, Design Pattern etc braucht ihr nicht benennen, könnt coden wie ihr wollt. Hauptsache, bei der Deadline habt ihr euer Programm fertig...

Ich bin mir nicht sicher, was von beidem besser ist.

Früher war ich der festen Überzeugung, daß das Softwareprojekt den Idealfall widerspiegeln sollte, d. h. lehrbuchmäßig Methoden anwenden sowie sehr systematisch und strukturiert arbeiten. Mittlerweise bin ich aber eher der Meinung, daß das Ziel des Softwareprojektes eher das Scheitern sein sollte. Der Lerneffekt ist vermutlich größer, wenn man durch ein praktisches Projekt (das wegen fehlender Struktur schlecht läuft) lernt, warum man eine gute Planung und die "Lehrbuchmethoden" benötigt.

Die Frage ist also, ob das Softwareprojekt dazu da sein sollte, die Anwendung von Methoden zu üben, deren Notwendigkeit sich nicht unbedingt erschließt, oder dazu, die Notwendigkeit dieser Methoden durch praktische Erfahrung einzusehen. Aber diese Frage ist ganz bestimmt nicht neu und wurde bereits oft genug im SE und KBS/L3S diskutiert.

Quoted

Original von Joachim
Mittlerweise bin ich aber eher der Meinung, daß das Ziel des Softwareprojektes eher das Scheitern sein sollte. Der Lerneffekt ist vermutlich größer, wenn man durch ein praktisches Projekt (das wegen fehlender Struktur schlecht läuft) lernt, warum man eine gute Planung und die "Lehrbuchmethoden" benötigt.

Die Frage ist also, ob das Softwareprojekt dazu da sein sollte, die Anwendung von Methoden zu üben, deren Notwendigkeit sich nicht unbedingt erschließt, oder dazu, die Notwendigkeit dieser Methoden durch praktische Erfahrung einzusehen. Aber diese Frage ist ganz bestimmt nicht neu und wurde bereits oft genug im SE und KBS/L3S diskutiert.

Und man kann nicht dadurch lernen, dass man sieht, dass die Methoden funktionieren?
Wenn man sie anwendet, merkt man eigentlich recht schnell, warum sie so wichtig sind. So geht es mir zumindest...

Quoted

Original von DrChaotica
alle Aufgaben haben da [im KBS] oft einen Anwendungsbezug und werden scheinbar wirklich benötigt [...] Dafür wird dort [im SE] viel methodischer gearbeitet, du musst Lastenhefte, Pflichtenhefte schreiben, Reviews durchführen, durch Quality Gates kommen....und so weiter. Müsst eben alles, was man bei SWQ/SWT so gelernt hat, einmal richtig durch"spielen".

Genauso würd ich das auch beschreiben. Wenn man mit Leuten spricht die "auf der anderen Seite" waren, kam es einem im SE-Projekt stressiger vor. Aber egal! Zitierte Gründe waren genau die, wieso ich u. A. z. B. beim SE damals das Projekt machen wollt. Wer sowas mal erleben will, sollte allein deswegen schon die SE-Projekte bevorzugen. So zumindest mein Empfinden und meine Meinung.

Quoted

Original von neweb
Und man kann nicht dadurch lernen, dass man sieht, dass die Methoden funktionieren?

Möglich, keine Ahnung. Wenn das Projekt jedoch "zu gut" klappt, nimmt man die Methoden möglicherweise als Ballast wahr und merkt gar nicht, daß die ein Grund für den guten Projektverlauf sind.

Ich habe da selbst wie gesagt keine feste Meinung zu. Persönlich finde ich es aber wichtiger, erst zu wissen, warum man etwas tut und erst dann wie es genau geht.

Quoted

Original von Joachim
Möglich, keine Ahnung. Wenn das Projekt jedoch "zu gut" klappt, nimmt man die Methoden möglicherweise als Ballast wahr und merkt gar nicht, daß die ein Grund für den guten Projektverlauf sind.

Ich habe da selbst wie gesagt keine feste Meinung zu. Persönlich finde ich es aber wichtiger, erst zu wissen, warum man etwas tut und erst dann wie es genau geht.

Okay, ganz ohne irgendwelche Reibungen wird man nicht durch das Projekt kommen. Und dort sollte man eigentlich sehen, dass man hier vielleicht etwas besser mit den Methoden hätte arbeiten können, was an einer anderen Stelle wunderbar funktioniert hat, weil man sie eben verwendet hat.

Ich persönlich würde gerne mal mit dem ganzen "Overhead" arbeiten, und habe mich damals auch für ein SE Projekt eingeschrieben. Leider wurde unsere Gruppe zum KBS gelost. War auf jeden Fall eine Erfahrung, aber ein richtiges Lasten/Plichtenheft hätte ich auch gerne mal geschrieben ...

Quoted

Original von Markus
Ich persönlich würde gerne mal mit dem ganzen "Overhead" arbeiten, und habe mich damals auch für ein SE Projekt eingeschrieben. Leider wurde unsere Gruppe zum KBS gelost. War auf jeden Fall eine Erfahrung, aber ein richtiges Lasten/Plichtenheft hätte ich auch gerne mal geschrieben ...

Das ist natürlich ein Argument eher ein Projekt beim SE zu machen. Darauf kommt es mir beim Softwareprojekt eher an. Erstellen von Lasten- und Pflichtenheften kann man sonst kaum irgendwo üben. Die Projekte beim KBS haben halt einen direkten Anwendungsbezug, aber eigentlich soll es ja eigentlich darum gehen die Methoden zu lernen und nicht primär darum eine Anwendung zu entwickeln.

am besten ist es IMHO beides schon mal gemacht zu haben. erst dann kann man auch wirklich vergleichen

Quoted

Original von Markus
am besten ist es IMHO beides schon mal gemacht zu haben. erst dann kann man auch wirklich vergleichen

Was sagt mir bloß, dass das nicht wirklich jemand freiwillig zwei mal machen will

Quoted

Original von CrissCross

Quoted

Natuerlich kannst du das, wenn du die Eier hast deinen Job zu riskieren. Es geht doch nicht um leiden,..., sondern um professionalitaet. Ob jemand seinen Job kann oder nicht. Du musst dich doch nicht immer an alles gewoehnen/anpassen. Manchmal hilf das ansprechen schon, um die Sitauation zu aendern.

Ich habe auch nicht davon geredet, sich alles bieten zu lassen. Was ich meinte ist, dass man auch mit Leuten arbeiten können sollte, die man von der persönlichen Seite aus wohlmöglich nicht so gut leiden kann.

Professionalitaet!?! Hat etwas damit zu tun, dass man persoehnlich und leiden aus dem Berufsfeld raushaelt. Ich bin zum Glueck ein sehr offener Mensch und bin von der Kommunikation beschenkt worden, daher wuerde ich nach Feierabend die nicht-leiden-Sache aus dem Weg raeumen.

Wie oberflaechlich!!!

Quoted

Und manche Sachen kannste zwar ansprechen, aber nicht zwangsläufig ändern: Was machste z.B. denn wenn du irgendeinen Chef mit nem BWL-Background hast, der überzeugt ist er könne wunderbar bei der Softwareentwicklung mitreden (obwohl er davon nix versteht)?
Es gibt in der Wirtschaft (leider) nunmal Entscheidungsträger, die nicht vom Fach sind, aber trotzdem ihre eigenen Vorstellungen durchsetzen - egal, was andere sagen.

Schon mal was von Kompromissen und Deinstleistungsvertrag gehoert. Wenn ich wie in deinem Fall diese Position inne habe und der BWL-Backgroundler sich mit seiner Position im Betrieb durchsetzten kann/darf, dann merke ich meine Meinung an und setze bei keinem Konsense seine Vorstellungen um. Da ich dann wahrscheinlich an einem Dienstleitungsvertrag gebunden bin, kriegt er einen auf den Deckel, wenn das Projekt scheitert(genau das ist ja der Unterschied beim Softwareprojekt *EDIT* im Studium *EDIT* , du hast als Entwickler gleichzeitig auch sehr hohe Verantwortung-> CP oder keine CP), ich krieg mein Gehalt, eventuel eine Kuendigung mit Abfindung :-)...

Quoted

Original von Joachim
Früher war ich der festen Überzeugung, daß das Softwareprojekt den Idealfall widerspiegeln sollte, d. h. lehrbuchmäßig Methoden anwenden sowie sehr systematisch und strukturiert arbeiten. Mittlerweise bin ich aber eher der Meinung, daß das Ziel des Softwareprojektes eher das Scheitern sein sollte. Der Lerneffekt ist vermutlich größer, wenn man durch ein praktisches Projekt (das wegen fehlender Struktur schlecht läuft) lernt, warum man eine gute Planung und die "Lehrbuchmethoden" benötigt.

Die Frage ist also, ob das Softwareprojekt dazu da sein sollte, die Anwendung von Methoden zu üben, deren Notwendigkeit sich nicht unbedingt erschließt, oder dazu, die Notwendigkeit dieser Methoden durch praktische Erfahrung einzusehen. Aber diese Frage ist ganz bestimmt nicht neu und wurde bereits oft genug im SE und KBS/L3S diskutiert.

Zu dieser Ansicht bin ich nun eigentlich auch gekommen. Allerdings wäre es für die Studenten ja nicht gerade angenehm, sich ein ganzes Semester lang mit einem Projekt befassen zu müssen, das von vornerein zum Scheitern verurteilt war. Manche nehmen so etwas ziemlich ernst und investieren dann eben soviel Zeit, dass es doch halbwegs etwas wird.
Vielleicht wäre deshalb ja so eine Art Mini-SWP über ein paar Wochen vor dem eigentlichen Projekt nicht schlecht, aber sowas ließe sich bestimmt schlecht im Studienplan unterbringen...vielleicht irgendwo (SWT/Programmieren 2 ?) als freiwillige Übung mit einem extrem großzügigen Bonus bei Teilnahme? Andererseits kann man sowas natürlich auch zuhause machen, betreutes Arbeiten nach Lehrbuchmethoden gibt es jedoch nur an der Uni... weswegen ich eigentlich auch nur bei den SE-Projekten einen Mehrwert sehe.

Aber Markus sagte es ja bereits, die andere Seite kennt man nicht... kann sein, dass es beim KBS auch nicht alles so planlos abläuft
Sehr gut finde ich jedenfalls, dass inzwischen die Projekte (im laufenden Semester, nicht bloß von Jahr zu Jahr) miteinander verknüpft werden und aufeinander aufbauen...auf diese Weise sieht man bestimmt schön die Konsequenzen schlechter Dokumentation und Programmierarbeit in Form von... real vorhandenem Ärger bei denjenigen, die es benutzen müssen.

Quoted

Signatur von Markus
You are Java. You are yery strong and sturdy, but his makes you a bit sluggish.
Which Programming Language are You?

Jetzt rat mal, was ich bin. Prolog...