Changes for page Projektarbeit

Summary

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

Details

Page properties

Content

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