Bearbeiten von „KIF460:Gruppenarbeiten im Studium“


= Gruppenarbeiten im Studium (KIF 46.0) =
Pad: https://md.kif.rocks/460-gruppenarbeiten?both

== Vorstellung/Teilnehmer ==

* TU Ilmenau/2
* TU Darmstadt/5
* Nürnberg/1
* Chemnitz/1
* HTWK Leipzig/1
* Bamberg/2
* Emden/3
* Göttingen/1

== Austausch ==

Was habt ihr für Arten von Gruppenarbeiten? Wie werden diese betreut, vorbereitet, nachbereit und alles was dazugehört.

* Chemnitz: 
** Softwarepraktikum und Datenstrukturen 
** Zufall, ob man die richtigen Leute hat 
** keine Kompetenzvermittlung zu Gruppenarbeiten
* Ilmenau: 
** Softwareprojekt vorhanden, vorher Softwaretechnik Einführung 
** im Softwareprojekt mit 8 Personen mit einem Betreuer 
** Manche Betreuer*innen machen das gut, anderen ist es vollkommen egal
* Emden: 
** Softwareprojekt/Projektmanagement 
** kleine Gruppen möglich. 
** Problem, dass man Gruppen finden muss. 
** Projekt mit 17 Leuten gemacht, in Kleingruppen gesplittet, dann war die Kommuinkation kaputt 
** Gruppenarbeiten für Übungsaufgaben etc.
* Ilmenau: 
** weitere Veranstaltungen mit Gruppen, die für Bonuspunkte vorgestellt werden 
** Lösungen werden nicht alle vorgestellt
* Göttingen: 
** Programmierpraktikum mit 3-5 Leuten, die von Tutor*in betreut werden. Es gibt Leitfaden für Tutor*innen aber keine Tutorenschulung 
** ZESS Kompetenzzentrum bietet &quot;Kommunikationskurse&quot; Nachfrage -&gt; Aufgabenverteilung nicht gleichmäßig? Sozialer Aspekt abdecken?
* Nürnberg: 
** Gruppenbildung per E-Learning 
** Gruppen mit &quot;Nichts-Tuer*innen&quot; existieren 
** wenig Leute, keine Anonymität, jeder kennt sich hilft scheinbar 
** ProfessorInnen lassen uns alleine
* Darmstadt: 
** Glaubt, dass Uni durchaus Handhabe hat, es muss die Uni nur auch interessieren 
** z.B. per git Aktivität
* Chemnitz: 
** Uni kann auch Sozialkompetenzen in Studiengänge aufnehmen 
** Teile markieren, wer was gemacht hat
* Emden: 
** Teile markieren ist je nach Veranstaltung und Prinzipien nicht immer möglich 
** Wenn dann Probleme entstehen mit Prof reden, dieser hatte keine Lösung
* Ilmenau/Allgemein: 
** Uni hat auch Verantwortung, Dinge zu vermitteln 
** z.B. &quot;employability&quot; d.h. wir müssen Kompetenz erlernen, wie man in Gruppen arbeitet 
** Individualleistung muss bewertet werden -&gt; funktioniert tendenziell, wenn die Betreuer*in gute Arbeit machen
* Nürnberg: 
** Peer Review in Informatik 1, bekommt nur Code und reviewed den 
*** auch aus Kapazitätsproblemen eingeführt, nicht direkt Gruppenarbeit 
** Teilweise &quot;Desaster&quot; weil Beleidigung in Peer Review 
** Es gibt möglichkeit, dass Vorlesungen reviewed werden, aber nur gute Professor*innen nehmen das war 
** Gruppenarbeit zur Webprogrammierung
* Leipzig: 
** relativ viel Gruppenarbeit. Auslosung der Gruppen. 
** Softwareprojekt 8-10 Leute mit 3 Masterstudierenden als Betreuer im 3.Semester 
** Masterstudierende sind ScrumMaster und ProjectOwner, wenn die Masterleute, dann alles selber 
** machen, ist es blöd 
** Am Ende eine Peer to Peer Bewertung, im Ticketsystem sieht man auch, wer was macht
* Darmstadt: 
** Kennlerntreffen bei Gruppen, die sich nicht kennen. War nicht super gut, aber sie haben versucht Konfliktlösung zu thematisieren 
** Gruppe von 3 Leuten geben Aufgaben ab. Gibt Gruppenfindungsforum, aber man kann Glück und Pech haben 
** Es gibt von abgegebenen Aufgaben Testate. Code wird vorher hochgeladen, wodurch Leute, die nichts tun, auch eine gute Note bekommen haben -&gt; in Beispielfall durch Kommunikation gelöst 
** Bachelorpraktikum geht über halbes oder ganzes Jahr. Hat eine Gruppenleitung (hat im Beispiel nicht funktioniert, weil die Gruppenleitung nichts gemacht hat) -&gt; keine Qualitätskontrolle
* Dresden: 
** Legomindstormprogrammierung in Gruppen mit zufälliger Zusammensetzung 
** Bewertung einheitlich. Es wird in Form von Vorstellungen herausgefunden, ob gleichmäßig viel gemacht wurde. Wenn Gruppe zumindest, bekommt Person schlechtere Note 
** später noch Gruppenarbeit mit externen und internen Gruppenarbeiten. Extern nur mit &quot;entsprechenden&quot; Noten möglich
* Nachfrage Ilmenau: 
** Es werden also Leute nach Note in Gruppe geclustered, Gute Leute kommen in Gruppen, weniger gute in eigene Gruppe, d.h. keiner da, der denen helfen könnte? -&gt; Ja, ist mehr oder weniger so. Noch kein Hebel gefunden, wie man dagegen vorgeht
* Göttingen: 
** neue Veranstaltung mit Gruppenprojekt in Göttingen bietet Freiheit. Beispielgruppe versucht dies zu Nutzen um Kommunikative Bestandteile einzubauen

