Changes for page Anforderungen Gruppen

Summary

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

Details

Page properties

Content

...	...	@@ -234,3 +234,186 @@
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	+----
	256	+
	257	+== Organisation ==
	258	+
	259	+* Durchführung: **1× pro Woche**
	260	+* Dauer: **30–60 Minuten**
	261	+* Pro Termin: Vorstellung von **1–2 ausgewählten Codeausschnitten**
	262	+
	263	+----
	264	+
	265	+== 👤 Rollen im Review ==
	266	+
	267	+=== 🧑‍💻 Autor:in ===
	268	+
	269	+* stellt den Code vor
	270	+* (((
	271	+erklärt:
	272	+
	273	+* Ziel und Kontext
	274	+* wichtige Designentscheidungen
	275	+* ggf. offene Fragen oder Unsicherheiten
	276	+)))
	277	+
	278	+=== 🔍 Gruppe (Reviewer) ===
	279	+
	280	+* stellt Verständnisfragen
	281	+* gibt Feedback
	282	+* diskutiert Alternativen
	283	+
	284	+=== 🎯 Moderator:in ===
	285	+
	286	+* achtet auf Zeit und Struktur
	287	+* sorgt dafür, dass alle beteiligt werden
	288	+* verhindert Abschweifen
	289	+
	290	+👉 Die Rollen sollen innerhalb der Gruppe **regelmäßig rotieren**.
	291	+
	292	+----
	293	+
	294	+== 🔄 Ablauf eines Gruppenreviews ==
	295	+
	296	+=== 1. Vorbereitung (Autor:in) ===
	297	+
	298	+* Wählt einen **überschaubaren Codeausschnitt** (keine sehr großen Änderungen)
	299	+* (((
	300	+Fokus z. B. auf:
	301	+
	302	+* interessante Logik
	303	+* Architekturentscheidungen
	304	+* schwierige oder unklare Stellen
	305	+)))
	306	+* (((
	307	+Bereitet **2–3 konkrete Fragen** vor, z. B.:
	308	+
	309	+* „Ist diese Struktur sinnvoll?“
	310	+* „Wie würdet ihr das testen?“
	311	+* „Gibt es eine einfachere Lösung?“
	312	+)))
	313	+
	314	+----
	315	+
	316	+=== 2. Vorstellung (ca. 5–10 Minuten) ===
	317	+
	318	+* (((
	319	+kurzer Überblick:
	320	+
	321	+* Was macht der Code?
	322	+* Wo ist er im System eingeordnet?
	323	+)))
	324	+* keine detaillierte Zeilen-für-Zeilen-Erklärung
	325	+
	326	+----
	327	+
	328	+=== 3. Gemeinsames Review (ca. 20–40 Minuten) ===
	329	+
	330	+Diskutiert den Code anhand folgender Leitfragen:
	331	+
	332	+==== 🧠 Verständlichkeit ====
	333	+
	334	+* Ist der Code gut nachvollziehbar?
	335	+* Welche Stellen sind schwer verständlich?
	336	+
	337	+==== 🏗️ Design ====
	338	+
	339	+* Ist die Struktur sinnvoll gewählt?
	340	+* Gibt es einfachere oder klarere Alternativen?
	341	+
	342	+==== 🔁 Wartbarkeit ====
	343	+
	344	+* Ist der Code leicht erweiterbar?
	345	+* Gibt es unnötige Komplexität?
	346	+
	347	+==== 🧪 Testbarkeit ====
	348	+
	349	+* Wie könnte man den Code testen?
	350	+* Sind relevante Tests vorhanden oder ableitbar?
	351	+
	352	+----
	353	+
	354	+=== 4. Fazit (ca. 5 Minuten) ===
	355	+
	356	+* Was war gut?
	357	+* Was kann verbessert werden?
	358	+* Welche Erkenntnisse nehmen wir als Team mit?
	359	+
	360	+----
	361	+
	362	+== 🧩 Geeignete Inhalte für das Gruppenreview ==
	363	+
	364	+**Gut geeignet:**
	365	+
	366	+* neue Features mit Designentscheidungen
	367	+* komplexe Logik oder Algorithmen
	368	+* Refactorings
	369	+* Code, bei dem Unsicherheit besteht
	370	+
	371	+**Weniger geeignet:**
	372	+
	373	+* sehr kleine oder triviale Änderungen
	374	+* reine Formatierungsänderungen
	375	+* sehr große, unstrukturierte Codebereiche
	376	+
	377	+----
	378	+
	379	+== 🗣️ Feedback-Regeln ==
	380	+
	381	+=== ✔️ Gutes Feedback ist: ===
	382	+
	383	+* konkret („Die Methode ist schwer lesbar, weil …“)
	384	+* begründet („… dadurch wird der Ablauf schwer nachvollziehbar“)
	385	+* konstruktiv („Man könnte hier …“)
	386	+
	387	+=== ❌ Vermeidet: ===
	388	+
	389	+* pauschale Aussagen („Das ist schlecht“)
	390	+* persönliche Kritik
	391	+* Diskussionen ohne Bezug zum Code
	392	+
	393	+----
	394	+
	395	+== ⚠️ Typische Probleme ==
	396	+
	397	+* **Zu viel Code:** → stärker eingrenzen
	398	+* **Alle schweigen:** → gezielte Fragen stellen
	399	+* **Einzelne dominieren:** → Moderator:in steuert aktiv
	400	+* **Diskussion driftet ab:** → Fokus wieder auf Code lenken
	401	+
	402	+----
	403	+
	404	+== 🧭 Minimal-Regeln ==
	405	+
	406	+1. Es findet **regelmäßig ein Gruppenreview** statt
	407	+1. Es wird **nur ein überschaubarer Codeausschnitt** betrachtet
	408	+1. Eine Person stellt den Code vor
	409	+1. Die Gruppe diskutiert strukturiert
	410	+1. Am Ende werden **konkrete Erkenntnisse festgehalten**
	411	+
	412	+----
	413	+
	414	+== 💡 Hinweis ==
	415	+
	416	+Das Gruppenreview ist eine **Lerngelegenheit**.
	417	+Bringt gerne auch Code mit, bei dem ihr unsicher seid – genau dort entsteht oft die beste Diskussion.
	418	+
	419	+----