Skip to Content

Changes for page Projektarbeit

Last modified by Marco Grawunder on 2026/08/26 10:15
From version 9.1
edited by Marco Grawunder
on 2026/08/25 16:29
Change comment: There is no comment for this version
To version 8.1
edited by Marco Grawunder
on 2026/08/25 15:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -104,7 +104,8 @@
104 104  Der Aufwand der Verantwortungsbereiche ist unterschiedlich und kann sich im Projektverlauf verändern. Die Einstufungen sind daher nur als Orientierung zu verstehen.
105 105  {{/info}}
106 106  
107 -{{expandable summary="Scrum-Master"}}
107 +**Scrum-Master:**
108 +
108 108  * Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
109 109  * 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"]].
110 110  * Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
... ... @@ -112,9 +112,9 @@
112 112  * Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
113 113  * 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.
114 114  * Aufwand: Sehr hoch
115 -{{/expandable}}
116 116  
117 -{{expandable summary="GitLab, Projektplanung und Product Owner"}}
117 +**GitLab, Projektplanung und Product Owner:**
118 +
118 118  * 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.
119 119  * Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, ein vollständiges Gantt-Diagramm über das komplette Semester zu erstellen.
120 120  * [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] führen
... ... @@ -124,15 +124,15 @@
124 124  * Sie achtet darauf, dass für die Arbeit im Sprint die vereinbarte Definition of Done berücksichtigt wird.
125 125  * 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.
126 126  * Aufwand: Hoch
127 -{{/expandable}}
128 128  
129 -{{expandable summary="Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring"}}
129 +**Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring:**
130 +
130 130  * Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner
131 131  * Aufwand: Kann sehr variieren
132 132  * Bei größeren Gruppen kann der Verantwortungsbereich sinnvoll in **API/Kommunikation (OpenAPI, REST, WebSockets)** und **Spring/serverseitige Architektur** aufgeteilt werden.
133 -{{/expandable}}
134 134  
135 -{{expandable summary="Git/GitLab und Reviewbeauftragter"}}
135 +**Git/GitLab und Reviewbeauftragter:**
136 +
136 136  * Der Inhaber kennt sich mit Git und Gitlab aus.
137 137  * Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
138 138  * 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.
... ... @@ -141,9 +141,9 @@
141 141  * Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
142 142  * Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig.
143 143  * Aufwand: Mittel
144 -{{/expandable}}
145 145  
146 -{{expandable summary="Codequalitätsbeauftragter und Patternbeauftragter"}}
146 +**Codequalitätsbeauftragter und Patternbeauftragter:**
147 +
147 147  * Überwachung von Codierungsstandards
148 148  * Kennt sich mit Refactorings aus
149 149  * Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
... ... @@ -152,9 +152,9 @@
152 152  * Die Gruppe bei der Anwendung der Pattern unterstützen
153 153  * Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
154 154  * Aufwand: Mittel
155 -{{/expandable}}
156 156  
157 -{{expandable summary="Testbeauftragter"}}
157 +**Testbeauftragter:**
158 +
158 158  * Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
159 159  * Die Person stellt ggf. Mockito und JUnit vor
160 160  * Der Testbeauftragte unterstützt die Gruppe beim Schreiben von Tests und steht bei Fragen beratend zur Verfügung.
... ... @@ -161,15 +161,14 @@
161 161  * Die Person achtet darauf, dass Tests nicht vernachlässigt werden, betrachtet regelmäßig die vorhandene Testabdeckung und macht auf unzureichend getestete Bereiche aufmerksam.
162 162  * Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
163 163  * Aufwand: Mittel
164 -{{/expandable}}
165 165  
166 -{{expandable summary="Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter"}}
166 +**Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:**
167 +
167 167  * 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.
168 168  * Erstellung/Anpassung von Vorlagen, Hilfe
169 169  * Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie
170 170  * Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden.
171 171  * Aufwand: Mittel
172 -{{/expandable}}
173 173  
174 174  **Konfliktmanagement:**
175 175  
... ... @@ -238,7 +238,6 @@
238 238  
239 239  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**.
240 240  
241 -{{expandable summary="Detaillierte Anleitung zum Gruppenreview"}}
242 242  == Ziel des Gruppenreviews ==
243 243  
244 244  Das gruppenweite Review soll dabei helfen:
... ... @@ -394,5 +394,4 @@
394 394  Man kann das auch mehrmals machen. Im SWP wird es aber nur einmal verlangt.
395 395  
396 396  ----
397 -{{/expandable}}
398 398