swt23w23/src/main/asciidoc/protocols/2023-10-27.adoc

// vim: set spell spelllang=de:
// SPDX-License-Identifier: Apache-2.0 AND AGPL-3.0-or-later
// SPDX-FileCopyrightText: 2015 Sven Seemann
// SPDX-FileCopyrightText: 2015 Oliver Drotbohm
// SPDX-FileCopyrightText: 2017 Jan Falkenberg
// SPDX-FileCopyrightText: 2017 Marc Kandler
// SPDX-FileCopyrightText: 2023 swt23w23
= Protokoll Gruppe 23

Treffen am 2023-10-27

Ort:      APB/E010 +
Beginn:   14:50 Uhr +
Ende:     16:42 Uhr

__Schriftführer:__ Simon Bruder

*Nächstes Treffen:* +
2023-11-03, 14:50 Uhr, APB (Treffpunkt: Foyer)

__Teilnehmer:__

[%header]
|===
|Name|Rolle|Bemerkung
|Denis Natusch||
|Eren Asker||BBB
|Erik Hohlfeld||
|Jacob Benjamin Fasshauer|Kunde, Tutor|
|Mathis Kral|Scrum Master|
|Paul Heimer||BBB
|Simon Bruder|Schriftführer|
|Theo Reichert||
|===

== Bemerkungen

Es wird angemerkt,
dass es beim Pflichtenheft vor allem auf die Konsistenz ankommt.
Die Anforderungen seien soweit alle bereits im Pflichtenheft abgedeckt
und auch ansonsten ist es (im positiven Sinne) unauffällig.
Sollten nach der Abgabefrist kleinere Fehler angemerkt werden,
sollen diese bis zum nächsten Treffen behoben werden.
Bei größeren Fehlern werden 2 Tage Zeit gegeben,
um das Pflichtenheft zu überarbeiten

Im Verlauf werden individuelle Fragen zum Videoshop beantwortet.

Auf eine Nachfrage wird erklärt,
dass Konfigurationen für eine Entwicklungsumgebung mit Nix von den Teilnehmern hinzugefügt werden können,
solange dabei die bestehende Struktur nicht verändert wird.

Als Nachtrag wird folgendes als zusätzliches Kann-Kriterium bekannt gegeben:
Die Mitarbeitenden von Mampf sollen ein Benutzerkonto besitzen,
mit dem sie sich anmelden können
und ihre Zuteilungen zu den Events,
sowie ihre Arbeitszeitaufstellung einsehen zu können.
Die Konten hierfür werden vom Administrator erstellt.

Diese Anforderung war ursprünglich als Muss-Kriterium geplant,
wurde jedoch bei der Vorstellung vergessen
(bzw. auf eine Nachfrage im letzten Treffen nicht erwähnt)
und wird daher auf ein Kann-Kriterium herabgestuft.

Als Abschluss des Videoshops muss von den jeweiligen Teilnehmern ihr Code erklärt werden.
Dies soll bereits vor dem nächsten Treffen stattfinden.
Der Termin hierfür wird zeitnah bekannt gegeben.

Es wird bereits auf die Zwischenpräsentationen in der 5. Woche hingewiesen.

Schließlich wird noch verkündet, dass Yucheng Yang die Gruppe verlassen hat,
sie also nur noch aus sieben Mitgliedern besteht.

== Retrospektive des letzten Sprints

Seit dem letzten Treffen wurde der Entwurf des Pflichtenheftes verfeinert,
so dass nur noch kleinere Änderungen notwendig sind.

== Aktueller Stand

Bei der individuellen Arbeit am Videoshop sind die meisten bereits fertig,
einige haben jedoch noch den Großteil zu erledigen.

== Planung des nächsten Sprints

Ab nächster Woche soll die Arbeit in den Zweierteams beginnen.
Durch Yuchengs Verlassen muss eine Person alleine arbeiten.
Hierfür meldet sich Theo freiwillig.

Weiter werden folgende Teams festgelegt:

- Erik und Mathis
- Denis und Eren
- Paul und Simon

Die Aufgabe des nächsten Sprints besteht darin,
Anwendungsprototypen zu erstellen,
was zwei Bereiche umfasst.

Zum einen soll ein Grobentwurf als Teil der Entwicklungsdokumentation in der ganzen Gruppe erstellt werden.
Dieser umfasst unter anderem die Verfeinerung des Analysediagramms aus dem Pfichtenheft.
Inwiefern die Diagramme aufgeteilt werden müssen,
wird nachgereicht.

Zum soll der komplette Umfang des Projektes in vier _Features_ aufgeteilt werden,
wobei für jedes in den Zweierteams ein Prototyps erstellt werden soll.
Es ist nicht geplant,
diese mit in das Endresultat des Projektes zu übernehmen,
bei einer umfangreichen Ausarbeitung ist dies jedoch möglich.
Das Ziel ist,
alle vier Feature-Branches (einer pro Gruppe)
in einen Branch zu mergen.
Beim Prototypen wird vor allem das Frontend im Vordergrund stehen,
jedoch soll darauf geachtet werden,
dass innerhalb eines Zweierteams die Aufgaben(typen) auf beide gleich verteilt sind.

Bei einer Diskussion über die Aufteilung werden drei verschiedene Vorschläge gemacht.

Der erste Vorschlag orientiert sich an den Anwendungsfällen:

- _Personalverwaltung_
- _Inventarverwaltung_
- _Berechtigung eines Kundens_
- _Berechtigung eines Nutzers_ und _Ohne Authentifikation_

Der zweite Vorschlag umfasst folgende Teile:

- Admintätigkeit 1 (Inventar, Personal)
- Admintätigkeit 2 (Kalender, Kundenkonten, Einsehen von Aufträgen)
- Auftrag/Event buchen (noch ohne Validierung)
- Login/Registrierung und Einsehen des Angebots

Der dritte Vorschlag trifft folgende Einteilung:

- Autorisierung
- Administratortätigkeit (Inventar, Personal)
- Sehr vereinfachte Form der Auftragsbuchung (Kunde kann vereinfachten Auftrag eintragen und Admin kann diesen sehen)
- Kalender (Übersicht und Eintragung einer groben Zeitverteilung in den Kalender für Personal und Inventar)

Da während des Treffens keine Einigung getroffen werden konnte,
entscheiden sich die Teilnehmer,
die genaue Festlegung erst am Dienstag zu treffen.
Bis dahin soll eine provisorische Aufgabenverteilung gelten
und die zugeteilte Gruppe soll sich hierfür lediglich mit dem Frontend mit Fokus auf den Aufbau beschäftigen.
Allgemein sollen sich alle bis dahin auch Gedanken zum Grobentwurf machen,
da hierdurch die Einteilung in Gruppen durch eine klarere Sicht auf die Abhängigkeiten vereinfacht wird.

Die Aufteilung hierfür wird folgendermaßen festgelegt:

[%header]
|===
| Gruppe       | Aufgabe
| Denis, Eren  | Einsicht des eigenen Profils für Kunde
| Denis, Eren  | Mitarbeiterübersicht, Mitarbeiter hinzufügen
| Erik, Mathis | Auftragsliste für Kunde und Administrator
| Erik, Mathis | Eventplanungs-Formular für Kunden (Auftrag erstellen)
| Erik, Mathis | Kundenübersicht für Administrator
| Paul, Simon  | Inventarübersicht, Inventar-Item hinzufügen
| Paul, Simon  | Login/Registrierung
| Theo         | Kalender
|===