Changes for page Projektarbeit

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 0 added, 5 removed)
  • Alarmglocken.pdf
  • Aufgaben Erstberatung.pdf
  • Handlungsempfehlungen Bystander_14.04.23.pdf
  • Prävention.pdf
  • Sexualisierte Diskriminierung und Gewalt.pdf

Details

Page properties

Content

...	...	@@ -1,17 +1,11 @@
1		-{{info}}
2		-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.
3		-{{/info}}
	1	+= Teilaufgabe 1 - Projektmanagement organisieren =
4	4
5		-{{toc/}}
6		-
7		-= Projektmanagement organisieren =
8		-
9	9	* Organisieren Sie Ihr Projekt bzw. Team,
10		-** verteilen Sie in der zweiten Woche die [[Einzelaufgaben>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]],
	4	+** verteilen Sie in der zweiten Woche die [[Einzelaufgaben>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]],
11	11	** definieren Sie eine Reihenfolge für die Übernahme der Moderation und des Protokolls (z.B. nach Alphabet)
12	12	** die Tagesordnung ist vom Moderator mindestens einen Tag vorher zu erstellen (dafür ggf. die Gruppe nach weiteren TOPs fragen)
13	13	** definieren Sie Standards für Dokumente (LaTeX, UTF-8, ...)
14		-** Führen Sie ein [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] (im Wiki)
	8	+** Führen Sie ein [[Projekttagebuch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] (im Wiki)
15	15	* Dokumentieren Sie immer alle Ergebnisse der Gruppe, wie
16	16	** Protokolle,
17	17	** Ausarbeitungen,
...	...	@@ -23,9 +23,9 @@
23	23	* Überlegen Sie sich für Ihre Aufgaben eine "Definition of Ready" und eine "Definition of Done", d.h. was muss für eine Aufgabe erledigt sein, bevor sie als erledigt angesehen werden kann. (siehe z.B. [[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
24	24	* Erstellen Sie basierend auf den Vorgaben der Veranstaltung eine Produktvision. (vgl. z.B. [[https:~~/~~/www.wibas.com/scrum/product-vision/de)>>url:https://www.wibas.com/scrum/product-vision/de]]
25	25
26		-Sprints allein gewährleisten noch keine langfristige Orientierung. Definieren Sie deshalb zusätzliche **Meilensteine**, zu denen konkrete fachliche Ergebnisse erreicht sein sollen. Einige sind vorgegeben (vgl. [[Meilensteine>>doc:Main.Softwareentwicklung.WebHome||anchor="HVorgegebeneMeilensteine"]]). Verwenden Sie zur Meilensteindefinition nicht nur die Präsentationstermine!
	20	+Scrum hat den Nachteil, dass man lange "vor sich hin iterieren" kann. Definieren Sie zusätzliche **Meilensteine **zu denen bestimmte Funktionen fertig sein sollen. Einige sind vorgegeben (vgl. [[Meilensteine>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:DievordefiniertenMeilensteine"]]). Verwenden Sie zur Meilensteindefinition nicht nur die Präsentationstermine!
27	27
28		-= Zusammenarbeit und Verhaltensregeln =
	22	+= Anforderungen: Spielregeln innerhalb der Gruppe =
29	29
30	30	* **Allgemeine Regeln innerhalb der Gruppe**
31	31	** alle
...	...	@@ -35,8 +35,8 @@
35	35	*** beachten Gruppenstandards
36	36	*** sind bereit, ihre Arbeit auf Fehler untersuchen zu lassen
37	37	**** Grundsätzliche Kritik bitte zunächst unmittelbar an eine Person, dann Gruppe, dann Tutor, dann Dozent
38		-**** Es gibt in jeder Gruppe einen Konfliktbeauftragten (siehe [[Anforderungen Einzelleistungen>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]]) geben
39		-*** Diskriminierung wird in keinster Form geduldet! (siehe [[Spielregeln>>doc:Main.Projektarbeit.WebHome||anchor="HZusammenarbeitundVerhaltensregeln"]])
	32	+**** Es gibt in jeder Gruppe einen Konfliktbeauftragten (siehe [[Anforderungen Einzelleistungen>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]]) geben
	33	+*** Diskriminierung wird in keinster Form geduldet! (siehe [[Spielregeln>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:SpielregelninnerhalbderGruppe"]])
40	40	*** Konsequenzen bei Nichterfüllung von übertragenen Aufgaben festlegen?
41	41	** Jeder übernimmt Teile bei
42	42	*** Dokumentation und
...	...	@@ -90,26 +90,20 @@
90	90	* Erstanlaufstelle Antidiskriminierung des AStA: Donnerstags: 10:30 - 13:30 Uhr de/eng/farsi im AStA Trakt, Raum M1-157, [[beratung@asta-uol.de>>mailto:beratung@asta-uol.de||style="background-color: rgb(255, 255, 255);"]],
91	91	* conTakt: [[https:~~/~~/uol.de/contakt-beratungsstelle>>url:https://uol.de/contakt-beratungsstelle]]
92	92
93		-= Individuelle Verantwortungsbereiche und Einzelaufgaben =
	87	+= Anforderungen: Einzelleistungen und Einzelaufgaben =
94	94
95		-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 als **Querschnitts- und Serviceaufgaben** zu verstehen. Wenn in einem Zeitraum für einen Verantwortungsbereich wenig Bedarf besteht, soll nicht künstlich Arbeit erzeugt werden; die Person unterstützt dann die reguläre Projektarbeit oder andere Verantwortungsbereiche. Entscheidend ist, dass es für das jeweilige Thema eine klar benannte Person gibt, die sich zuständig fühlt, bei Fragen unterstützen kann und darauf achtet, dass die vereinbarten Anforderungen berücksichtigt werden. 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.
	89	+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 oder andere Rollen unterstützen. 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.
96	96
97		-Die kurzen Einführungen zu den Verantwortungsbereichen des ersten Blocks sollen im ersten Semester, möglichst innerhalb der ersten sieben Wochen, durchgeführt werden.
	91	+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!
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 ==
	95	+== Einzelaufgaben/Rollen (müssen vergeben sein) ==
102	102
103		-Jeder muss einen Kurzvortrag halten, i.d.R. bezogen auf die Rolle
	97	+Hinweis: Der Aufwand ist relativ zu sehen, d.h. Scrum-Master ist z.B. aufwändiger als Testbeauftragter
104	104
	99	+**Scrum-Master:**
105	105
106		-== Verantwortungsbereiche / Rollen ==
107		-
108		-{{info}}
109		-Der Aufwand der Verantwortungsbereiche ist unterschiedlich und kann sich im Projektverlauf verändern. Die Einstufungen sind daher nur als Orientierung zu verstehen.
110		-{{/info}}
111		-
112		-{{expandable summary="Scrum-Master"}}
113	113	* Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
114	114	* 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"]].
115	115	* Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
...	...	@@ -117,27 +117,28 @@
117	117	* Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
118	118	* 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.
119	119	* Aufwand: Sehr hoch
120		-{{/expandable}}
121	121
122		-{{expandable summary="GitLab, Projektplanung und Product Owner"}}
	109	+**GitLab, Projektplanung und Productowner:**
	110	+
123	123	* 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.
124		-* Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, ein vollständiges Gantt-Diagramm über das komplette Semester zu erstellen.
125		-* [[Projekttagebuch>>doc:Main.Projektarbeit.WebHome||anchor="HProjekttagebuch"]] führen
	112	+* Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen.
	113	+* [[Projekttagebuch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] führen
126	126	* Stundenzettelpflege überwachen
127	127	* Weiterhin soll diese Person als Ansprechpartner für GitLab dienen, d.h. sie sollte sich besonders informieren und ggf. bei Fragen und Problemen beratend zur Seite stehen.
128		-* Die Person übernimmt gemeinsam mit dem Tutor wesentliche Aufgaben des Product Owners: Sie achtet darauf, dass ausreichend vorbereitete Einträge im Product Backlog vorhanden sind und unterstützt deren Priorisierung.
129		-* Sie achtet darauf, dass für die Arbeit im Sprint die vereinbarte Definition of Done berücksichtigt wird.
130		-* 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.
	116	+* Product Owner
	117	+* NEU: Diese Rolle sollte vorrangig mit dem Tutor die Scrum-Rolle des Productowners übernehmen, d.h. die Person kontrolliert, ob immer genug Tickets im Backlog vorliegen und macht ggf. eine Priorisierung der Tickets.
	118	+* NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind
	119	+* NEU: Die Rolle sorgt dafür, dass kleinere Teilgruppen (**Ticket-Task-Force**) dafür sorgen, dass neue Tickets formuliert und Ticketbeschreibungen verbessert werden (Backlogrefinement). 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.
131	131	* Aufwand: Hoch
132		-{{/expandable}}
133	133
134		-{{expandable summary="Client-Server-Kommunikation: OpenAPI, REST, WebSockets und Spring"}}
	122	+**OpenAPI, REST und Spring**
	123	+
135	135	* Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner
136	136	* Aufwand: Kann sehr variieren
137		-* Bei größeren Gruppen kann der Verantwortungsbereich sinnvoll in **API/Kommunikation (OpenAPI, REST, WebSockets)** und **Spring/serverseitige Architektur** aufgeteilt werden.
138		-{{/expandable}}
	126	+* Hinweis: Es kann Sinn machen (bei mehr als 10 Teilnehmern), diese Rolle in "OpenAPI, REST, WebSockets" und "Spring" aufzuteilen.
139	139
140		-{{expandable summary="Git/GitLab und Reviewbeauftragter"}}
	128	+**~ Git/Gitlab und Reviewbeauftragter:**
	129	+
141	141	* Der Inhaber kennt sich mit Git und Gitlab aus.
142	142	* Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
143	143	* 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.
...	...	@@ -145,43 +145,43 @@
145	145	* Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen
146	146	* Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
147	147	* Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig.
148		-* Aufwand: Mittel
149		-{{/expandable}}
	137	+* Aufwand: Geringer
	138	+* Aufwand: Mittel.
150	150
151		-{{expandable summary="Codequalitätsbeauftragter und Patternbeauftragter"}}
	140	+**Codequalitätsbeauftragter und Patternbeauftragter:**
	141	+
152	152	* Überwachung von Codierungsstandards
153	153	* Kennt sich mit Refactorings aus
154	154	* Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
155		-* Kennt sich mit Werkzeugen wie SpotBugs, Checkstyle und SonarLint/SonarQube aus.
	145	+* Kennt sich mit Tools wie: FindBugs, Checkstyle und SonarLint/Sonarqube aus.
156	156	* Soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten
157	157	* Die Gruppe bei der Anwendung der Pattern unterstützen
158	158	* Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
159	159	* Aufwand: Mittel
160		-{{/expandable}}
161	161
162		-{{expandable summary="Testbeauftragter"}}
	151	+**Testbeauftragter:**
	152	+
163	163	* Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
164	164	* Die Person stellt ggf. Mockito und JUnit vor
165		-* Der Testbeauftragte unterstützt die Gruppe beim Schreiben von Tests und steht bei Fragen beratend zur Verfügung.
166		-* Die Person achtet darauf, dass Tests nicht vernachlässigt werden, betrachtet regelmäßig die vorhandene Testabdeckung und macht auf unzureichend getestete Bereiche aufmerksam.
	155	+* Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an
	156	+* Die Person muss dafür sorgen, dass Tests nicht vernachlässigt werden, hat also regelmäßig einen Blick auf die aktuelle Testabdeckung und weist ggf. Personen darauf hin, dass bestimmte Codeabschnitte noch (besser) durch Tests abgedeckt werden müssen.
167	167	* Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
168	168	* Aufwand: Mittel
169		-{{/expandable}}
170	170
171		-{{expandable summary="Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter"}}
172		-* 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.
	160	+**Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:**
	161	+
	162	+* Sorgt dafür, dass die passenden Dokumente erstellt, mitgepflegt und gesichert werden (kein Doku Sklave!)
173	173	* Erstellung/Anpassung von Vorlagen, Hilfe
174	174	* Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie
175	175	* Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden.
176	176	* Aufwand: Mittel
177		-{{/expandable}}
178	178
179		-{{expandable summary="Konfliktmanagement"}}
	168	+**Konfliktmanagement:**
	169	+
180	180	* Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
181	181	* 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.
182	182	* 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.
183	183	* Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden.
184		-{{/expandable}}
185	185
186	186	Falls alle Rollen vergeben sind, können noch folgende ergänzend dazu kommen.
187	187
...	...	@@ -188,8 +188,8 @@
188	188	* Spielregeln
189	189	* Frontend (z.B. JavaFX oder Web-Frontends)
190	190	* Spezielle Rolle für REST, WebSockets und OpenAPI und dafür in der obigen Rolle (OpenAPI, REST und Spring) nur noch Spring
191		-* Programmierkonzepte
192		-** z. B. Dependency Injection mit Spring
	180	+* Progammierkonzepte
	181	+** z.B. Dependency Injection mit Guice
193	193	* DB-Zugriff:
194	194	** Installation/Überwachung der DB
195	195	* Spezialisten für verschiedene Teilthemen:
...	...	@@ -215,7 +215,7 @@
215	215	* Wann wurden andere wichtige Zwischenziele erreicht
216	216	* Welche besonderen Dinge hat es gegeben, die wesentlichen Einfluss auf das Projekt oder die Gruppe hatten
217	217
218		-== Wechselnde Aufgaben innerhalb der Gruppe ==
	207	+== Anforderungen: Wechselnde Aufgaben innerhalb der Gruppe ==
219	219
220	220	Diese Aufgaben wechseln wöchentlich:
221	221
...	...	@@ -222,7 +222,7 @@
222	222	* Sitzungsleitung und Moderation
223	223	** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master
224	224	** Tagesordnung definieren (vorher)!!
225		-** Ein Moderator ist dafür zuständig, dass die Sitzungen geregelt ablaufen, d.h. insbesondere muss ein Moderator darauf achten, dass die Teilnehmer sich an die Regeln (siehe: [[Spielregeln>>doc:Main.Projektarbeit.WebHome||anchor="HZusammenarbeitundVerhaltensregeln"]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen.
	214	+** Ein Moderator ist dafür zuständig, dass die Sitzungen geregelt ablaufen, d.h. insbesondere muss ein Moderator darauf achten, dass die Teilnehmer sich an die Regeln (siehe: [[Spielregeln>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:SpielregelninnerhalbderGruppe"]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen.
226	226	Hier gibt es weitere Hinweise zu der Aufgabe eines Moderators: [[https:~~/~~/www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html >>url:https://www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html%C2%A0]]
227	227	* Protokollführung
228	228	** Erstellung eines Protokolls der Gruppensitzung
...	...	@@ -235,15 +235,10 @@
235	235	** Leitung/Protokoll (Liste!)
236	236	* Tutor ist nur Berater, leitet keine Sitzungen, kann aber um Rat gefragt werden (und greift (zu Beginn mehr und Ende weniger) ein, wenn es zu sehr „aus dem Ruder läuft“, erlaubt aber auch Fehler …)
237	237
238		-= Gruppenweites Code-Review (Team-Review) =
	227	+= Gruppenweites Code Review (Team-Review) =
239	239
240		-{{info}}
241		-**Kurzfassung:** Mindestens einmal im Projekt wird ein nicht trivialer Codebereich gemeinsam reviewt. Der Kontext wird vorbereitet, die gesamte Gruppe beteiligt sich am Review, Ergebnisse werden dokumentiert und konkrete Verbesserungsmaßnahmen anschließend nachverfolgt.
242		-{{/info}}
243		-
244	244	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**.
245	245
246		-{{expandable summary="Detaillierte Anleitung zum Gruppenreview"}}
247	247	== Ziel des Gruppenreviews ==
248	248
249	249	Das gruppenweite Review soll dabei helfen:
...	...	@@ -399,4 +399,4 @@
399	399	Man kann das auch mehrmals machen. Im SWP wird es aber nur einmal verlangt.
400	400
401	401	----
402		-{{/expandable}}
	386	+

Alarmglocken.pdf

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-196.9 KB

Content

Aufgaben Erstberatung.pdf

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-110.3 KB

Content

Handlungsempfehlungen Bystander_14.04.23.pdf

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-74.0 KB

Content

Prävention.pdf

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-135.0 KB

Content

Sexualisierte Diskriminierung und Gewalt.pdf

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-168.1 KB

Content