Das Team FINAS Quick-Check ÖD bestand aus zwei Softwareentwicklern (Backend/Architektur und Frontend), einer Business Analystin, einem Product Owner sowie Martin als Agile Coach. Da wir in unserer Digital Factory Unternehmenskunden bei der Umsetzung ihrer IT-Projekte unterstützen, war für die Zusammenstellung des Teams natürlich zunächst die aktuelle Verfügbarkeit ausschlaggebend. Ebenso wurden unsere individuellen Stärken und Interessen bei der Auswahl mit einbezogen. Das Projekt sollte zudem Gelegenheit geben, uns in gewissen Bereichen weiterzubilden. Daher hatten wir auch den Freiraum, neue Tools und Ansätze auszuprobieren.
Aufgrund der überschaubaren Teamgröße und dem explorativem Ansatz, haben wir uns als Team auf Kanban mit Einflüssen aus Scrum als Projektmethodik geeinigt. Kanban ist ein nützliches Werkzeug zur Koordination und Kommunikation im Team – vor allem, wenn die Personen im Team unterschiedliche Aufgabenbereiche haben, so wie es bei uns der Fall war. Durch die Visualisierung des Entwicklungsprozesses auf dem Kanban-Board konnten wir immer schnell erkennen, an welchen Stellen es gegebenenfalls noch hakt.
Jeden Morgen haben wir uns in einem Daily im Team gegenseitig kurz über den aktuellen Fortschritt des Projekts abgestimmt und eventuelle Probleme besprochen. Hinzu kamen wöchentliche Demo-/Planning-Meetings, in denen wir uns den Gesamtfortschritt des Projekts angeschaut, etwaige Engpässe identifiziert und Strategien zur Verbesserung der Effizienz des Entwicklungsprozesses diskutiert haben. Unser Product Owner achtete dabei darauf, dass wir auf dem richtigen Weg blieben und das Endprodukt den Kundenanforderungen entspricht. Last but not least lud uns Martin, unser Agile Coach, in größeren zeitlichen Abständen zur Retrospektive ein. Hier konnten wir uns über die übergeordneten Ziele, das aktuelle Befinden im Team und mögliche nicht technische Probleme austauschen und Lösungen dafür erarbeiten. Diese Meetings waren sehr wertvoll für uns, da sie uns als Team stärker gemacht haben.
Für eine gute und zielführende Zusammenarbeit ist es wichtig, ein gemeinsames Verständnis über ein paar grundlegende Dinge zu haben. Eines ist davon ist die Definition of Ready (DoR). Bei der DoR handelt es sich um eine festgelegte Liste von Kriterien, die erfüllt sein müssen, bevor eine User Story oder eine andere Aufgabe in den Sprint aufgenommen werden kann, bzw. in unserem Fall in die Umsetzung ging.
Unsere DoR sah so aus:
Damit wussten wir jetzt zwar wie eine Story aussehen sollte, jedoch nicht, wann sie eigentlich fertig umgesetzt ist. Im nächsten Schritt haben wir daher gemeinsam eine Definition of Done (DoD) festgelegt, sprich, die Anforderungen, die erfüllt sein müssen, bevor eine Story als abgeschlossen gilt. Eine klare und einheitlich formulierte DoD hilft dabei, die Qualität der Arbeit zu verbessern und die Arbeit im Team zu fördern. Je nach Team und Projekt kann sie variieren, umfasst aber typischerweise Aspekte wie das Durchlaufen von Tests, die Dokumentation, die Freigabe durch den Kunden oder Product Owner sowie die Integration in den Produktionsprozess.
Für das Projekt FINAS Quick-Check ÖD haben wir uns auf die folgende DoD geeinigt:
Nachdem unser Team soweit startklar war, haben wir auf Grundlage der Ergebnisse aus der Foundation Phase die Gesamtarchitektur und den Programmablauf der Anwendung konzipiert. Zur Erinnerung: In der Foundation Phase wurden die Business Treiber, die fachlichen Anforderungen, die Umwelt der Anwendung, nicht funktionale Anforderungen sowie die Story Map inklusive MVP und initialem Backlog ausgearbeitet. Eine wichtige Anforderung dabei war, dass die Anwendung schnell, einfach und kostengünstig bereitgestellt wird. Aus diesem Grund haben wir uns für eine Implementierung als Cloudanwendung mit folgendem architekturellem Aufbau entschieden:
Für die Umsetzung des Frontends haben wir Angular als Framework genutzt, im Backend kam Spring Boot zum Einsatz. Zur Durchführung der versicherungsmathematischen Berechnungen greift die Anwendung auf unseren FINAS Rechenservice Versorgung Öffentlicher Dienst zu. Neben der eigentlichen Anwendung, die sich an Endkunden richtet und über den Browser aufgerufen wird, ist der Administrationsbereich ein wesentlicher Bestandteil. Versicherungs- und Finanzdienstleistungsunternehmen, die den FINAS Quick-Check ÖD auf ihrer Website als zusätzlichen Service für ihre Kundschaft bereitstellen, können hierüber die Anwendung nach ihren Bedürfnissen anpassen. Das umfasst z.B. die Änderung der Farbwelt, Ergänzung von Links oder die Hinterlegung des eigenen Logos. In dem Zusammenhang war speziell das Thema 'Mandantenfähigkeit' ein wichtiger Punkt, den wir bei der Entwicklung mit berücksichtigen mussten.
Der finale Programmablauf unseres FINAS Quickcheck ÖD sah im Detail dann so aus:
Nach Aufruf der Startseite können die individuellen Angaben, z.B. Datum des Eintritts in den öffentlichen Dienst oder Erfahrungsstufe, hinterlegt werden. Sind alle notwendigen Informationen eingegeben, führt der FINAS Rechenservice Versorgung Öffentlicher Dienst die entsprechenden Berechnungen durch. Im Ergebnis werden das persönliche Ruhegehalt bei regulärem Pensionsbeginn, bei vorzeitigem Ruhestand und bei Dienstunfähigkeit angezeigt sowie ein Call-to-Action-Button, mit der Möglichkeit direkt Kontakt aufzunehmen. Der Administrationsbereich zur Anpassung des FINAS Quick-Check ÖD ist für Endkunden nicht sichtbar.
Im Folgenden möchte ich gern näher auf zwei Tools eingehen, die wir bei der Entwicklung des Frontends genutzt haben:
Wie oben bereits erwähnt, haben wir zur Umsetzung des Frontends die neueste Version des Angular Frameworks¹ genutzt, welche eine deutlich schickere Möglichkeit zur Implementierung einfacherer Komponenten bietet. Angelehnt an andere Typescript Frameworks, wie React, ist es nun möglich Template-, Styling-, Test- sowie Module-Dateien direkt in nur einer einzigen Typescript-Datei zu formulieren. Das vermeidet unnötigen Code und erhöht die Übersichtlichkeit in komplexen Projekten. Zudem erleichtert es Neulingen den Zugang zur Angular typischen Architektur.
Im Projekt haben wir uns dazu entschieden, einfache Komponenten als Standalone zu erstellen und für diese eine gemeinsame Styling Datei zu hinterlegen. Der Vorteil: Leere oder einzeilige Dateien können so vermieden werden.
Eines der Tools, das wir innerhalb des Projekts neu ausprobiert haben, war NgRx. Hierbei handelt es sich um eine State-Management-Bibliothek für Angular-Anwendungen, die auf der Redux-Architektur basiert und einige nützliche Features parat hält:
Zentralisierte Zustandsverwaltung: NgRx bietet einen zentralen Speicher für den Zustand der Anwendung. Die Verwaltung und der Zugriff auf den Zustand aus verschiedenen Komponenten werden so vereinfacht. Ebenso entfällt damit in manchen Anwendungsbereichen die Notwendigkeit, Daten zwischen den Komponenten über Input- und Output-Bindings weiterzugeben. Die Philosophie der 'Single Source of Truth' kommt hierbei zur Anwendung und erleichtert das Finden von Fehlern sowie die Einarbeitungszeit in den Code, wenn man mit diesem nicht vertraut ist.
Vorhersagbare Zustandsänderungen: Zustandsänderungen werden durch ein striktes Muster verwaltet. Das Muster stellt sicher, dass alle Änderungen am Zustand vorhersehbar und nachvollziehbar sind. Das kann dazu beitragen, dass die Anwendung zuverlässiger und einfacher zu debuggen ist.
Zeitreise-Debugging: Mit NgRx können die Redux DevTools verwendet werden, um die Zustandsänderungen der Anwendung zu debuggen. Das ermöglicht, Änderungen des Zustands der Anwendung im Laufe der Zeit einzusehen. Sehr hilfreich, wenn es darum geht, einen Fehler aufzuspüren oder zu verstehen, wie eine Anwendung funktioniert.
Wiederverwendbarkeit des Codes: NgRx bietet ein gut definiertes Muster für die Behandlung von Zustandsänderungen. Ist das Muster einmal gelernt, kann man es auf verschiedene Teile der Anwendung angewendet werden. Dadurch lässt sich der Code wiederverwenden und ist leichter zu pflegen.
Neben den vielen Vorteilen gibt es aber auch einige potenzielle Herausforderungen und Probleme, die bei der Verwendung auftreten können:
Erhöhte Komplexität: Die Verwendung kann die Komplexität der Anwendung erhöhen, da die Redux-Architektur erlernt und das NgRx-Muster befolgt werden müssen. Dies kann das Verständnis und die Wartung der Codebasis erschweren.
Lernkurve: Trotz steiler Lernkurve kann es einige Zeit dauern, zu verstehen, wie es funktioniert und sich effektiv einsetzen lässt. Auch das kann zur Komplexität der Codebasis beitragen.
Boilerplate-Code: Die Einrichtung kann eine Menge Boilerplate-Code erfordern, was den Einstieg erschweren und zu ausführlicherem Code führen kann.
Performance-Overhead: Die Verwendung kann zu einem gewissen Performance-Overhead in der Anwendung führen, da zusätzliche Verarbeitungsschritte für die Bearbeitung der Zustandsänderungen erforderlich sind. Dieser Overhead ist jedoch in den meisten Anwendungen vernachlässigbar.
Dependency Injection: NgRx erfordert die Verwendung von Dependency Injection, die vielleicht nicht allen Entwicklern und Entwicklerinnen vertraut ist. Dies kann die Einrichtung erschweren und die Komplexität der Anwendung erhöhen.
Mein Fazit zu NgRx:
Insgesamt ist es ein nützliches Werkzeug zur Verwaltung des Zustands einer Angular-Anwendung, insbesondere, wenn die Anwendung einen komplexen Zustand hat, der über mehrere Komponenten hinweg geteilt werden muss. Es gibt zwar einige potenzielle Herausforderungen bei der Verwendung, die jedoch durch eine angemessene Planung, Schulung und bewährte Verfahren bewältigt werden können.
Wenn es um das Frontend geht, ist die technische Umsetzung aber nur eine Seite der Medaille. Nicht weniger wichtig ist das Design, also das, was der Endkunde zum Schluss sieht. Um ein konsistentes visuelles Markenerlebnis zu schaffen, sollte das Corporate Design bei der Entwicklung berücksichtigt werden. Der Administrationsbereich, in dem unsere Kunden die Anwendung nach ihren Anforderungen anpassen können, spielt deshalb eine große Rolle. Für die Standardversion der Software haben wir uns an den Vorgaben unseres unternehmenseigenen Styleguides orientiert. Hier einige der Punkte, die für uns in Bezug auf das Design relevant waren:
Konsequente Verwendung der Markenfarben: Die Markenfarben ziehen sich durchgängig durch das gesamte Design der Anwendung, um ein einheitliches visuelles Erlebnis zu schaffen.
Typografie: Die Typografie sollte zur Markenidentität und der Zielgruppe passen. Für unseren FINAS Quickcheck ÖD haben wir als Default unsere Cegeka-eigene Schriftart gewählt.
Einbindung des Logos: Das Logo ist die visuelle Repräsentation einer Marke. Es sollte daher gut sichtbar platziert, z.B. in der Kopf- oder Fußzeile, und einheitlich in der gesamten Anwendung verwenden werden.
Einheitliche Tonalität: Auch das Wording innerhalb der Anwendung muss mit der Markenidentität übereinstimmen (z.B. Ansprache 'Du' oder 'Sie'), um ein einheitliches Markenerlebnis zu schaffen.
Design-Test: Es ist wichtig, das Design auf verschiedenen Geräten und Browsern ausgiebig zu testen, um sicherzustellen, dass es responsiv und funktional ist und zu einem positiven Nutzererlebnis beiträgt. Für den Test der Anwendung haben wir Lambdatest genutzt – eine Cloud-basierte Plattform, die die Durchführung von Cross-Browser-Tests für zahlreiche Browserkonfigurationen und Betriebssysteme ermöglicht, einschließlich Smartphones, Tablets und Desktop.
Für mich als Frontendentwickler war das Projekt eine tolle Erfahrung. Es hat Spaß gemacht, in einem gut eingespielten Team zu arbeiten, eigene Ideen einzubringen und Neues auszuprobieren. Aber mit dem Frontend allein war es natürlich nicht getan. Schließlich musste unser FINAS Quick-Check ÖD ja noch in die Cloud gebracht werden...
Mehr zum Thema Deployment in die Cloud & CI/CD-Pipeline dann demnächst im Artikel von Peter.
¹ Weitere Informationen unter https://angular.io/guide/releases
² Weitere Informationen unter https://ngrx.io/