Wiki source code of Projektarbeit
Version 11.1 by Marco Grawunder on 2026/08/26 09:45
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{info}} | ||
| 2 | Diese Seite beschreibt die **Organisation und Zusammenarbeit innerhalb der Projektgruppe**. Dazu gehören Projektmanagement, gemeinsame Arbeitsregeln, individuelle Verantwortungsbereiche, Projekttagebuch, wechselnde Sitzungsaufgaben und das gruppenweite Code-Review. | ||
| 3 | {{/info}} | ||
| 4 | |||
| 5 | {{toc/}} | ||
| 6 | |||
| 7 | = Projektmanagement organisieren = | ||
| 8 | |||
| 9 | * Organisieren Sie Ihr Projekt bzw. Team, | ||
| 10 | ** verteilen Sie in der zweiten Woche die [[Einzelaufgaben>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]], | ||
| 11 | ** definieren Sie eine Reihenfolge für die Übernahme der Moderation und des Protokolls (z.B. nach Alphabet) | ||
| 12 | ** die Tagesordnung ist vom Moderator mindestens einen Tag vorher zu erstellen (dafür ggf. die Gruppe nach weiteren TOPs fragen) | ||
| 13 | ** definieren Sie Standards für Dokumente (LaTeX, UTF-8, ...) | ||
| 14 | ** Führen Sie ein [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] (im Wiki) | ||
| 15 | * Dokumentieren Sie immer alle Ergebnisse der Gruppe, wie | ||
| 16 | ** Protokolle, | ||
| 17 | ** Ausarbeitungen, | ||
| 18 | ** Präsentationen, | ||
| 19 | ** Software-Dokumente, etc. | ||
| 20 | * mit einer Zuordnung zu Personen in GitLab. **Verwenden Sie dafür die Wiki-Funktion von Gitlab** ([[https:~~/~~/docs.gitlab.com/user/project/wiki/>>https://docs.gitlab.com/user/project/wiki/]]). | ||
| 21 | * Geben Sie die Einzelaufgaben an | ||
| 22 | * Stellen Sie ein Gruppenbild (mit Namen) ein! Ideal ist es für mich und die Tutoren, wenn in dem Bild die Namen direkt als Text enthalten sind. | ||
| 23 | * Überlegen Sie sich für Ihre Aufgaben eine "Definition of Ready" und eine "Definition of Done", d.h. was muss für eine Aufgabe erledigt sein, bevor sie als erledigt angesehen werden kann. (siehe z.B. [[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]]) | ||
| 24 | * Erstellen Sie basierend auf den Vorgaben der Veranstaltung eine Produktvision. (vgl. z.B. [[https:~~/~~/www.wibas.com/scrum/product-vision/de)>>url:https://www.wibas.com/scrum/product-vision/de]] | ||
| 25 | |||
| 26 | Sprints allein gewährleisten noch keine langfristige Orientierung. Definieren Sie deshalb zusätzliche **Meilensteine**, zu denen konkrete fachliche Ergebnisse erreicht sein sollen. Einige sind vorgegeben (vgl. [[Meilensteine>>doc:Main.Softwareentwicklung.WebHome||anchor="HVorgegebeneMeilensteine"]]). Verwenden Sie zur Meilensteindefinition nicht nur die Präsentationstermine! | ||
| 27 | |||
| 28 | = Zusammenarbeit und Verhaltensregeln = | ||
| 29 | |||
| 30 | * **Allgemeine Regeln innerhalb der Gruppe** | ||
| 31 | ** alle | ||
| 32 | *** sind vorbereitet und nehmen aktiv teil | ||
| 33 | *** erledigen ihre Aufgaben vollständig und pünktlich | ||
| 34 | *** übernehmen aktiv Aufgaben | ||
| 35 | *** beachten Gruppenstandards | ||
| 36 | *** sind bereit, ihre Arbeit auf Fehler untersuchen zu lassen | ||
| 37 | **** Grundsätzliche Kritik bitte zunächst unmittelbar an eine Person, dann Gruppe, dann Tutor, dann Dozent | ||
| 38 | **** Es gibt in jeder Gruppe einen Konfliktbeauftragten (siehe [[Anforderungen Einzelleistungen>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]]) geben | ||
| 39 | *** Diskriminierung wird in keinster Form geduldet! (siehe [[Spielregeln>>doc:Main.Projektarbeit.WebHome||anchor="HZusammenarbeitundVerhaltensregeln"]]) | ||
| 40 | *** Konsequenzen bei Nichterfüllung von übertragenen Aufgaben festlegen? | ||
| 41 | ** Jeder übernimmt Teile bei | ||
| 42 | *** Dokumentation und | ||
| 43 | *** Implementierung | ||
| 44 | *** keine „Doku-Sklaven“! | ||
| 45 | * **Kommunikationsregeln innerhalb der Gruppe** | ||
| 46 | ** Es sollte stets ein respektvoller Umgangston herrschen. | ||
| 47 | ** Jedes Gruppenmitglied hat das Recht auf freie Meinungsäußerung und wird in Gesprächen, | ||
| 48 | Diskussionen oder Vorstellungen nicht unterbrochen. | ||
| 49 | ** Gespräche und Diskussionen jeglicher Art finden stets auf einer sachlichen Ebene statt. Beleidigungen | ||
| 50 | jeglicher Form werden nicht toleriert. | ||
| 51 | ** Zwischenmenschliche Probleme werden direkt offen und nicht hinter dem Rücken des betreffenden | ||
| 52 | Gruppenmitgliedes kommuniziert. | ||
| 53 | * **Verhaltensregeln innerhalb der Gruppe** | ||
| 54 | ** Alle Gruppenmitglieder werden stets mit Respekt behandelt. | ||
| 55 | ** Kritik wird stets konstruktiv auf einer sachlichen Ebene geäußert. | ||
| 56 | ** Im Sinne der Projektarbeit kann der Fall eintreten, dass persönliche Ansichten zurückgestellt | ||
| 57 | werden müssen. Es wird somit ein hohes Maß an Kompromissbereitschaft vorausgesetzt. | ||
| 58 | ** Meinungen, welche von den eigenen Ansichten abweichen, werden stets toleriert. | ||
| 59 | ** Bei verursachten Fehlern wird stets die volle Verantwortung für das eigene Handeln übernommen. | ||
| 60 | |||
| 61 | == Keine Tolerierung von Diskriminierung jeglicher Art == | ||
| 62 | |||
| 63 | Leider sind wir im Rahmen des „Software Projektes“ auf eine Reihe von Vorfällen aufmerksam geworden, bei denen es um sexualisiertes Verhalten oder Herabwürdigung aufgrund des Geschlechtes geht. Diese Vorfälle reichen von vermeintlich harmlosen „dummen Sprüchen“ bis hin zu direktem unerwünschtem körperlichem Kontakt. | ||
| 64 | |||
| 65 | Ich möchte noch einmal ausdrücklich darauf hinweisen, dass wir als Department für Informatik und natürlich auch als Universität Oldenburg jede Art von Diskriminierung in keiner Weise tolerieren. Ein solches Vorkommnis kann bis zum Ausschluss von der Veranstaltung, in weitergehenden Fällen sogar bis zur Exmatrikulation führen! | ||
| 66 | |||
| 67 | Wir wissen, dass dies in der großen Masse lediglich Einzelfälle sind, und es geht auf keinen Fall darum, das gesamte „Software Projekt“ zu beschuldigen. Wir möchten jedoch jeden Einzelnen und jede Einzelne dafür sensibilisieren, auf solche Situationen zu achten und gegebenenfalls entschärfend einzuwirken. | ||
| 68 | |||
| 69 | Die Betroffenen bitte ich darum, das Thema nicht mit sich herumzutragen, sondern die möglichen Kontaktmöglichkeiten zu nutzen. Nur dann, wenn das Thema offensiv angegangen wird, besteht die Chance, dass die Sensibilität für das Thema steigt! | ||
| 70 | |||
| 71 | Nachfolgend werden einige Informationen über Diskriminierung & Gewalt, dessen "Alarmglocken", Präventionsmöglichkeiten, Handlungsempfehlungen und die Aufgaben der Erstberatung zur Verfügung gestellt. | ||
| 72 | |||
| 73 | [[Alarmglocken>>attach:Alarmglocken.pdf]] | ||
| 74 | |||
| 75 | [[Aufgaben Erstberatung>>attach:Aufgaben Erstberatung.pdf]] | ||
| 76 | |||
| 77 | [[Handlungsempfehlungen Bystander>>attach:Handlungsempfehlungen Bystander_14.04.23.pdf]] | ||
| 78 | |||
| 79 | [[Prävention>>attach:Prävention.pdf]] | ||
| 80 | |||
| 81 | [[Sexualisierte Diskriminierung und Gewalt>>attach:Sexualisierte Diskriminierung und Gewalt.pdf]] | ||
| 82 | |||
| 83 | **Kontaktmöglichkeiten** | ||
| 84 | |||
| 85 | * Tutor/Tutorin der Gruppe | ||
| 86 | * Dozent der Veranstaltung | ||
| 87 | * Fachschaft Informatik: [[https:~~/~~/fachschaft-informatik.de/>>url:https://fachschaft-informatik.de/]] | ||
| 88 | * Dezentrale Gleichstellungbeauftragte der Informatik: [[https:~~/~~/uol.de/informatik/department/gremien-beauftragte/beauftragte>>url:https://uol.de/informatik/department/gremien-beauftragte/beauftragte]] | ||
| 89 | * Direktor/Direktorin des Departments: [[https:~~/~~/uol.de/informatik>>url:https://uol.de/informatik]] | ||
| 90 | * Erstanlaufstelle Antidiskriminierung des AStA: Donnerstags: 10:30 - 13:30 Uhr de/eng/farsi im AStA Trakt, Raum M1-157, [[beratung@asta-uol.de>>mailto:beratung@asta-uol.de||style="background-color: rgb(255, 255, 255);"]], | ||
| 91 | * conTakt: [[https:~~/~~/uol.de/contakt-beratungsstelle>>url:https://uol.de/contakt-beratungsstelle]] | ||
| 92 | |||
| 93 | = Individuelle Verantwortungsbereiche und Einzelaufgaben = | ||
| 94 | |||
| 95 | Neben der eigentlichen Softwareentwicklung gibt es spezielle Aufgaben, die von den Teammitglieder als Querschnittsaufgaben übernommen werden müssen. Diese Spezialisten und Verantwortlichen arbeiten sich in das Thema ein, beraten die Mitglieder der Gruppe und sorgen dafür, dass die Anforderungen an diese Aufgabe eingehalten werden. Die Aufgaben können dabei von einzelnen Personen oder auch zu zweit übernommen werden. Die Rollen sind als **Querschnitts- und Serviceaufgaben** zu verstehen. Wenn in einem Zeitraum für einen Verantwortungsbereich wenig Bedarf besteht, soll nicht künstlich Arbeit erzeugt werden; die Person unterstützt dann die reguläre Projektarbeit oder andere Verantwortungsbereiche. Entscheidend ist, dass es für das jeweilige Thema eine klar benannte Person gibt, die sich zuständig fühlt, bei Fragen unterstützen kann und darauf achtet, dass die vereinbarten Anforderungen berücksichtigt werden. In den Einschätzungen der Tutoren gibt es dafür auch ein Feld, welche die Felder "erfüllt", "nicht erfüllt" oder "war nicht notwendig" enthält. | ||
| 96 | |||
| 97 | Die kurzen Einführungen zu den Verantwortungsbereichen des ersten Blocks sollen im ersten Semester, möglichst innerhalb der ersten sieben Wochen, durchgeführt werden. | ||
| 98 | |||
| 99 | Die Einzelaufgaben sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet. | ||
| 100 | |||
| 101 | == Kurzvortrag == | ||
| 102 | |||
| 103 | Jeder muss einen Kurzvortrag halten, i.d.R. bezogen auf die Rolle | ||
| 104 | |||
| 105 | * Umfang ca. 10 Minuten | ||
| 106 | * Bezug auf die Gruppe und das SWP | ||
| 107 | * Vortrag muss hinterher im Gitlab-Wiki abgelegt werden | ||
| 108 | |||
| 109 | == Verantwortungsbereiche / Rollen == | ||
| 110 | |||
| 111 | {{info}} | ||
| 112 | Der Aufwand der Verantwortungsbereiche ist unterschiedlich und kann sich im Projektverlauf verändern. Die Einstufungen sind daher nur als Orientierung zu verstehen. | ||
| 113 | {{/info}} | ||
| 114 | |||
| 115 | {{expandable summary="Scrum-Master"}} | ||
| 116 | * Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt | ||
| 117 | * Kurze Zusammenfassung zu [[Scrum>>doc:Main.Scrum.WebHome||anchor="HEinkurzerDCberblick"]], ausführlicher in den Folien der VL und in [[Scrum im Detail>>doc:Main.Scrum.WebHome||anchor="HImDetail"]]. | ||
| 118 | * Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs). | ||
| 119 | * Diese Rolle ist mit die wichtigste Rolle im SWP und verlangt durchgehend sehr viel Kapazität. Ein Scrum-Master ist aus diesem Grund typischerweise weniger (aber trotzdem noch) an der Implementierung beteiligt. | ||
| 120 | * Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen. | ||
| 121 | * Der Scrum-Master kann während des gesamten Projekts hinweg an einem monatlichen **Scrum-Master-Treffen** teilnehmen (nähere Informationen werden im Workshop mitgeteilt) - die Teilnahme ist empfohlen. | ||
| 122 | * Aufwand: Sehr hoch | ||
| 123 | {{/expandable}} | ||
| 124 | |||
| 125 | {{expandable summary="GitLab, Projektplanung und Product Owner"}} | ||
| 126 | * Scrum hat das Problem, dass man beliebig "herumiterieren" kann. Diese Rolle soll dafür sorgen, dass das "Große und Ganze" nicht aus den Augen verloren geht. Die grundlegend definierten Meilensteine sollten dabei um weitere Meilensteine ergänzt werden. Diese Meilensteine sollen dabei helfen, Sprintziele zu definieren. | ||
| 127 | * Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, ein vollständiges Gantt-Diagramm über das komplette Semester zu erstellen. | ||
| 128 | * [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] führen | ||
| 129 | * Stundenzettelpflege überwachen | ||
| 130 | * Weiterhin soll diese Person als Ansprechpartner für GitLab dienen, d.h. sie sollte sich besonders informieren und ggf. bei Fragen und Problemen beratend zur Seite stehen. | ||
| 131 | * Die Person übernimmt gemeinsam mit dem Tutor wesentliche Aufgaben des Product Owners: Sie achtet darauf, dass ausreichend vorbereitete Einträge im Product Backlog vorhanden sind und unterstützt deren Priorisierung. | ||
| 132 | * Sie achtet darauf, dass für die Arbeit im Sprint die vereinbarte Definition of Done berücksichtigt wird. | ||
| 133 | * Sie organisiert das Backlog Refinement. Dazu können kleinere, wechselnd zusammengesetzte Teilgruppen (**Ticket-Task-Force**) neue Tickets formulieren und Beschreibungen verbessern. Die Teilnehmer der Teilgruppen dürfen nicht über den ganzen Durchgang gleich bleiben sondern muss im Laufe der Zeit wechseln. Sollte die Gruppe sich gegen eine Ticket-Task-Force entscheiden, können die Tickets und Ticketbeschreibungen auch in der gesamten Gruppe gemeinsam erarbeitet werden. | ||
| 134 | * Aufwand: Hoch | ||
| 135 | {{/expandable}} | ||
| 136 | |||
| 137 | {{expandable summary="Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring"}} | ||
| 138 | * Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner | ||
| 139 | * Aufwand: Kann sehr variieren | ||
| 140 | * Bei größeren Gruppen kann der Verantwortungsbereich sinnvoll in **API/Kommunikation (OpenAPI, REST, WebSockets)** und **Spring/serverseitige Architektur** aufgeteilt werden. | ||
| 141 | {{/expandable}} | ||
| 142 | |||
| 143 | {{expandable summary="Git/GitLab und Reviewbeauftragter"}} | ||
| 144 | * Der Inhaber kennt sich mit Git und Gitlab aus. | ||
| 145 | * Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt) | ||
| 146 | * Der Inhaber dieser Rolle sollte sich auch darum kümmern, dass der Git-Workflow (Ticket → Branch → PR → Mergen) eingehalten, dass Merge-Requests sinnvoll abgearbeitet werden und nicht zu lange liegen bleiben. | ||
| 147 | * Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben. | ||
| 148 | * Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen | ||
| 149 | * Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren. | ||
| 150 | * Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig. | ||
| 151 | * Aufwand: Mittel | ||
| 152 | {{/expandable}} | ||
| 153 | |||
| 154 | {{expandable summary="Codequalitätsbeauftragter und Patternbeauftragter"}} | ||
| 155 | * Überwachung von Codierungsstandards | ||
| 156 | * Kennt sich mit Refactorings aus | ||
| 157 | * Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus | ||
| 158 | * Kennt sich mit Werkzeugen wie SpotBugs, Checkstyle und SonarLint/SonarQube aus. | ||
| 159 | * Soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten | ||
| 160 | * Die Gruppe bei der Anwendung der Pattern unterstützen | ||
| 161 | * Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären | ||
| 162 | * Aufwand: Mittel | ||
| 163 | {{/expandable}} | ||
| 164 | |||
| 165 | {{expandable summary="Testbeauftragter"}} | ||
| 166 | * Der Testbeauftragte ist nicht dafür da, Tests zu schreiben! | ||
| 167 | * Die Person stellt ggf. Mockito und JUnit vor | ||
| 168 | * Der Testbeauftragte unterstützt die Gruppe beim Schreiben von Tests und steht bei Fragen beratend zur Verfügung. | ||
| 169 | * Die Person achtet darauf, dass Tests nicht vernachlässigt werden, betrachtet regelmäßig die vorhandene Testabdeckung und macht auf unzureichend getestete Bereiche aufmerksam. | ||
| 170 | * Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden. | ||
| 171 | * Aufwand: Mittel | ||
| 172 | {{/expandable}} | ||
| 173 | |||
| 174 | {{expandable summary="Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter"}} | ||
| 175 | * Achtet darauf, dass die erforderlichen Dokumente erstellt, kontinuierlich gepflegt und gesichert werden. Die Rolle ist **nicht** dafür zuständig, die gesamte Dokumentation allein zu schreiben. | ||
| 176 | * Erstellung/Anpassung von Vorlagen, Hilfe | ||
| 177 | * Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie | ||
| 178 | * Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden. | ||
| 179 | * Aufwand: Mittel | ||
| 180 | {{/expandable}} | ||
| 181 | |||
| 182 | {{expandable summary="Konfliktmanagement"}} | ||
| 183 | * Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten. | ||
| 184 | * Diese Rolle soll sich im Vorfeld (also bevor etwas "schief" geht), damit befassen, welche Methoden und Ansätze es gibt, in Gruppen mit solchen Konflikten umzugehen. | ||
| 185 | * Es macht Sinn, dass es jemanden zweiten gibt, der sich als Stellvertreter ebenfalls mit dieser Aufgabe befasst, falls die Person, die diese Rolle eigentlich inne hat, selber der Auslöser eines Konfliktes ist. | ||
| 186 | * Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden. | ||
| 187 | {{/expandable}} | ||
| 188 | |||
| 189 | Falls alle Rollen vergeben sind, können noch folgende ergänzend dazu kommen. | ||
| 190 | |||
| 191 | * Spielregeln | ||
| 192 | * Frontend (z.B. JavaFX oder Web-Frontends) | ||
| 193 | * Spezielle Rolle für REST, WebSockets und OpenAPI und dafür in der obigen Rolle (OpenAPI, REST und Spring) nur noch Spring | ||
| 194 | * Programmierkonzepte | ||
| 195 | ** z. B. Dependency Injection mit Spring | ||
| 196 | * DB-Zugriff: | ||
| 197 | ** Installation/Überwachung der DB | ||
| 198 | * Spezialisten für verschiedene Teilthemen: | ||
| 199 | ** Netzwerkkommunikation | ||
| 200 | ** Regeln des aktuellen Spiels | ||
| 201 | ** Weitere Frameworks | ||
| 202 | ** GUI | ||
| 203 | |||
| 204 | === Projekttagebuch === | ||
| 205 | |||
| 206 | Im Projekttagebuch werden kurz und knapp die Ergebnisse der Sprints festgehalten und der Ablauf der Projekte als Ganzes dokumentiert. | ||
| 207 | |||
| 208 | Für jeden Sprint wird hier geschrieben, | ||
| 209 | |||
| 210 | * welche Stories umgesetzt wurden. | ||
| 211 | * wie das Review gelaufen ist. | ||
| 212 | * wie die Retrospektive gelaufen ist und welche Maßnahmen ergriffen worden sind, um Probleme im nächsten Sprint zu reduzieren. | ||
| 213 | |||
| 214 | Außerdem: | ||
| 215 | |||
| 216 | * Wann wurden Meilensteine erreicht | ||
| 217 | * Wann wurden Meilensteine verschoben und (ganz wichtig!) was waren die Gründe dafür | ||
| 218 | * Wann wurden andere wichtige Zwischenziele erreicht | ||
| 219 | * Welche besonderen Dinge hat es gegeben, die wesentlichen Einfluss auf das Projekt oder die Gruppe hatten | ||
| 220 | |||
| 221 | == Wechselnde Aufgaben innerhalb der Gruppe == | ||
| 222 | |||
| 223 | Diese Aufgaben wechseln wöchentlich: | ||
| 224 | |||
| 225 | * Sitzungsleitung und Moderation | ||
| 226 | ** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master | ||
| 227 | ** Tagesordnung definieren (vorher)!! | ||
| 228 | ** Ein Moderator ist dafür zuständig, dass die Sitzungen geregelt ablaufen, d.h. insbesondere muss ein Moderator darauf achten, dass die Teilnehmer sich an die Regeln (siehe: [[Spielregeln>>doc:Main.Projektarbeit.WebHome||anchor="HZusammenarbeitundVerhaltensregeln"]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen. | ||
| 229 | Hier gibt es weitere Hinweise zu der Aufgabe eines Moderators: [[https:~~/~~/www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html >>url:https://www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html%C2%A0]] | ||
| 230 | * Protokollführung | ||
| 231 | ** Erstellung eines Protokolls der Gruppensitzung | ||
| 232 | ** Hier reicht i.d.R. ein Ergebnisprotokoll | ||
| 233 | ** Protokolle müssen direkt im Wiki abgelegt sein (nicht als PDF, damit sind die einfacher lesbar) | ||
| 234 | * Zu Beginn jeder Gruppensitzung („Daily Scrum“): | ||
| 235 | ** findet ein kurzes „Briefing“ („Blitzlicht“) statt, in der jede/r berichtet, was sie/er in der letzten Woche für das Projekt getan hat. | ||
| 236 | * Am Ende jeder Sitzung neue Aufgabenverteilung | ||
| 237 | ** Tickets (wer macht was) | ||
| 238 | ** Leitung/Protokoll (Liste!) | ||
| 239 | * 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 …) | ||
| 240 | |||
| 241 | = Gruppenweites Code-Review (Team-Review) = | ||
| 242 | |||
| 243 | {{info}} | ||
| 244 | **Kurzfassung:** Mindestens einmal im Projekt wird ein nicht trivialer Codebereich gemeinsam reviewt. Der Kontext wird vorbereitet, die gesamte Gruppe beteiligt sich am Review, Ergebnisse werden dokumentiert und konkrete Verbesserungsmaßnahmen anschließend nachverfolgt. | ||
| 245 | {{/info}} | ||
| 246 | |||
| 247 | 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**. | ||
| 248 | |||
| 249 | {{expandable summary="Detaillierte Anleitung zum Gruppenreview"}} | ||
| 250 | == Ziel des Gruppenreviews == | ||
| 251 | |||
| 252 | Das gruppenweite Review soll dabei helfen: | ||
| 253 | |||
| 254 | * die **gesamte Codebasis besser zu verstehen** | ||
| 255 | * **Designentscheidungen nachvollziehen und hinterfragen zu können** | ||
| 256 | * voneinander zu lernen (gute Lösungen, typische Probleme) | ||
| 257 | * Wissen im Team zu verteilen (kein „Ein-Personen-Code“) | ||
| 258 | |||
| 259 | Wichtig: Es geht **nicht darum, jemanden zu bewerten**, sondern gemeinsam besseren Code zu entwickeln. | ||
| 260 | |||
| 261 | == Organisation == | ||
| 262 | |||
| 263 | * Durchführung: **mindestens einmal im Semester** | ||
| 264 | * Dauer: **30–60 Minuten** | ||
| 265 | * Vorstellung von **1–2 ausgewählten Codeausschnitten** | ||
| 266 | |||
| 267 | == Rollen im Review == | ||
| 268 | |||
| 269 | === Autor:in === | ||
| 270 | |||
| 271 | * stellt den Code vor | ||
| 272 | * ((( | ||
| 273 | erklärt: | ||
| 274 | |||
| 275 | * Ziel und Kontext | ||
| 276 | * wichtige Designentscheidungen | ||
| 277 | * ggf. offene Fragen oder Unsicherheiten | ||
| 278 | ))) | ||
| 279 | |||
| 280 | === Gruppe (Reviewer) === | ||
| 281 | |||
| 282 | * stellt Verständnisfragen | ||
| 283 | * gibt Feedback | ||
| 284 | * diskutiert Alternativen | ||
| 285 | |||
| 286 | === Moderator:in === | ||
| 287 | |||
| 288 | * achtet auf Zeit und Struktur | ||
| 289 | * sorgt dafür, dass alle beteiligt werden | ||
| 290 | * verhindert Abschweifen | ||
| 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 | === 2. Vorstellung (ca. 5–10 Minuten) === | ||
| 315 | |||
| 316 | * ((( | ||
| 317 | kurzer Überblick: | ||
| 318 | |||
| 319 | * Was macht der Code? | ||
| 320 | * Wo ist er im System eingeordnet? | ||
| 321 | ))) | ||
| 322 | * keine detaillierte Zeilen-für-Zeilen-Erklärung | ||
| 323 | |||
| 324 | === 3. Gemeinsames Review (ca. 20–40 Minuten) === | ||
| 325 | |||
| 326 | Diskussion des Codes anhand folgender Leitfragen: | ||
| 327 | |||
| 328 | ==== Verständlichkeit ==== | ||
| 329 | |||
| 330 | * Ist der Code gut nachvollziehbar? | ||
| 331 | * Welche Stellen sind schwer verständlich? | ||
| 332 | |||
| 333 | ==== Design ==== | ||
| 334 | |||
| 335 | * Ist die Struktur sinnvoll gewählt? | ||
| 336 | * Gibt es einfachere oder klarere Alternativen? | ||
| 337 | |||
| 338 | ==== Wartbarkeit ==== | ||
| 339 | |||
| 340 | * Ist der Code leicht erweiterbar? | ||
| 341 | * Gibt es unnötige Komplexität? | ||
| 342 | |||
| 343 | ==== Testbarkeit ==== | ||
| 344 | |||
| 345 | * Wie könnte man den Code testen? | ||
| 346 | * Sind relevante Tests vorhanden oder ableitbar? | ||
| 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 | == Geeignete Inhalte für das Gruppenreview == | ||
| 355 | |||
| 356 | **Gut geeignet:** | ||
| 357 | |||
| 358 | * neue Features mit Designentscheidungen | ||
| 359 | * komplexe Logik oder Algorithmen | ||
| 360 | * Refactorings | ||
| 361 | * Code, bei dem Unsicherheit besteht | ||
| 362 | |||
| 363 | **Weniger geeignet:** | ||
| 364 | |||
| 365 | * sehr kleine oder triviale Änderungen | ||
| 366 | * reine Formatierungsänderungen | ||
| 367 | * sehr große, unstrukturierte Codebereiche | ||
| 368 | |||
| 369 | == Feedback-Regeln == | ||
| 370 | |||
| 371 | === Gutes Feedback ist: === | ||
| 372 | |||
| 373 | * konkret („Die Methode ist schwer lesbar, weil …“) | ||
| 374 | * begründet („… dadurch wird der Ablauf schwer nachvollziehbar“) | ||
| 375 | * konstruktiv („Man könnte hier …“) | ||
| 376 | |||
| 377 | === Vermeidet: === | ||
| 378 | |||
| 379 | * pauschale Aussagen („Das ist schlecht“) | ||
| 380 | * persönliche Kritik | ||
| 381 | * Diskussionen ohne Bezug zum Code | ||
| 382 | |||
| 383 | == Typische Probleme == | ||
| 384 | |||
| 385 | * **Zu viel Code:** → stärker eingrenzen | ||
| 386 | * **Alle schweigen:** → gezielte Fragen stellen | ||
| 387 | * **Einzelne dominieren:** → Moderator:in steuert aktiv | ||
| 388 | * **Diskussion driftet ab:** → Fokus wieder auf Code lenken | ||
| 389 | |||
| 390 | == Minimal-Regeln == | ||
| 391 | |||
| 392 | 1. Es wird **nur ein überschaubarer Codeausschnitt** betrachtet | ||
| 393 | 1. Eine Person stellt den Code vor | ||
| 394 | 1. Die Gruppe diskutiert strukturiert | ||
| 395 | 1. Am Ende werden **konkrete Erkenntnisse festgehalten** | ||
| 396 | |||
| 397 | == Hinweis == | ||
| 398 | |||
| 399 | Das Gruppenreview ist eine **Lerngelegenheit**. | ||
| 400 | Bringt gerne auch Code mit, bei dem ihr unsicher seid – genau dort entsteht oft die beste Diskussion. | ||
| 401 | |||
| 402 | Man kann das auch mehrmals machen. Im SWP wird es aber nur einmal verlangt. | ||
| 403 | |||
| 404 | ---- | ||
| 405 | {{/expandable}} |