Changes for page Projektarbeit

Summary

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

Details

Page properties

Content

...	...	@@ -98,14 +98,6 @@
98	98
99	99	Die Einzelaufgaben sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet.
100	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	109	== Verantwortungsbereiche / Rollen ==
110	110
111	111	{{info}}
...	...	@@ -112,7 +112,8 @@
112	112	Der Aufwand der Verantwortungsbereiche ist unterschiedlich und kann sich im Projektverlauf verändern. Die Einstufungen sind daher nur als Orientierung zu verstehen.
113	113	{{/info}}
114	114
115		-{{expandable summary="Scrum-Master"}}
	107	+**Scrum-Master:**
	108	+
116	116	* Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
117	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	118	* Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
...	...	@@ -120,9 +120,9 @@
120	120	* Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
121	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	122	* Aufwand: Sehr hoch
123		-{{/expandable}}
124	124
125		-{{expandable summary="GitLab, Projektplanung und Product Owner"}}
	117	+**GitLab, Projektplanung und Product Owner:**
	118	+
126	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	127	* Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, ein vollständiges Gantt-Diagramm über das komplette Semester zu erstellen.
128	128	* [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] führen
...	...	@@ -132,15 +132,15 @@
132	132	* Sie achtet darauf, dass für die Arbeit im Sprint die vereinbarte Definition of Done berücksichtigt wird.
133	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	134	* Aufwand: Hoch
135		-{{/expandable}}
136	136
137		-{{expandable summary="Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring"}}
	129	+**Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring:**
	130	+
138	138	* Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner
139	139	* Aufwand: Kann sehr variieren
140	140	* Bei größeren Gruppen kann der Verantwortungsbereich sinnvoll in **API/Kommunikation (OpenAPI, REST, WebSockets)** und **Spring/serverseitige Architektur** aufgeteilt werden.
141		-{{/expandable}}
142	142
143		-{{expandable summary="Git/GitLab und Reviewbeauftragter"}}
	135	+**Git/GitLab und Reviewbeauftragter:**
	136	+
144	144	* Der Inhaber kennt sich mit Git und Gitlab aus.
145	145	* Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
146	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.
...	...	@@ -149,9 +149,9 @@
149	149	* Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
150	150	* Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig.
151	151	* Aufwand: Mittel
152		-{{/expandable}}
153	153
154		-{{expandable summary="Codequalitätsbeauftragter und Patternbeauftragter"}}
	146	+**Codequalitätsbeauftragter und Patternbeauftragter:**
	147	+
155	155	* Überwachung von Codierungsstandards
156	156	* Kennt sich mit Refactorings aus
157	157	* Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
...	...	@@ -160,9 +160,9 @@
160	160	* Die Gruppe bei der Anwendung der Pattern unterstützen
161	161	* Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
162	162	* Aufwand: Mittel
163		-{{/expandable}}
164	164
165		-{{expandable summary="Testbeauftragter"}}
	157	+**Testbeauftragter:**
	158	+
166	166	* Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
167	167	* Die Person stellt ggf. Mockito und JUnit vor
168	168	* Der Testbeauftragte unterstützt die Gruppe beim Schreiben von Tests und steht bei Fragen beratend zur Verfügung.
...	...	@@ -169,22 +169,21 @@
169	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	170	* Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
171	171	* Aufwand: Mittel
172		-{{/expandable}}
173	173
174		-{{expandable summary="Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter"}}
	166	+**Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:**
	167	+
175	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	176	* Erstellung/Anpassung von Vorlagen, Hilfe
177	177	* Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie
178	178	* Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden.
179	179	* Aufwand: Mittel
180		-{{/expandable}}
181	181
182		-{{expandable summary="Konfliktmanagement"}}
	174	+**Konfliktmanagement:**
	175	+
183	183	* Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
184	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	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	186	* Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden.
187		-{{/expandable}}
188	188
189	189	Falls alle Rollen vergeben sind, können noch folgende ergänzend dazu kommen.
190	190
...	...	@@ -246,7 +246,6 @@
246	246
247	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	248
249		-{{expandable summary="Detaillierte Anleitung zum Gruppenreview"}}
250	250	== Ziel des Gruppenreviews ==
251	251
252	252	Das gruppenweite Review soll dabei helfen:
...	...	@@ -402,4 +402,4 @@
402	402	Man kann das auch mehrmals machen. Im SWP wird es aber nur einmal verlangt.
403	403
404	404	----
405		-{{/expandable}}
	396	+