Changes for page Projektarbeit

Summary

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

Details

Page properties

Content

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