== Best Practices (Restzeit) ==

* Chemnitz: Gruppenmitglieder nicht würfeln. Dass man mit Leuten zusammenarbeitet, die man sich selber aussucht
* Leipzig: Problematik, dass man sich in der Arbeitswelt auch nicht seine Mitarbeiter*innen aussuchen kann. Bei uns gibt es die Möglichkeit Leute aus dem Projekt rauszuwerfen, wenn es garnicht klappt. Dann gehen wir zum/r Dozent/in und lassen den entfernen. Es fallen auch Gruppen komplett auseinander.
* Ilmenau: Auch wichtig für Best Practice wäre, dass man vor dem Projekt Gruppenkommunikation und Gruppenarbeit lernt. Beispiel hatte Gruppe mit Leuten aus gemsichten Studiengängen. Hat gut geklappt, da die WiInf-Studierenden Gruppenarbeit und Projektorganisation geübt haben
* Bamberg: Zwiespalt zwischen Würfeln und selber aussuchen. Schlechteste Erfahrung mit Gruppen, die gemischt zwischen bekannten und unbekannten Leuten besteht
* Emden: Betreuer*innen-Sicht -&gt; Zusammengewürfelte Gruppen laufen immer schlechter als die, die sich kennen, aber Leute, die sich kennen brechen mit &quot;mehr Radau&quot; auseinander. Man macht es vermutlich wie mans macht, immer falsch
* Rhein-Main: Per Fragebogen an Studierende tariert Professor*in die Gruppen aus, so dass unterschiedliche Stärken und Schwächen in der Gruppe vertreten sind.
* Ilmenau: nicht komunizierter Zeitpunkt, wenn Leute sich in &quot;Gruppenbildungssystem&quot; eintragen können. Im Modulhandbuch sollte Gruppenarbeitskompetenz stehen. Wenn Gruppen auseinanderbrechen, wäre gut wenn dies begründet sein müsste (Reflektion)
* Darmstadt:
** Gruppen in Form von Praktika können cool sein, eher nicht bei Übungsbetrieb, weil man sich dann die Aufgaben irgendwie aufteilt, einer der anderen in den Arsch tritt, da hat man keinen weiteren Vorteil. Am Ende des Semesters den kram nochmal machen, weil man nur einen Teil gemacht hat, aber alles für die Prüfung braucht
** Harte Teilnehmerzahl in Praktikum macht Lerngruppen Probleme
* Ilmenau: Es muss auch klar sein, dass es ein &quot;Erfolg&quot; ist, wenn das Projekt &quot;scheitert&quot;. D.h. man lernt auch aus gescheiterten Projekten
* Leipzig: Gemischte Gruppen funktionieren ganz gut
* zu lernen, was man zu tun hat und vielleicht eher lassen sollte wäre noch gut
* Darmstadt:
** Tutor*innen sollten auch bewertet werden, damit etwas passiert, um die eine Qualitätssicherung festzustellen
** Gemischte Gruppen gibt es. Andere Studiengänge suchen &quot;gute Programmierer*innen&quot; um dann nichts tun zu müssen
* Dresden: Aufgaben sollten gleichen Schwierigkeitsgrad für alle haben aber Ausgestaltungsmöglichkeiten bieten.
* Bamberg: Kommunikationskanäle werden geschaffen in den Gruppen
* Göttingen:
** Rollenverteilung in der Gruppe - sollte verteilt sein und das muss auch ermöglicht werden.
** Aufwand ist natürlich da (Gruppe finden, Kommunikation, Feedbackrunden etc.), sollte auch in Credits sich wiederspiegeln.
* Leipzig:
** Kommunikation viel über E-Mail
** Wenn man kein WhatsApp benutzt, ist das blöd, wenn dennoch viel über solche Kanäle kommuniziert wird
* Dresden:
** Uni sollte Plattform für größere Gruppen zur Verfügung stellen
** Messenger etc. sollte Gruppen überlassen sein,
* Ilmenau:
** Betreuer*in legt Kommunikationsplattform fest
** Uni stellt gitlab bereit

