Changes for page Anforderungen Gruppen
Last modified by mgrawunder on 2025/09/22 10:02
From 14.3 to 14.2
From 21.1 to 20.4
From version 20.4
edited by mgrawunder
on 2025/09/11 14:42
on 2025/09/11 14:42
Change comment:
There is no comment for this version
To version 14.3
edited by Pascal Meyer
on 2025/07/30 18:13
on 2025/07/30 18:13
Change comment:
Update document after refactoring.
Summary
-
Page properties (3 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -Anforderungen 1 +AnforderungenGruppen - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. mgrawunder1 +XWiki.PascalMeyer - Content
-
... ... @@ -1,5 +3,3 @@ 1 -[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]] 2 - 3 3 {{toc/}} 4 4 5 5 = Anforderungen Gruppensitzungen = ... ... @@ -20,7 +20,7 @@ 20 20 21 21 == Vorschlag für Ablauf == 22 22 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.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 [[Scrum Workshop>>url: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 [[Scrum Workshop>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/319456049/Scrum+Workshop]] angeboten. 24 24 25 25 [[image:Arbeitsweise_Weiß.png]] 26 26 ... ... @@ -37,8 +37,8 @@ 37 37 *** beachten Gruppenstandards 38 38 *** sind bereit, ihre Arbeit auf Fehler untersuchen zu lassen 39 39 **** Grundsätzliche Kritik bitte zunächst unmittelbar an eine Person, dann Gruppe, dann Tutor, dann Dozent 40 -**** Es gibt in jeder Gruppe einen (siehe [[AnforderungenEinzelleistungen>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]]) geben41 -*** Diskriminierung wird in keinster Form geduldet! (siehe [[Spielregeln>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:SpielregelninnerhalbderGruppe"]])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]] 42 42 *** Konsequenzen bei Nichterfüllung von übertragenen Aufgaben festlegen? 43 43 ** Jeder übernimmt Teile bei 44 44 *** Dokumentation und ... ... @@ -97,45 +97,41 @@ 97 97 98 98 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! 99 99 100 -Die Einzelaufgaben **außer dem Scrum-Master** sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet.98 +Die Einzelaufgaben sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet. 101 101 102 102 == Einzelaufgaben/Rollen (müssen vergeben sein) == 103 103 104 -Hinweis: Der Aufwand ist relativ zu sehen, d.h. Scrum-Master ist z.B. aufwändiger als Testbeauftragter 105 - 106 -**Scrum-Master:** 107 - 108 -* Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt 109 -* 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"]]. 110 -* Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs). 111 -* 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. 112 -* Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen. 113 -* 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. 114 -* Aufwand: Sehr hoc 115 - 116 -* **GitLab, Projektplanung und Productowner:** 102 +* **Scrum-Master:** 103 +** Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt 104 +** Kurze Zusammenfassung zu [[Scrum>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]], ausführlicher in den Folien der VL. 105 +** Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs). 106 +** 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. 107 +** Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen. 108 +** 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. 109 +** Aufwand: Sehr hoch 110 +* **Jira, Projektplanung und Productowner:** 117 117 ** 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. 118 118 ** Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen. 119 -** [[Projekttagebuch>> doc:Main.AnforderungenGruppen.WebHome||anchor="HProjekttagebuch"]] führen113 +** [[Projekttagebuch>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393398/Projekttagebuch]] führen 120 120 ** Stundenzettelpflege überwachen 121 -** 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. 115 +** Ggf. kann das Jira-Plugin: Portfolie verwendet werden. 116 +** 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. 122 122 ** Product Owner 123 123 ** 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. 124 124 ** NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind 125 125 ** 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. 126 126 ** Aufwand: Hoch 127 -* **OpenAPI, REST und Spring** 128 -** Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner 129 -* ** Git/Gitlab und Reviewbeauftragter:** 130 -** Der Inhaber kennt sich mit Git und Gitlab aus. 122 +* **Konfliktmanagement:** 123 +** Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten. 124 +** 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. 125 +** 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. 126 +** Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden. 127 +* ** Git/Bitbucket:** 128 +** Der Inhaber kennt sich mit Git und Bitbucket aus. 131 131 ** Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt) 132 -** 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.130 +** 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. 133 133 ** Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben. 134 -** Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen 135 -** Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren. 136 -** Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig. 137 -** Aufwand: Geringer 138 -** Aufwand: Mittel. 132 +** Aufwand: Initial höher, zum Ende hin weniger. 139 139 * **Codequalitätsbeauftragter und Patternbeauftragter:** 140 140 ** Überwachung von Codierungsstandards 141 141 ** Kennt sich mit Refactorings aus ... ... @@ -145,6 +145,11 @@ 145 145 ** Die Gruppe bei der Anwendung der Pattern unterstützen 146 146 ** Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären 147 147 ** Aufwand: Mittel 142 +* **Reviewbeauftragter:** 143 +** Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen 144 +** Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren. 145 +** Zusammen mit dem Git- und dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Pull-Requests zuständig. 146 +** Aufwand: Geringer 148 148 * **Testbeauftragter:** 149 149 ** Der Testbeauftragte ist nicht dafür da, Tests zu schreiben! 150 150 ** Die Person stellt ggf. Mockito und JUnit vor ... ... @@ -152,18 +152,18 @@ 152 152 ** 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. 153 153 ** Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden. 154 154 ** Aufwand: Mittel 155 -* **Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:**154 +* **Dokumentations- und Backupbeauftragter, Confluence, LaTeX-Beauftragter:** 156 156 ** Sorgt dafür, dass die passenden Dokumente erstellt, mitgepflegt und gesichert werden (kein Doku Sklave!) 157 157 ** Erstellung/Anpassung von Vorlagen, Hilfe 158 158 ** Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie 159 159 ** Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden. 160 160 ** Aufwand: Mittel 161 -* ** Konfliktmanagement:**162 -** Es kommtabundzu vor,dassimSWP gruppeninterneKonflikte auftreten.163 -** Diese Rolle soll sich im Vorfeld(also bevoretwas"schief" geht), damit befassen,welcheMethodenundAnsätze es gibt, inGruppen mit solchenKonfliktenzugehen.164 -** Esmacht Sinn, dass es jemanden zweitengibt, dersichals Stellvertreter ebenfallsmitdieserAufgabe befasst, fallsdie Person,die diese Rolle eigentlichinne hat, selberderAuslöser einesKonfliktes ist.165 -** Aufwand: HängtmassivvonderGruppeab ... Kannsehr wenig,kannaberauch sehrkomplexwerden.166 -* 160 +* **Entwicklungsumgebung, Maven, Bamboo und Infrastruktur:** 161 +** Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur 162 +** Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung 163 +** Kümmert sich um die Builds in Bamboo (Anpassen von Plänen) 164 +** Kümmert sich um die Bereitstellung des Servers in der Arbi 165 +** Aufwand: Mittel 167 167 * **GUI-Beauftragter:** 168 168 ** Da i.d.R. noch nicht viel Erfahrung im Bereich der Entwicklung von Oberflächen besteht, soll sich diese Rolle intensiv mit JavaFX auseinandersetzen 169 169 ** Die Rolle soll Wissen grundsätzlich zu JavaFX aufbauen und als Ansprechpartner bei Fragen und Problemen dienen. ... ... @@ -207,12 +207,12 @@ 207 207 * Sitzungsleitung und Moderation 208 208 ** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master 209 209 ** Tagesordnung definieren (vorher)!! 210 -** 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.AnforderungenGruppen.WebHome||anchor="HAnforderungen:SpielregelninnerhalbderGruppe"]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen.209 +** 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 in der Gruppe>>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. 211 211 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]] 212 212 * Protokollführung 213 213 ** Erstellung eines Protokolls der Gruppensitzung 214 214 ** Hier reicht i.d.R. ein Ergebnisprotokoll 215 -** Protokolle müssen im Wikiabgelegt sein214 +** Protokolle müssen im Confluence abgelegt sein 216 216 * Zu Beginn jeder Gruppensitzung („Daily Scrum“): 217 217 ** findet ein kurzes „Briefing“ („Blitzlicht“) statt, in der jede/r berichtet, was sie/er in der letzten Woche für das Projekt getan hat. 218 218 * Am Ende jeder Sitzung neue Aufgabenverteilung