Workshop
Hierbei handelt es sich um eine interaktive Informations-, Diskussions, Lern- oder Trainingseinheit zu einem Thema. Der Workshop wird von den Autor:innen in einer Live-Situation in maximal 180 Minuten durchgeführt. Der Workshop sollte folgende Komponenten enthalten:
Einführung ins Thema
Warum ist das Thema relevant für das Modul? Wie hat sich das Thema entwickelt und woher kommt es? Wer treibt das Thema voran und warum? Für wen ist das Thema interessant?
Kurzübersicht über den Workshop
Was passiert im Workshop? Was muss ich als Teilnehmer mitbringen? Was muss ich vorbereiten? Was kann ich nach dem Workshop besser als vorher?
Theoretischer/ Grundlagenteil
Wesentliche Konzepte, Ideen, Techniken, Kontexte etc. um das Thema zu verstehen und im Themenfeld agieren zu können.
Praktischer Teil
Das ist der wichtigste Teil des Workshops, denn hier findet eine konkrete, praktische Auseinandersetzung mit dem Thema statt: Übungen, Aufgaben, Analysen, Synthese, etc. Der oder die praktischen Teile müssen gut an- und abmoderiert werden und auch gut begleitet und dokumentiert werden.
Zusammenfassung, WrapUp & Feedback
Was wurde gemacht? Was sollen/ können die Teilnehmer mitnehmen? Wie kann man das Thema vertiefen? Was haben die Teilnehmer mitgenommen?
Abstract
Dem Workshop muss ein kurzes Abstract vorangestellt werden, aus dem auch hervorgeht an welche Zielgruppe sich der Workshop richtet, welche Kenntnisse und Voraussetzung gegeben sein müssen und was durch den Workshop vermittelt wird. Die erforderlichen Dokumente müssen als Hypertexte oder Markdown Files bereit gestellt werden und alle enthaltenen Ressourcen wie Grafiken und Bilder referenzieren. Sollten Videosequenzen enthalten sein, dann müssen diese über den Youtube Kanal der Medieninformatik verfügbar gemacht und ins Dokument eingebunden werden.
Folgende Angaben müssen enthalten sein:
- Thema
- Modul
- Entstehungsjahr
- Autor
- Keywords
- Zielgruppe
- notwendige Voraussetzungen
Niveaustufen Workshop
Beste Lösung
- Das Thema wird überzeugend eingeführt: Relevanz, Kontext und persönliche Motivation der Workshopgeberin sind spürbar
- Das Thema wird eingeordnet: Was gibt es Ähnliches, wie grenzt sich der Workshop ab, was machen wir heute?
- Es gibt eine nachvollziehbare Reiseroute zu Beginn – Teilnehmende wissen, welche Etappen sie erwartet
- Konzepte und theoretische Grundlagen werden vor dem praktischen Teil erläutert – kein direkter Einstieg in den Code
- Der Übergang von Theorie in die Praxis ist nachvollziehbar und leitet sich aus dem Konzeptteil ab
- Die Codebasis ist bewusst einfach gehalten und setzt wenig voraus – niemand wird verloren
- Praktische Teile sind präzise angeleitet: verständliche Aufgabenstellung, Zeitvorgaben, Hilfsmaterialien oder Musterlösungen zum Nachschlagen
- Die Workshopgeberin geht während der Bearbeitungszeit aktiv rum und unterstützt
- Nach dem Praxisteil wird reflektiert: Lösungen werden gemeinsam angeschaut, Teilnehmende werden einbezogen, das geht nicht zu schnell
- Das Ergebnis wird zurück zum Ausgangskonzept kontextualisiert – was haben wir gelernt, was war schwierig, warum?
- Am Ende gibt es eine Zusammenfassung und einen Ausblick
- Die Materialien sind so aufbereitet, dass man sie im echten Entwickleralltag direkt verwenden kann
Gute Lösung
- Thema und Motivation werden vorgestellt, die Einordnung ins größere Themenfeld ist erkennbar, aber nicht vollständig ausgearbeitet
- Eine Reiseroute oder Agenda ist vorhanden, gibt aber nicht immer ein verständliches Bild davon, was die Teilnehmenden am Ende mitnehmen
- Der Theorieteil ist solide und legt die wichtigsten Konzepte dar, geht aber gelegentlich zu schnell in den Code, ohne den Übergang explizit zu machen
- Praktische Teile sind vorhanden und sinnvoll eingebettet; Aufgabenstellung und Zeitvorgaben sind klar, Hilfsmaterialien vorhandenaber nicht immer ausreichend unterstützend
- Die Codebasis ist recht gut zugänglich, setzt an einzelnen Stellen aber mehr Vorwissen voraus als für alle Teilnehmenden angemessen wäre
- Die Workshopgeberin ist ansprechbar, geht aber nicht immer aktiv auf die Gruppe zu während der Bearbeitungszeit
- Reflexion nach den Praxisteilen findet statt, ist aber knapp oder wenig interaktiv. Teilnehmende werden kaum einbezogen.
- Zusammenfassung am Ende ist vorhanden, ein Ausblick oder Transfer in den Entwickleralltag fehlt.
- Materialien sind zugänglich und nutzbar, aber nicht so aufbereitet, dass man sie direkt im Alltag verwenden könnte.
Passable Lösung
- Das Thema wird vorgestellt, eine Einordnung oder Kontextualisierung fehlt aber weitgehend: warum dieser Workshop, warum jetzt, für wen?
- Eine grobe Struktur ist erkennbar, aber die Dramaturgie überzeugt nicht immer. Theorie und Praxis wirken nebeneinander statt aufeinander aufbauend.
- Theorieteil ist vorhanden, aber entweder zu oberflächlich oder zu lang und verliert die Teilnehmenden.
- Der Übergang in den Praxisteil passiert abrupt oder wird nicht moderiert.
- Praktische Teile sind vorhanden, aber die Anleitung ist lückenhaft, Aufgaben sind unklar formuliert, Zeitvorgaben fehlen oder die Codebasis setzt zu viel voraus.
- Während der Bearbeitungszeit gibt es kaum Unterstützung oder Präsenz der Workshopgeberin.
- Reflexion nach dem Praxisteil ist sehr knapp oder fehlt, die Aufgaben werden nicht gemeinsam nachbesprochen.
- Kein klarer Abschluss, kein Transfer
- Materialien sind vorhanden, aber wenig strukturiert und nicht für die Nachnutzung aufbereitet.
Akzeptable Lösung
- Das Thema wird benannt, aber nicht motiviert: warum es relevant ist oder wen es betrifft, bleibt offen.
- Kaum roter Faden, wenig erkennbare Reiseroute. Die Teilnehmenden wissen selten, wo sie gerade stehen und was noch kommt.
- Theorie und Praxis sind sehr lose verknüpft, Konzepte werden entweder übersprungen oder stehen zusammenhanglos neben dem Praxisteil.
- Der Praxisteil ist zu kurz, zu vage oder überfordert die Teilnehmenden durch eine ungeeignete Codebasis oder unklare Aufgaben.
- Kaum aktive Begleitung während der Bearbeitungszeit.
- Kaum Reflexion oder gemeinsame Nachbesprechung.
- Kein WrapUp, kein Ausblick.
- Materialien fehlen weitgehend oder sind in einem Zustand, der keine sinnvolle Nachnutzung erlaubt.
Schlechte Lösung
- Thema, Relevanz und Ziel bleiben unklar
- Kein erkennbarer Aufbau, kein Bogen
- Kein sinnvoller Praxisteil
- Keine Anleitung, keine Begleitung, keine Reflexion
- Keine nutzbaren Materialien
Beiboot Projekt
Das Beiboot Projekt läuft parallel zum Modul. Hier wird ein grobes Projektthema vorgegeben und alle zwei bis drei Wochen werden Features publiziert, die dann integriert werden müssen. Im Rahmen der Veranstaltung werden gemeinsame Code und Review-Vorstellungen, Diskussionen und Reviews durchgeführt. Das Beiboot Projekt dient als Diskusionsgrundlage und zeigt, wie verschiedene Teilnehmer/ Entwickler das gleiche Feature implementieren, es dient als Grundlage für die Diskussion zu Technologie- und Implementierungsentscheidungen, es hilft den Teilnehmern bei der Selbsteinschätzung der eigenen Skills und es dient zur Inspirationen für alternative Implementierungsansätze und Ideen. Im Beibootprojekt werden auch Kooperations- und Qualitätssicherungs Kompetenzen aufgebaut und gefestigt.
Niveaustufen
Beste Lösung
- Alle Issues werden im Takt abgeliefert, Zeitvorgaben werden eingehalten oder begründet überschritten
- Der tatsächliche Zeitaufwand wird für jedes Issue dokumentiert und reflektiert – es entsteht ein realistisches Bild der eigenen Arbeitsgeschwindigkeit
- Technologieentscheidungen werden aktiv getroffen, nachvollziehbar begründet und in Decision Records festgehalten
- Die Wahl der Technologien zeigt Mut zum Experiment – neue Ansätze werden bewusst ausprobiert und eingeordnet
- Der Code ist verständlich strukturiert, gut kommentiert und so aufgebaut, dass Dritte ihn nachvollziehen, starten und erweitern können
- Wesentliche Entscheidungen, Schwierigkeiten und Lernmomente sind dokumentiert
- Die Ergebnisse werden in Reviews aktiv eingebracht, die eigene Lösung wird im Vergleich zu anderen reflektiert
- Das Projekt ist insgesamt ein überzeugender, eigenständiger Beitrag – technisch solide, gut dokumentiert und mit erkennbarer Handschrift
Gute Lösung
- Issues werden überwiegend im Takt abgeliefert, kleinere Verzögerungen sind nachvollziehbar
- Zeitaufwand wird dokumentiert, aber nicht immer vollständig oder mit Reflexion verknüpft
- Technologieentscheidungen sind erkennbar, aber nicht immer explizit begründet oder in Records festgehalten
- Der Code ist verständlich und funktioniert, kleinere Strukturschwächen oder fehlende Kommentare fallen aber auf
- Dokumentation ist vorhanden, bleibt aber stellenweise oberflächlich
- Die eigene Lösung wird in Reviews vorgestellt, ein aktiver Vergleich mit anderen Ansätzen findet aber kaum statt
- Das Ergebnis ist solide und nutzbar
Passable Lösung
- Issues werden nicht immer im Takt abgeliefert, Verzögerungen bleiben unbegründet
- Zeitaufwand wird kaum oder unregelmäßig dokumentiert
- Technologieentscheidungen wirken zufällig oder unreflektiert, eine Begründung fehlt weitgehend
- Der Code funktioniert, ist aber schwer nachzuvollziehen – Struktur und Kommentierung sind lückenhaft
- Dokumentation ist minimal und wenig hilfreich für Dritte
- Reviews werden passiv mitgemacht, kein erkennbarer Austausch mit anderen Lösungsansätzen
- Das Ergebnis ist verwendbar, aber nicht überzeugend
Akzeptable Lösung
- Issues werden häufig nicht im Takt abgeliefert oder sind unvollständig
- Kein nachvollziehbares Zeittracking, kein Gefühl für den eigenen Aufwand
- Technologieentscheidungen sind nicht dokumentiert, es gibt keinen erkennbaren Auswahlprozess
- Der Code ist schwer verständlich, kaum kommentiert und nicht ohne Weiteres durch Dritte nutzbar
- Dokumentation fehlt weitgehend
- In Reviews kaum präsent, kein Austausch mit anderen Lösungen
- Das Ergebnis erfüllt die Anforderungen nur teilweise
Schlechte Lösung
- Issues werden nicht oder stark verspätet abgeliefert
- Kein Zeittracking, keine Dokumentation
- Keine nachvollziehbaren Technologieentscheidungen
- Code ist nicht funktionsfähig, nicht strukturiert oder nicht vorhanden
- Keine Teilnahme an Reviews
- Das Projekt liefert kein verwertbares Ergebnis