Changes for page Anforderungen Gruppen

Last modified by Marco Grawunder on 2026/07/28 16:09

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Children
- Content
- Comments
- Attachments (7)
- History
- Information
- Likes

From 29.1 to 28.1 From 29.3 to 29.2

From version 29.2

edited by Marco Grawunder
on 2026/04/20 10:39

Change comment: Auto-saved during real-time collaboration

To version 29.1

edited by Marco Grawunder
on 2025/11/05 16:28

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -234,186 +234,3 @@
  ** Tickets (wer macht was)
  ** Leitung/Protokoll (Liste!)
  * 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 …)
--
--
--
--= Gruppenweites Code Review (Team-Review) =
--
--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**.
--
--== Ziel des Gruppenreviews ==
--
--Das gruppenweite Review soll dabei helfen:
--
--* die **gesamte Codebasis besser zu verstehen**
--* **Designentscheidungen nachvollziehen und hinterfragen zu können**
--* voneinander zu lernen (gute Lösungen, typische Probleme)
--* Wissen im Team zu verteilen (kein „Ein-Personen-Code“)
--
--👉 Wichtig: Es geht **nicht darum, jemanden zu bewerten**, sondern gemeinsam besseren Code zu entwickeln.
--
------
--
--== Organisation ==
--
--* Durchführung: **1× pro Woche**
--* Dauer: **30–60 Minuten**
--* Pro Termin: Vorstellung von **1–2 ausgewählten Codeausschnitten**
--
------
--
--== 👤 Rollen im Review ==
--
--=== 🧑‍💻 Autor:in ===
--
--* stellt den Code vor
--* (((
--erklärt:
--
--* Ziel und Kontext
--* wichtige Designentscheidungen
--* ggf. offene Fragen oder Unsicherheiten
--)))
--
--=== 🔍 Gruppe (Reviewer) ===
--
--* stellt Verständnisfragen
--* gibt Feedback
--* diskutiert Alternativen
--
--=== 🎯 Moderator:in ===
--
--* achtet auf Zeit und Struktur
--* sorgt dafür, dass alle beteiligt werden
--* verhindert Abschweifen
--
--👉 Die Rollen sollen innerhalb der Gruppe **regelmäßig rotieren**.
--
------
--
--== 🔄 Ablauf eines Gruppenreviews ==
--
--=== 1. Vorbereitung (Autor:in) ===
--
--* Wählt einen **überschaubaren Codeausschnitt** (keine sehr großen Änderungen)
--* (((
--Fokus z. B. auf:
--
--* interessante Logik
--* Architekturentscheidungen
--* schwierige oder unklare Stellen
--)))
--* (((
--Bereitet **2–3 konkrete Fragen** vor, z. B.:
--
--* „Ist diese Struktur sinnvoll?“
--* „Wie würdet ihr das testen?“
--* „Gibt es eine einfachere Lösung?“
--)))
--
------
--
--=== 2. Vorstellung (ca. 5–10 Minuten) ===
--
--* (((
--kurzer Überblick:
--
--* Was macht der Code?
--* Wo ist er im System eingeordnet?
--)))
--* keine detaillierte Zeilen-für-Zeilen-Erklärung
--
------
--
--=== 3. Gemeinsames Review (ca. 20–40 Minuten) ===
--
--Diskutiert den Code anhand folgender Leitfragen:
--
--==== 🧠 Verständlichkeit ====
--
--* Ist der Code gut nachvollziehbar?
--* Welche Stellen sind schwer verständlich?
--
--==== 🏗️ Design ====
--
--* Ist die Struktur sinnvoll gewählt?
--* Gibt es einfachere oder klarere Alternativen?
--
--==== 🔁 Wartbarkeit ====
--
--* Ist der Code leicht erweiterbar?
--* Gibt es unnötige Komplexität?
--
--==== 🧪 Testbarkeit ====
--
--* Wie könnte man den Code testen?
--* Sind relevante Tests vorhanden oder ableitbar?
--
------
--
--=== 4. Fazit (ca. 5 Minuten) ===
--
--* Was war gut?
--* Was kann verbessert werden?
--* Welche Erkenntnisse nehmen wir als Team mit?
--
------
--
--== 🧩 Geeignete Inhalte für das Gruppenreview ==
--
--**Gut geeignet:**
--
--* neue Features mit Designentscheidungen
--* komplexe Logik oder Algorithmen
--* Refactorings
--* Code, bei dem Unsicherheit besteht
--
--**Weniger geeignet:**
--
--* sehr kleine oder triviale Änderungen
--* reine Formatierungsänderungen
--* sehr große, unstrukturierte Codebereiche
--
------
--
--== 🗣️ Feedback-Regeln ==
--
--=== ✔️ Gutes Feedback ist: ===
--
--* konkret („Die Methode ist schwer lesbar, weil …“)
--* begründet („… dadurch wird der Ablauf schwer nachvollziehbar“)
--* konstruktiv („Man könnte hier …“)
--
--=== ❌ Vermeidet: ===
--
--* pauschale Aussagen („Das ist schlecht“)
--* persönliche Kritik
--* Diskussionen ohne Bezug zum Code
--
------
--
--== ⚠️ Typische Probleme ==
--
--* **Zu viel Code:** → stärker eingrenzen
--* **Alle schweigen:** → gezielte Fragen stellen
--* **Einzelne dominieren:** → Moderator:in steuert aktiv
--* **Diskussion driftet ab:** → Fokus wieder auf Code lenken
--
------
--
--== 🧭 Minimal-Regeln ==
--
--1. Es findet **regelmäßig ein Gruppenreview** statt
--1. Es wird **nur ein überschaubarer Codeausschnitt** betrachtet
--1. Eine Person stellt den Code vor
--1. Die Gruppe diskutiert strukturiert
--1. Am Ende werden **konkrete Erkenntnisse festgehalten**
--
------
--
--== 💡 Hinweis ==
--
--Das Gruppenreview ist eine **Lerngelegenheit**.
--Bringt gerne auch Code mit, bei dem ihr unsicher seid – genau dort entsteht oft die beste Diskussion.
--
------

Changes for page Anforderungen Gruppen

Summary

Details

Applications

Navigation