Changes for page Anforderungen Gruppen

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -234,3 +234,180 @@
234	234	** Tickets (wer macht was)
235	235	** Leitung/Protokoll (Liste!)
236	236	* Tutor ist nur Berater, leitet keine Sitzungen, kann aber um Rat gefragt werden (und greift (zu Beginn mehr und Ende weniger) ein, wenn es zu sehr „aus dem Ruder läuft“, erlaubt aber auch Fehler …)
	237	+
	238	+
	239	+
	240	+= Gruppenweites Code Review (Team-Review) =
	241	+
	242	+Neben den üblichen Pull-Request-Reviews soll im Projekt mindestens ein **gruppenweites Code Reviews** durchgeführt werden. Dieses dienen nicht primär der Fehlersuche, sondern dem **gemeinsamen Verständnis, der Diskussion von Lösungsansätzen und dem Lernen im Team**.
	243	+
	244	+== Ziel des Gruppenreviews ==
	245	+
	246	+Das gruppenweite Review soll dabei helfen:
	247	+
	248	+* die **gesamte Codebasis besser zu verstehen**
	249	+* **Designentscheidungen nachvollziehen und hinterfragen zu können**
	250	+* voneinander zu lernen (gute Lösungen, typische Probleme)
	251	+* Wissen im Team zu verteilen (kein „Ein-Personen-Code“)
	252	+
	253	+Wichtig: Es geht **nicht darum, jemanden zu bewerten**, sondern gemeinsam besseren Code zu entwickeln.
	254	+
	255	+== Organisation ==
	256	+
	257	+* Durchführung: **mindestens einmal im Semester**
	258	+* Dauer: **30–60 Minuten**
	259	+* Vorstellung von **1–2 ausgewählten Codeausschnitten**
	260	+
	261	+== Rollen im Review ==
	262	+
	263	+=== Autor:in ===
	264	+
	265	+* stellt den Code vor
	266	+* (((
	267	+erklärt:
	268	+
	269	+* Ziel und Kontext
	270	+* wichtige Designentscheidungen
	271	+* ggf. offene Fragen oder Unsicherheiten
	272	+)))
	273	+
	274	+=== Gruppe (Reviewer) ===
	275	+
	276	+* stellt Verständnisfragen
	277	+* gibt Feedback
	278	+* diskutiert Alternativen
	279	+
	280	+=== Moderator:in ===
	281	+
	282	+* achtet auf Zeit und Struktur
	283	+* sorgt dafür, dass alle beteiligt werden
	284	+* verhindert Abschweifen
	285	+
	286	+
	287	+
	288	+== Ablauf eines Gruppenreviews ==
	289	+
	290	+=== 1. Vorbereitung (Autor:in) ===
	291	+
	292	+* Wählt einen **überschaubaren Codeausschnitt** (keine sehr großen Änderungen)
	293	+* (((
	294	+Fokus z. B. auf:
	295	+
	296	+* interessante Logik
	297	+* Architekturentscheidungen
	298	+* schwierige oder unklare Stellen
	299	+)))
	300	+* (((
	301	+Bereitet **2–3 konkrete Fragen** vor, z. B.:
	302	+
	303	+* „Ist diese Struktur sinnvoll?“
	304	+* „Wie würdet ihr das testen?“
	305	+* „Gibt es eine einfachere Lösung?“
	306	+)))
	307	+
	308	+----
	309	+
	310	+=== 2. Vorstellung (ca. 5–10 Minuten) ===
	311	+
	312	+* (((
	313	+kurzer Überblick:
	314	+
	315	+* Was macht der Code?
	316	+* Wo ist er im System eingeordnet?
	317	+)))
	318	+* keine detaillierte Zeilen-für-Zeilen-Erklärung
	319	+
	320	+----
	321	+
	322	+=== 3. Gemeinsames Review (ca. 20–40 Minuten) ===
	323	+
	324	+Diskutiert den Code anhand folgender Leitfragen:
	325	+
	326	+==== Verständlichkeit ====
	327	+
	328	+* Ist der Code gut nachvollziehbar?
	329	+* Welche Stellen sind schwer verständlich?
	330	+
	331	+==== 🏗️ Design ====
	332	+
	333	+* Ist die Struktur sinnvoll gewählt?
	334	+* Gibt es einfachere oder klarere Alternativen?
	335	+
	336	+==== 🔁 Wartbarkeit ====
	337	+
	338	+* Ist der Code leicht erweiterbar?
	339	+* Gibt es unnötige Komplexität?
	340	+
	341	+==== 🧪 Testbarkeit ====
	342	+
	343	+* Wie könnte man den Code testen?
	344	+* Sind relevante Tests vorhanden oder ableitbar?
	345	+
	346	+----
	347	+
	348	+=== 4. Fazit (ca. 5 Minuten) ===
	349	+
	350	+* Was war gut?
	351	+* Was kann verbessert werden?
	352	+* Welche Erkenntnisse nehmen wir als Team mit?
	353	+
	354	+----
	355	+
	356	+== 🧩 Geeignete Inhalte für das Gruppenreview ==
	357	+
	358	+**Gut geeignet:**
	359	+
	360	+* neue Features mit Designentscheidungen
	361	+* komplexe Logik oder Algorithmen
	362	+* Refactorings
	363	+* Code, bei dem Unsicherheit besteht
	364	+
	365	+**Weniger geeignet:**
	366	+
	367	+* sehr kleine oder triviale Änderungen
	368	+* reine Formatierungsänderungen
	369	+* sehr große, unstrukturierte Codebereiche
	370	+
	371	+----
	372	+
	373	+== 🗣️ Feedback-Regeln ==
	374	+
	375	+=== ✔️ Gutes Feedback ist: ===
	376	+
	377	+* konkret („Die Methode ist schwer lesbar, weil …“)
	378	+* begründet („… dadurch wird der Ablauf schwer nachvollziehbar“)
	379	+* konstruktiv („Man könnte hier …“)
	380	+
	381	+=== ❌ Vermeidet: ===
	382	+
	383	+* pauschale Aussagen („Das ist schlecht“)
	384	+* persönliche Kritik
	385	+* Diskussionen ohne Bezug zum Code
	386	+
	387	+----
	388	+
	389	+== ⚠️ Typische Probleme ==
	390	+
	391	+* **Zu viel Code:** → stärker eingrenzen
	392	+* **Alle schweigen:** → gezielte Fragen stellen
	393	+* **Einzelne dominieren:** → Moderator:in steuert aktiv
	394	+* **Diskussion driftet ab:** → Fokus wieder auf Code lenken
	395	+
	396	+----
	397	+
	398	+== 🧭 Minimal-Regeln ==
	399	+
	400	+1. Es findet **regelmäßig ein Gruppenreview** statt
	401	+1. Es wird **nur ein überschaubarer Codeausschnitt** betrachtet
	402	+1. Eine Person stellt den Code vor
	403	+1. Die Gruppe diskutiert strukturiert
	404	+1. Am Ende werden **konkrete Erkenntnisse festgehalten**
	405	+
	406	+----
	407	+
	408	+== 💡 Hinweis ==
	409	+
	410	+Das Gruppenreview ist eine **Lerngelegenheit**.
	411	+Bringt gerne auch Code mit, bei dem ihr unsicher seid – genau dort entsteht oft die beste Diskussion.
	412	+
	413	+----