== '''Best Practises''' ==

# Gruppenmitglieder nicht würfeln, sondern aussuchen(?), gemischte Gruppen aus verschiedenen Fächern
# Möglichkeit Leute raus zu werfen aus dem Praktikum (Hebel gegen Leute, die nicht mitarbeiten)
# Gruppenkommunikation vor dem Gruppenprojekt lehren und üben, warum klappt eine Gruppenarbeit nicht [Thomas aus Nürnberg, Snaums aus Chemnitz, Nico aus Emden - zusammen mit 1,2,8]
# Wofür sollten Gruppenarbeiten verwendet werden? (z.B. nicht bei nachfolgender Klausur) [Simone aus Darmstadt, Arina aus Leipzig, Tobias aus Dresden]
# Anzahl Gruppenmitglieder als &quot;Korridor&quot; (bspw. [3..5])
# Socializing in der Gruppe (man geht mit den Leuten in die Mensa etc.) [Fabi aus Darmstadt, Tim aus Darmstadt, Kiki aus Emden]
# Betreuung und Qualitätssicherung, Anforderungen an die Betreuer stellen
# Es ist auch Erfolg, wenn Projekt scheitert - Kommunikation [1,2,3,8 zusammen]
# Gruppen mischen durch verschiedene Studiengänge, da diese verschiedene Kompetenzen mitbringen
# Feedbackkanal zur Betreuung (Qualitätssicherung) [Jannis aus Darmstadt, Norman aus Emden, Franziska aus Ilmenau - mit 7]
# Schwierigkeit der Aufgabenstellung sollte gleich bzw. ähnlich sein für alle Gruppen.
# Rollenverteilung erlauben und Projektorganisation als Arbeitsaufwand und Leistung ansehen [Janika aus Darmstadt, Ente aus Göttingen, Thorsten aus Privat]
# Uni sollte Kommunikationsplattform bereitstellen, Gitlab / SVN, Wiki (?) [Erik aus Ilmenau, Lilith aus Aachen, Marius aus Bamberg]

=== Wofür sollten Gruppenarbeiten verwendet werden? ===

* Erwerb von Sozialkompetenzen
** Es steht nicht der Erfolg des Projekts, sondern die Gruppenarbeit an sich im Fokus
* Programmierprojekte
** Das Projekt selbst ist für die Note relevant
** Arbeit kann sinnvoll aufgeteilt werden
** Es wird keine Klausur darüber geschrieben
* Eventuell theoretische und praktische Übungsabgaben
** Es sollte während des Übungsbetriebs sicher gestellt werden, dass alle Gruppenmitglieder die Kompetenzen erwerben
** Nach Möglichkeit sollte Individualbewertung eine Option sein, z.B. Einzelabgaben, auf denen eine Gruppe angegeben werden kann, aber nicht muss

=== Socializing in der Gruppe ===

* Zeitliche Probleme
** Viele soziale Gruppen, aber nur 1x Mittagessen
* Es setzen sich automatisch weitere Menschen dazu
* Auch Abends weg gehen oder sonst irgendwas machen
* Wenn der erste Eindruck schon schlecht war, sagen einige Menschen vermutlich leider schon ab und haben keine Lust, noch Socializing zu betreiben
* Pendler*innen können Abends nicht weg gehen (kein Zug)
* Konsens: Socializing ist wichtig, aber schwer!
* Nach einem Projekt sowohl den Erfolg als auch Misserfolg feiern
* Aber vor allem auch den Erfolg
* '''Die Uni sollten den Menschen nahelegen, dass Socializing wichtig ist'''
** '''Betonen, dass es sehr wichtig ist, den Erfolg am Ende zu feiern!'''
* Die Gestaltung der Treffen muss individuell sein, da die Möglichkeiten stark von der Zusammenstellung der Gruppe (Lebensituation, Pendelwegen, Freund*innen, …) abhängen.

