Add protocol from 2023-10-27

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

@@ -0,0 +1,155 @@
+// vim: set spell spelllang=de:
+= Protokoll Gruppe 23
+
+Treffen am 2023-10-20
+
+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
+|===