Changes for page Anforderungen Gruppen
Last modified by mgrawunder on 2025/09/22 10:02
From 7.2 to 8.1
From 18.2 to 19.1
From version 8.1
edited by Pascal Meyer
on 2025/07/29 02:04
on 2025/07/29 02:04
Change comment:
Uploaded new attachment "Sexualisierte Diskriminierung und Gewalt.pdf", version {1}
To version 18.2
edited by Marco Grawunder
on 2025/08/15 10:16
on 2025/08/15 10:16
Change comment:
There is no comment for this version
Summary
-
Page properties (3 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -Anforderungen an dieGruppe1 +Anforderungen Gruppen - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. PascalMeyer1 +XWiki.MarcoGrawunder - Content
-
... ... @@ -1,6 +1,8 @@ 1 +[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]] 2 + 1 1 {{toc/}} 2 2 3 -= Anforderungen :Gruppensitzungen =5 += Anforderungen Gruppensitzungen = 4 4 5 5 Die Gruppensitzungen (im Stud.IP zu erkennen an AG Softwareprojekt (X)) sind die Zeiten, in denen die Teams gemeinsam ihr Produkt entwickeln. Die Sitzungen werden von einem Tutor/einer Tutorin begleitet. Die Gruppentreffen finden i.d.R. in Präsenz statt. Im zweiten Semester braucht es ggf. nur alle zwei Wochen ein Präsenztreffen mit dem Tutor/der Tutorin, der Rest kann dann auch online stattfinden. 6 6 ... ... @@ -18,7 +18,7 @@ 18 18 19 19 == Vorschlag für Ablauf == 20 20 21 -Es ist nicht immer leicht, zu Beginn die Organisation zu handhaben. Aus diesem Grund im Folgenden ein paar Hilfsdiagramme, die ein Student erstellt hat und freundlicherweise zur Verfügung gestellt hat. Wichtig sind dazu auch noch einmal die [[Scrum>> url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]]-Aspekte, die auch in einem [[Scrumurl:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/319456049/Scrum+Workshop]] aufbereitet wurde. Wenn es die Mittel zulassen und es eine geeignete Person gibt, wird der [[Scrumurl:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/319456049/Scrum+Workshop]] angeboten.23 +Es ist nicht immer leicht, zu Beginn die Organisation zu handhaben. Aus diesem Grund im Folgenden ein paar Hilfsdiagramme, die ein Student erstellt hat und freundlicherweise zur Verfügung gestellt hat. Wichtig sind dazu auch noch einmal die [[Scrum>>doc:Main.Scrum.WebHome]]-Aspekte, die auch in einem [[Scrum-Workshop>>doc:Main.Scrum.WebHome||anchor="HScrumWorkshop"]] aufbereitet wurde. Wenn es die Mittel zulassen und es eine geeignete Person gibt, wird der [[Scrum-Workshop>>doc:Main.Scrum.WebHome||anchor="HScrumWorkshop"]] angeboten. 22 22 23 23 [[image:Arbeitsweise_Weiß.png]] 24 24 ... ... @@ -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>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393423/Einzelleistungen+und%C2%A0Einzelaufgaben]]39 -*** [[Diskriminierung wird in keinster Form geduldet!>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/569606145/Keine+Tolerierung+von+Diskriminierung+jeglicher+Art]]40 +**** Es gibt in jeder Gruppe einen Konfliktbeauftragten (siehe [[Anforderungen Einzelleistungen>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]]) geben 41 +*** 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 ... ... @@ -78,12 +78,8 @@ 78 78 79 79 [[Prävention>>attach:Prävention.pdf]] 80 80 81 - 83 +[[Sexualisierte Diskriminierung und Gewalt>>attach:Sexualisierte Diskriminierung und Gewalt.pdf]] 82 82 83 -[[Prävention.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/cb6873a1ee8c216372356589dc8561b1/Pr%C3%A4vention.pdf]] 84 - 85 -[[Sexualisierte Diskriminierung und Gewalt.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/7d11cc3e96658ddfe2876a95b343a4b3/Sexualisierte_Diskriminierung_und_Gewalt.pdf]] 86 - 87 87 **Kontaktmöglichkeiten** 88 88 89 89 * Tutor/Tutorin der Gruppe ... ... @@ -103,38 +103,39 @@ 103 103 104 104 == Einzelaufgaben/Rollen (müssen vergeben sein) == 105 105 106 -* Scrum-Master: 104 +Hinweis: Der Aufwand ist relativ zu sehen, d.h. Scrum-Master ist aufwändiger als Te 105 + 106 +* **Scrum-Master:** 107 107 ** Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt 108 -** Kurze Zusammenfassung zu [[Scrum>> url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]], ausführlicher in den Folien der VL.108 +** 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"]]. 109 109 ** Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs). 110 110 ** Diese Rolle ist mit die wichtigste Rolle im SWP und verlangt durchgehend sehr viel Kapazität. Ein Scrum-Master ist aus diesem Grund typischerweise weniger (aber trotzdem noch) an der Implementierung beteiligt. 111 111 ** Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen. 112 112 ** 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. 113 113 ** Aufwand: Sehr hoch 114 -* Jira, Projektplanung und Productowner:114 +* **GitLab, Projektplanung und Productowner:** 115 115 ** 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. 116 116 ** Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen. 117 -** [[Projekttagebuch>> url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393398/Projekttagebuch]] führen117 +** [[Projekttagebuch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] führen 118 118 ** Stundenzettelpflege überwachen 119 -** Ggf. kann das Jira-Plugin: Portfolie verwendet werden. 120 -** Weiterhin soll diese Person als Ansprechpartner für Jira dienen, d.h. sie sollte sich besonders informieren und ggf. bei Fragen und Problemen beratend zur Seite stehen. 119 +** 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. 121 121 ** Product Owner 122 122 ** 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. 123 123 ** NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind 124 124 ** 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. 125 125 ** Aufwand: Hoch 126 -* Konfliktmanagement 125 +* **Konfliktmanagement:** 127 127 ** Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten. 128 128 ** 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. 129 129 ** 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. 130 130 ** Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden. 131 -* Git/Bitbucket 130 +* ** Git/Bitbucket:** 132 132 ** Der Inhaber kennt sich mit Git und Bitbucket aus. 133 133 ** Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt) 134 134 ** Der Inhaber dieser Rolle sollte sich auch darum kümmern, dass der Git-Workflow (Ticket → Branch → PR → Mergen) eingehalten, dass Pull-Requests sinnvoll abgearbeitet werden und nicht zu lange liegen bleiben. 135 135 ** Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben. 136 136 ** Aufwand: Initial höher, zum Ende hin weniger. 137 -* Codequalitätsbeauftragter und Patternbeauftragter 136 +* **Codequalitätsbeauftragter und Patternbeauftragter:** 138 138 ** Überwachung von Codierungsstandards 139 139 ** Kennt sich mit Refactorings aus 140 140 ** Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus ... ... @@ -143,12 +143,12 @@ 143 143 ** Die Gruppe bei der Anwendung der Pattern unterstützen 144 144 ** Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären 145 145 ** Aufwand: Mittel 146 -* Reviewbeauftragter 145 +* **Reviewbeauftragter:** 147 147 ** Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen 148 148 ** Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren. 149 149 ** Zusammen mit dem Git- und dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Pull-Requests zuständig. 150 150 ** Aufwand: Geringer 151 -* Testbeauftragter: 150 +* **Testbeauftragter:** 152 152 ** Der Testbeauftragte ist nicht dafür da, Tests zu schreiben! 153 153 ** Die Person stellt ggf. Mockito und JUnit vor 154 154 ** Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an ... ... @@ -155,19 +155,19 @@ 155 155 ** 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. 156 156 ** Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden. 157 157 ** Aufwand: Mittel 158 -* Dokumentations- und Backupbeauftragter, Confluence, LaTeX-Beauftragter157 +* **Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:** 159 159 ** Sorgt dafür, dass die passenden Dokumente erstellt, mitgepflegt und gesichert werden (kein Doku Sklave!) 160 160 ** Erstellung/Anpassung von Vorlagen, Hilfe 161 161 ** Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie 162 162 ** Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden. 163 163 ** Aufwand: Mittel 164 -* Entwicklungsumgebung, Maven, Bamboo und Infrastruktur 165 -* Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur 163 +* **Entwicklungsumgebung, Maven, Bamboo und Infrastruktur:** 164 +** Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur 166 166 ** Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung 167 167 ** Kümmert sich um die Builds in Bamboo (Anpassen von Plänen) 168 168 ** Kümmert sich um die Bereitstellung des Servers in der Arbi 169 169 ** Aufwand: Mittel 170 -* GUI-Beauftragter 169 +* **GUI-Beauftragter:** 171 171 ** Da i.d.R. noch nicht viel Erfahrung im Bereich der Entwicklung von Oberflächen besteht, soll sich diese Rolle intensiv mit JavaFX auseinandersetzen 172 172 ** Die Rolle soll Wissen grundsätzlich zu JavaFX aufbauen und als Ansprechpartner bei Fragen und Problemen dienen. 173 173 ** Ganz wichtig sind in diesem Kontext auch Do and Don'ts, d.h. man sollte sich auch über Best-Practices bei JavaFX informieren. ... ... @@ -210,12 +210,12 @@ 210 210 * Sitzungsleitung und Moderation 211 211 ** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master 212 212 ** Tagesordnung definieren (vorher)!! 213 -** 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 >>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393414/Spielregeln+in+der+Gruppe]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen.212 +** 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. 214 214 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]] 215 215 * Protokollführung 216 216 ** Erstellung eines Protokolls der Gruppensitzung 217 217 ** Hier reicht i.d.R. ein Ergebnisprotokoll 218 -** Protokolle müssen im Confluenceabgelegt sein217 +** Protokolle müssen im Wiki abgelegt sein 219 219 * Zu Beginn jeder Gruppensitzung („Daily Scrum“): 220 220 ** findet ein kurzes „Briefing“ („Blitzlicht“) statt, in der jede/r berichtet, was sie/er in der letzten Woche für das Projekt getan hat. 221 221 * Am Ende jeder Sitzung neue Aufgabenverteilung