Changes for page Anforderungen Gruppen

Summary

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

Details

Page properties

Content

...	...	@@ -94,7 +94,7 @@
94	94
95	95	= Anforderungen: Einzelleistungen und Einzelaufgaben =
96	96
97		-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.
	97	+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 dabei als Serviceleistungen zu verstehen, d.h. wenn es keinen Bedarf gibt, muss die "Rolle" auch nicht krampfhaft versuchen, Inhalt zu finden, mit denen die Rolle gefüllt werden kann, dann lieber auf das Projekt fokussieren. Die Idee ist i.d.R. eher: Hier gibt es eine Person, die sich für die Aufgabe verantwortlich fühlt und im Zweifelsfall weiterhelfen kann bzw. dafür sorgt, dass die Dinge erfüllt werden (wie beim Scrummaster oder Testbeauftragten). 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.
98	98
99	99	Die Vorträge für die Einzelaufgaben des ersten Blocks müssen auf jeden Fall im ersten Semester, am besten innerhalb der ersten 7 Wochen durchgeführt worden sein!
100	100
...	...	@@ -185,6 +185,15 @@
185	185	* Spielregeln
186	186	* Frontend (z.B. JavaFX oder Web-Frontends)
187	187	* Spezielle Rolle für REST, WebSockets und OpenAPI und dafür in der obigen Rolle (OpenAPI, REST und Spring) nur noch Spring
	188	+* Progammierkonzepte
	189	+** z.B. Dependency Injection mit Guice
	190	+* DB-Zugriff:
	191	+** Installation/Überwachung der DB
	192	+* Spezialisten für verschiedene Teilthemen:
	193	+** Netzwerkkommunikation
	194	+** Regeln des aktuellen Spiels
	195	+** Weitere Frameworks
	196	+** GUI
188	188
189	189	=== Projekttagebuch ===
190	190
...	...	@@ -203,20 +203,8 @@
203	203	* Wann wurden andere wichtige Zwischenziele erreicht
204	204	* Welche besonderen Dinge hat es gegeben, die wesentlichen Einfluss auf das Projekt oder die Gruppe hatten
205	205
206		-== Einzelaufgaben/Rollen (je nach Bedarf) ==
	215	+== Anforderungen: Wechselnde Aufgaben innerhalb der Gruppe ==
207	207
208		-* Progammierkonzepte
209		-** z.B. Dependency Injection mit Guice
210		-* DB-Zugriff:
211		-** Installation/Überwachung der DB
212		-* Spezialisten für verschiedene Teilthemen:
213		-** Netzwerkkommunikation
214		-** Regeln des aktuellen Spiels
215		-** Weitere Frameworks
216		-** GUI
217		-
218		-= Anforderungen: Wechselnde Aufgaben innerhalb der Gruppe =
219		-
220	220	Diese Aufgaben wechseln wöchentlich:
221	221
222	222	* Sitzungsleitung und Moderation
...	...	@@ -305,8 +305,6 @@
305	305	* „Gibt es eine einfachere Lösung?“
306	306	)))
307	307
308		-----
309		-
310	310	=== 2. Vorstellung (ca. 5–10 Minuten) ===
311	311
312	312	* (((
...	...	@@ -317,18 +317,16 @@
317	317	)))
318	318	* keine detaillierte Zeilen-für-Zeilen-Erklärung
319	319
320		-----
321		-
322	322	=== 3. Gemeinsames Review (ca. 20–40 Minuten) ===
323	323
324	324	Diskussion des Codes anhand folgender Leitfragen:
325	325
326		-==== Verständlichkeit ====
	319	+==== Verständlichkeit ====
327	327
328	328	* Ist der Code gut nachvollziehbar?
329	329	* Welche Stellen sind schwer verständlich?
330	330
331		-==== Design ====
	324	+==== Design ====
332	332
333	333	* Ist die Struktur sinnvoll gewählt?
334	334	* Gibt es einfachere oder klarere Alternativen?
...	...	@@ -343,8 +343,6 @@
343	343	* Wie könnte man den Code testen?
344	344	* Sind relevante Tests vorhanden oder ableitbar?
345	345
346		-----
347		-
348	348	=== 4. Fazit (ca. 5 Minuten) ===
349	349
350	350	* Was war gut?
...	...	@@ -351,8 +351,6 @@
351	351	* Was kann verbessert werden?
352	352	* Welche Erkenntnisse nehmen wir als Team mit?
353	353
354		-----
355		-
356	356	== Geeignete Inhalte für das Gruppenreview ==
357	357
358	358	**Gut geeignet:**
...	...	@@ -368,8 +368,6 @@
368	368	* reine Formatierungsänderungen
369	369	* sehr große, unstrukturierte Codebereiche
370	370
371		-----
372		-
373	373	== Feedback-Regeln ==
374	374
375	375	=== Gutes Feedback ist: ===
...	...	@@ -384,8 +384,6 @@
384	384	* persönliche Kritik
385	385	* Diskussionen ohne Bezug zum Code
386	386
387		-----
388		-
389	389	== Typische Probleme ==
390	390
391	391	* **Zu viel Code:** → stärker eingrenzen
...	...	@@ -393,8 +393,6 @@
393	393	* **Einzelne dominieren:** → Moderator:in steuert aktiv
394	394	* **Diskussion driftet ab:** → Fokus wieder auf Code lenken
395	395
396		-----
397		-
398	398	== Minimal-Regeln ==
399	399
400	400	1. Es wird **nur ein überschaubarer Codeausschnitt** betrachtet
...	...	@@ -402,13 +402,11 @@
402	402	1. Die Gruppe diskutiert strukturiert
403	403	1. Am Ende werden **konkrete Erkenntnisse festgehalten**
404	404
405		-----
406		-
407	407	== Hinweis ==
408	408
409	409	Das Gruppenreview ist eine **Lerngelegenheit**.
410	410	Bringt gerne auch Code mit, bei dem ihr unsicher seid – genau dort entsteht oft die beste Diskussion.
411	411
412		-Man kann das auch me
	393	+Man kann das auch mehrmals machen. Im SWP wird es aber nur einmal verlangt.
413	413
414	414	----