Update Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

@@ -312,6 +312,17 @@ Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 
 ## Sprints und Meetings (in Zukunft ja asynchron)
 
+Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
+
+- Der "Last-Minute-Commit"-Druck: In den Stunden unmittelbar vor dem Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger oder unzureichend getesteter Code („Quick and Dirty“) in das Repository gepusht wurde.
+- Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting eintrafen, blieb dem restlichen Team keine Zeit für fundierte Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche statt für strategische Planung genutzt.
+- Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
+
+Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
+- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
+- Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
+- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
+
 # Modules
 ## Mass Mailer
 ## Event Registration