=== Qualitätssicherung, Anforderungen und Feedback bei/für Tutor*innen ===

* '''Anonymes Feedback''' über Forum
* wird direkt angegangen und verbessert
* '''Tutor*innen müssen geschult werden'''
** Didaktik und wie geht das so mit Gruppenbetreuung
** Beschwerden über die Tutor*innen muss durch die HS bzw. den Fachbereich ernstgenommen werden
** Gruppe muss in die Bewertung des*r Tutor*in mit einbezogen werden
** Feedback über Tutor*in geht an die nächst höhere Stelle
* es sollten '''nicht rein studentische Betreuung''' sein.
** '''Wissenschaftliche Mitarbeitende sollten ebenfalls für Gruppe zuständig sein, als Ansprechpartner*in''' auch für die studentischen Tutor*innen
* Betreuende Person sollte sich für Projekt und/oder Studierende interessieren.
* Regelmäßige Treffen und guter '''Kontakt mit Unterstützungsangebot für Studierende'''.
* Betreuende Person sollte auch '''Feedback an Studierende geben'''.

=== Rollenverteilung erlauben und Projektorganisation als Arbeitsaufwand und Leistung ansehen ===

'''Brainstorming''' * Lehrende müssen Bewusstsein für die Relevanz von Projektorganisation haben * Im Projekt gegenseitig Lob verteilen -&gt; auch für Organisation * Bei vielen Testaten, mit Fragen: &quot;Wie sieht diese Codezeile&quot; aus -&gt; wie bringt man das dort ein? * Fragen auf Bereiche aufteilen (z.B. Projektorganisation) * Nur Leute, die entsprechendes getan haben, antworten auf die entsprechenden Fragen * Studierenden müssen Bewusstsein für die Relevanz von Projektorganisation haben * -&gt; siehe Gruppenarbeit üben und lehren (s. anderer Punkt) * mehrere Gruppenarbeiten um verschiedene Rollen einzunehmen * erste Gruppenarbeit Organisationsrollen nicht in der Gruppe haben, sondern bei Betreuer (dafür siehe gute Betreuung)

'''Vorraussetzungen''': * grundlegend gute Betreuung (siehe &quot;gute Betreuung&quot;) * Gruppenarbeitskompetenz vermitteln um Bewusstsein für Relevanz von Projektorganisation zu schaffen (siehe Gruppenarbeit lehren und üben)

'''Ansätze''' * mehrere Gruppenarbeiten um verschiedene Rollen einzunehmen * Gruppen nach solchen Kompetenzen aussuchen können/müssen (Studiengangsspezifisch) * Bewertungschemata sollten Projektorganisation als Punkt beinhalten * Im Projekt gegenseitig Lob verteilen, dabei Kategorien angeben lassen (Projektorganisation, Programmierung, Architekturentwurf, Review, Konfliklösung, etc.) * weiteres ist zu erarbeiten ...

=== Kommunikatopnskanäle durch Uni ===

* alle Gruppenmitglieder nutzen die Dienste
* idealerweise von Uni gestellt
* Trennung von Freizeit-Programmen
* code-affine Plattformen (Slack, Trello etc.)
* Git-Einführung incl. Merge/Include-Tools, Issues
* Meta-Info in Wiki
* Rollenverteilung, Terminologie, Vorgehensmodell, Historie Treffen, Code-Guidelines
* Off-Topic auslagern
* direkter Kanal zum Betreuer (z.B. Slack Channel)

=== Gruppenkommunikation ===

* du braucht jmd. der die Führung übernimmt
* respektvoller Umgang
* Rhetorik / Schlüsselkompetenzen-Kurse als Pflicht im Studium
* einheitlicher Kommunikationskanal
* Aufgabenverteilung, entweder einer übernimmt die Führung und verteilt Aufgaben oder Basisdemokratisch in größeren freien Projekten
* 7-sprung schema
* Struktur, Terminplan, fixe Zeiten #### Gruppenmitglieder aussuchen
* man kennt sich, Komm.-Wege klarer und einfacher
* man sieht sich auch öfters, &quot;Flurfunk&quot; #### Menschen rauswerfen
* Problem: Gruppe könnte sich gegen einzelne verbünden
* positiv: man wird Nichts-Tuer los
* sonst keinerlei Handhabe? #### Betreuung
* Professor*in sollte Aufgaben kennen