Changes for page Anforderungen Gruppen

Last modified by mgrawunder on 2025/09/22 10:02

arrow_back From 14.2 to 14.3 From 20.2 to 20.3 arrow_forward

From version arrow_back 14.3 arrow_forward

edited by Pascal Meyer
on 2025/07/30 18:13

Change comment: Update document after refactoring.

To version arrow_back 20.2 arrow_forward

edited by mgrawunder
on 2025/09/11 14:40

Change comment: There is no comment for this version

Raw
Rendered

Summary

insert_drive_file Page properties (3 modified, 0 added, 0 removed)

Details

insert_drive_file Page properties

Title

@@ -1,1 +1,1 @@
--AnforderungenGruppen
++Anforderungen Gruppen

Author

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

Content

@@ -1,3 +1,5 @@
++[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
++
  {{toc/}}
  = Anforderungen Gruppensitzungen =
@@ -18,7 +18,7 @@
  == Vorschlag für Ablauf ==
--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.
++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.
  [[image:Arbeitsweise_Weiß.png]]
@@ -35,8 +35,8 @@
  *** beachten Gruppenstandards
  *** sind bereit, ihre Arbeit auf Fehler untersuchen zu lassen
  **** Grundsätzliche Kritik bitte zunächst unmittelbar an eine Person, dann Gruppe, dann Tutor, dann Dozent
--**** Es gibt in jeder Gruppe einen [[Konfliktbeauftragten>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393423/Einzelleistungen+und%C2%A0Einzelaufgaben]]
--*** [[Diskriminierung wird in keinster Form geduldet!>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/569606145/Keine+Tolerierung+von+Diskriminierung+jeglicher+Art]]
++**** Es gibt in jeder Gruppe einen Konfliktbeauftragten (siehe [[Anforderungen Einzelleistungen>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]]) geben
++*** Diskriminierung wird in keinster Form geduldet! (siehe [[Spielregeln>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:SpielregelninnerhalbderGruppe"]])
  *** Konsequenzen bei Nichterfüllung von übertragenen Aufgaben festlegen?
  ** Jeder übernimmt Teile bei
  *** Dokumentation und
@@ -95,25 +95,28 @@
  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!
--Die Einzelaufgaben sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet.
++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.
  == Einzelaufgaben/Rollen (müssen vergeben sein) ==
++Hinweis: Der Aufwand ist relativ zu sehen, d.h. Scrum-Master ist z.B. aufwändiger als Testbeauftragter
++
++**TODO: OpenAPI, REST und Spring**
++
  * **Scrum-Master:**
  ** Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
--** Kurze Zusammenfassung zu [[Scrum>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]], ausführlicher in den Folien der VL.
++** 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"]].
  ** Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
  ** 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.
  ** Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
  ** 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.
  ** Aufwand: Sehr hoch
--* **Jira, Projektplanung und Productowner:**
++* **GitLab, Projektplanung und Productowner:**
  ** 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.
  ** Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen.
--** [[Projekttagebuch>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393398/Projekttagebuch]] führen
++** [[Projekttagebuch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] führen
  ** Stundenzettelpflege überwachen
--** Ggf. kann das Jira-Plugin: Portfolie verwendet werden.
--** 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.
++** 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.
  ** Product Owner
  ** 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.
  ** NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind
@@ -124,10 +124,10 @@
  ** 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.
  ** 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.
  ** Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden.
--* ** Git/Bitbucket:**
--** Der Inhaber kennt sich mit Git und Bitbucket aus.
++* ** Git/Gitlab:**
++** Der Inhaber kennt sich mit Git und Gitlab aus.
  ** Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
--** 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.
++** 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.
  ** Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben.
  ** Aufwand: Initial höher, zum Ende hin weniger.
  * **Codequalitätsbeauftragter und Patternbeauftragter:**
@@ -151,18 +151,18 @@
  ** 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.
  ** Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
  ** Aufwand: Mittel
--* **Dokumentations- und Backupbeauftragter, Confluence, LaTeX-Beauftragter:**
++* **Dokumentations- und Backupbeauftragter, Wiki, LaTeX-Beauftragter:**
  ** Sorgt dafür, dass die passenden Dokumente erstellt, mitgepflegt und gesichert werden (kein Doku Sklave!)
  ** Erstellung/Anpassung von Vorlagen, Hilfe
  ** Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie
  ** Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden.
  ** Aufwand: Mittel
--* **Entwicklungsumgebung, Maven, Bamboo und Infrastruktur:**
--** Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur
--** Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung
--** Kümmert sich um die Builds in Bamboo (Anpassen von Plänen)
--** Kümmert sich um die Bereitstellung des Servers in der Arbi
--** Aufwand: Mittel
++* --**Entwicklungsumgebung, Maven, Bamboo und Infrastruktur:**--
++** --Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur--
++** --Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung--
++** --Kümmert sich um die Builds in Bamboo (Anpassen von Plänen)--
++** --Kümmert sich um die Bereitstellung des Servers in der Arbi--
++** --Aufwand: Mittel--
  * **GUI-Beauftragter:**
  ** Da i.d.R. noch nicht viel Erfahrung im Bereich der Entwicklung von Oberflächen besteht, soll sich diese Rolle intensiv mit JavaFX auseinandersetzen
  ** Die Rolle soll Wissen grundsätzlich zu JavaFX aufbauen und als Ansprechpartner bei Fragen und Problemen dienen.
@@ -206,12 +206,12 @@
  * Sitzungsleitung und Moderation
  ** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master
  ** Tagesordnung definieren (vorher)!!
--** 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.
++** 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.
  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]]
  * Protokollführung
  ** Erstellung eines Protokolls der Gruppensitzung
  ** Hier reicht i.d.R. ein Ergebnisprotokoll
--** Protokolle müssen im Confluence abgelegt sein
++** Protokolle müssen im Wiki abgelegt sein
  * Zu Beginn jeder Gruppensitzung („Daily Scrum“):
  ** findet ein kurzes „Briefing“ („Blitzlicht“) statt, in der jede/r berichtet, was sie/er in der letzten Woche für das Projekt getan hat.
  * Am Ende jeder Sitzung neue Aufgabenverteilung

Changes for page Anforderungen Gruppen

Summary

Details

Applications

Navigation