teamdocumentation.adoc

Teamdokumentation

Diese Dokumentation fixiert die während des Entwicklungsprozesses aufgetretenen Probleme und Lösungen, sowie die Entscheidungen die das Team in der Entwicklung getroffen hat.

Note	Constrains: Was für Probleme sind aufgetreten? Welche Entscheidungen wurden getroffen oder geändert? Warum? Welche Wochenziele wurden gesetzt und wurden diese eingehalten.

Probleme und Lösungen

Aufgabenteilung

Die Aufgabenaufteilung im Team bzw. in Teams von 2 Personen gestaltete sich schwierig. Oft kam es dazu, dass die Vorstellungen der konkreten Implementierungen, trotz der gleichen Idee sehr unterschiedlich waren. Als das Projekt noch klein war, gab es zudem nicht genug unabhängige Baustellen für jedes Team.

• Wir haben stets versucht viel zu kommunizieren (teilweise zu viel), um Missverständnisse auszuräumen, Implementierungen zu fixieren und Aufgaben sinnvoll aufzuteilen.

Remote Praktikum

Die Verlegung des Praktikums ins Home Office führt zu Problemen in der Kommunikation und Koordination der Teams und somit zu einem Produktivitätsverlust.

• Mithilfe von Hangouts konnten wir einen neuen Workflow in unsere Arbeit integrieren und des Weiteren an getroffenen Reglements festhalten. Es hat allerdings Zeit gekostet, bis sich die Teammitglieder auf die neue Arbeitsweise eingestellt haben. Dadurch konnten einige geplante Features nicht fertiggestellt werden.

Permission System

Es gab inhaltliche und softwaretechnische Diskrepanzen, wie und in welchem Umfang das Permission System implementiert werden soll. Deshalb wurde die Software häufig diskutiert und geändert, ohne konkreten Mehrwert zu liefern.

• Wir haben uns entschieden das Permission System so spät wie möglich zu implementieren und dann an die Gegebenheiten des Domainmodel anzupassen. Bis zur grundlegenden Implementierung des Domainmodels, gab es bei uns nur den User Studentin.Erst in der letzten Woche konnten wir eine klare Differenzierung der Rollen erarbeiten und diese implementieren.

Security/Keycloak

Die Implementierung/Nutzung der Security Frameworks gestaltete sich, vor allem aufgrund der mangelnden Erfahrung diesbezüglich im Team, als Herausforderung. Insbesondere die Implementierung von Keycloak in unsere Infrastruktur und Tests war ein größeres Hindernis, als wir ursprünglich angenommen haben.

• Die meisten Fragen konnte durch Ausprobieren oder in Zusammenarbeit mit den Betreuern gelöst werden. Für das Testen haben wir eine Mock-Konfiguration gefunden welche den Tests Zugriff auf die nötigen Routen ermöglicht. Da auch die Keycloak Demo erweitert wird bleibt dies aber ein fortlaufender Prozess.

wiederkehrende Diskussion über die Architektur

Obwohl wir uns zu Beginn für eine Onion Architektur entschieden haben, traten während der konkreten Umsetzung dieser Architektur und der Datenbankanbindung immer wieder Diskussionen auf, ob eine Schicht Architektur nicht sinnvoller ist.

• Um eine Analyse Paralyse zu vermeiden haben wir uns nach einer erneuten Abstimmung endgültig dazu entschieden, die Onion Architektur durchzuführen.

Pull Request Review

Aufgrund unterschiedlicher Standards bezüglich der Code Review zu Beginn des Projektes kam es häufiger zu Merges in den Dev Branch, welche nicht den gemeinsam vereinbarten Standards entsprachen.

• Es hat sich etabliert, dass Die Review von Personen/Teams durchgeführt wird, welche nicht direkt an der Erstellung des PRs beteiligt waren. Bei größeren PRs setzten sich meist eine "PR-fremde" und eine involvierte Person zusammen, damit inhaltliche Fragen direkt geklärt werden können.

Datenbankdiskussion

Bereits vor der ersten Implementierung entstanden viele Diskussionen, wie die Daten zu persistieren sind und ob aktuelle Ansätze der Implementierung performante Datenbankzugriffe für Anwendung und Tests ermöglicht.

• Wir haben uns dazu entschieden, Datenbank- und Modellimplementierung konsequent differenziert zu behandeln und umzusetzen.

MinIO

Wir hatten die Idee MinIO zu nutzen um Daten und Bilder zu speichern. Die Konfiguration von MinIO war sehr Zeit intensiv, lückenhaft dokumentiert und wir hatten keine Accounts, um das Ganze zu testen.

• Wir haben also die Integration von MinIO abgebrochen und uns auf andere Themen fokussiert.

Wochenziele

Woche 1

Ziel

• einheitliche Konfiguration der IDE sowie der CI

• Festlegen von Regeln und Workflows für das Team

• Einigung auf eine Architektur sowie ein Model, welches dann anschließend implementiert werden soll.

• Das Ziel konnte am Ende der Woche termingerecht erreicht werden, Fortschritt wurde in den Masterbranch integriert.

Woche 2

Ziel

• Integration eines ersten Spikes in das Projekt.

• Ein erster kleiner Workflow im Gesamtsystem sollte möglich sein.

• Das Ziel konnte nicht termingerecht erreicht werden. Gründe dafür sind aus dem Kapitel Probleme und Lösungen zu entnehmen.

• Letztendlich wurde das Ziel dennoch erreicht.

Woche 3

Ziel

• Integration der Anwendungslogik, sodass die ersten Userstories durchgeführt werden können.

• Am Ende der Woche war es möglich die komplette Struktur eines Forums, sprich über Topics, Threads und Posts, durch zu klicken.

• Mit diesem Meilenstein waren wir zuversichtlich, jetzt deutlich schneller weitere Features zu entwickeln.

Woche 4

Ziel

• Funktionsfähige Anwendung, weitestgehend ohne Bugs und den gängigen Qualitätszielen guter Software entsprechend.

• Suchfunktionalität integrieren.

• einen Moderationsmodus integrieren.

• Löschen von Beiträgen, Themen und Antworten muss möglich sein.

• Permissionsystem muss weitestgehend integriert sein.

• Anonymer Modus integrieren.

• Letzte Änderungen je Thread und Forum anzeigen.

• Die Hoffnung am Ende der 3. Woche hat sich erfüllt ! Feature konnten sehr schnell umgesetzt werden.

• Zur Verbesserung der Softwarequalität und der UX haben einige Teammitglieder auch Zeit nach dem Ende des Praktikums (freiwillig) in Anspruch genommen. Ohne diese Arbeit wären gewisse Qualitätsziele nur ungenügend eingehalten worden.