Changes for page Anforderungen Gruppen

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

arrow_back From 20.4 to 20.3 From 22.2 to 22.1 arrow_forward

From version arrow_back 22.1 arrow_forward

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

Change comment: There is no comment for this version

To version arrow_back 20.4 arrow_forward

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

insert_drive_file Page properties

Content

@@ -111,75 +111,65 @@
  * 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
++* Aufwand: Sehr hoc
--**GitLab, 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>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] führen
++** Stundenzettelpflege überwachen
++** 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
++** 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.
++** Aufwand: Hoch
++* **OpenAPI, REST und Spring**
++** Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner
++* ** Git/Gitlab und Reviewbeauftragter:**
++** 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 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.
++** Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen
++** Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
++** Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig.
++** Aufwand: Geringer
++** Aufwand: Mittel.
++* **Codequalitätsbeauftragter und Patternbeauftragter:**
++** Überwachung von Codierungsstandards
++** Kennt sich mit Refactorings aus
++** Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
++** Kennt sich mit Tools wie: FindBugs, Checkstyle und SonarLint/Sonarqube aus.
++** Soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten
++** Die Gruppe bei der Anwendung der Pattern unterstützen
++** Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
++** Aufwand: Mittel
++* **Testbeauftragter:**
++** Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
++** Die Person stellt ggf. Mockito und JUnit vor
++** Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an
++** 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, 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
++* **Konfliktmanagement:**
++** Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
++** 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.
++*
++* **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.
++** Ganz wichtig sind in diesem Kontext auch Do and Don'ts, d.h. man sollte sich auch über Best-Practices bei JavaFX informieren.
++** Aufwand: Mittel (je nach angestrebter GUI auch Hoch).
--* 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>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HProjekttagebuch"]] führen
--* Stundenzettelpflege überwachen
--* 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
--* 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.
--* Aufwand: Hoch
--
--**OpenAPI, REST und Spring**
--
--* Kennt sich mit den entsprechenden Technologien aus und dient als Ansprechpartner
--* Aufwand: Kann sehr variieren
--
--**~ Git/Gitlab und Reviewbeauftragter:**
--
--* 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 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.
--* Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen
--* Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
--* Zusammen mit dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Merge-Requests zuständig.
--* Aufwand: Geringer
--* Aufwand: Mittel.
--
--**Codequalitätsbeauftragter und Patternbeauftragter:**
--
--* Überwachung von Codierungsstandards
--* Kennt sich mit Refactorings aus
--* Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
--* Kennt sich mit Tools wie: FindBugs, Checkstyle und SonarLint/Sonarqube aus.
--* Soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten
--* Die Gruppe bei der Anwendung der Pattern unterstützen
--* Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
--* Aufwand: Mittel
--
--**Testbeauftragter:**
--
--* Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
--* Die Person stellt ggf. Mockito und JUnit vor
--* Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an
--* 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, 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
--
--**Konfliktmanagement:**
--
--* Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
--* 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.
--
--
--
  === Projekttagebuch ===
  Im Projekttagebuch werden kurz und knapp die Ergebnisse der Sprints festgehalten und der Ablauf der Projekte als Ganzes dokumentiert.
@@ -201,13 +201,14 @@
  * Progammierkonzepte
  ** z.B. Dependency Injection mit Guice
++* Google Guava
  * DB-Zugriff:
  ** Installation/Überwachung der DB
++** JDBC
  * Spezialisten für verschiedene Teilthemen:
  ** Netzwerkkommunikation
  ** Regeln des aktuellen Spiels
  ** Weitere Frameworks
--** GUI
  = Anforderungen: Wechselnde Aufgaben innerhalb der Gruppe =

Changes for page Anforderungen Gruppen

Summary

Details

Applications

Navigation