Eine Sprache, mehrere Betriebssysteme: Cross-Plattform-App mit Flutter

Wenn eine App unabhängig von dem Betriebssystem funktioniert, dann ist es in der Regel eine Cross-Plattform-Anwendung. Eine besondere Entwicklungsweise sorgt dafür, dass automatisierte Übersetzungsmechanismen zwischen den Plattformen greifen können und damit weder App noch User an ein bestimmtes System gebunden sind. Zusammen mit einem Kunden aus dem Bankensektor haben wir das Entwicklungs-Kit Flutter für deren Usecases evaluiert. Die Herausforderung dabei: Mehrere Teams sollten an festgelegten Bereichen der App parallel arbeiten können. Egal, ob in Android oder iOS.

Anforderungsworkshop: Welche Ziele sollen mit der Flutter-App erreicht werden?

Bevor ein Projekt startet, gehen wir in den direkten Austausch. In den Anforderungsworkshops ist das Ziel, den Kern des Problems der Auftraggebenden besser verstehen zu können. Es ist uns wichtig, dass in diesen Terminen sowohl von der fachlichen (z.B. Business Analyst) als auch von der technischen Seite (Software Developer) Expert*innen aus dem CodeCamp:N dabei sind. Das ist essenziell, um die Wünsche genau zu verstehen und einen konkreten Fahrplan zu entwickeln.  

In den beiden Anforderungsworkshops konnten diese Detailfragen geklärt werden:  

• Gibt es Umsysteme, die an die Neuentwicklung angeschlossen werden müssen? Wenn ja, welche?
• Gibt es bereits konkrete Implementationswünsche?
• Welche Abteilungen und Ansprechpartner*innen müssen involviert werden?  

Es ist uns dabei wichtig mit unseren Kunden auf Augenhöhe zu interagieren und eine gemeinsame Vertrauensbasis zu bilden. Nur so ist es möglich, in der Entwicklungsphase die Wünsche unserer Auftraggebenden perfekt umzusetzen und schnelle Entscheidungen herbeizuführen.  

Die Entwicklungsphase: Teams bilden, Code schaffen.

Bepackt mit den Anforderungen an die Software legt das Entwicklungsteam los. Dabei geht es nicht nur um die Programmierung der App, sondern einen ganzheitlichen Prozess. Im Geschäftsbereich TechHub legen wir großen Wert darauf, crossfunktionale Teams aufzustellen.  

Unsere Software-Developers werden unterstützt durch:

• Scrum Master
• Business Analysts
• Software Architects (Anfangsphase)  

Entwicklungsphase 1 der Flutter-App: Proof of Concept (POC)

Ein Proof of Concept wird in der Regel im Vorfeld der eigentlichen Entwicklung gebaut, um eine bestimmte Hypothese zu verproben. Im Falle unser Banking App hieß das, zu ergründen, ob Flutter ein geeignetes Framework für die Wünsche unserer Auftraggebenden ist.

In der POC-Phase erfolgte die Entwicklung nicht mit realen Daten oder bereits ausformulierten fachlichen Anforderungen. Der Fokus lag auf der Validierung von Flutter.  

Neben der Entwicklung der App nutzen wir diese Phase auch um weitere Informationen zu sammeln und aufzubereiten. Das hilft uns vor allem in den nächsten Phasen, wenn es darum geht, Fahrt aufzunehmen.  

In dieser Phase bestand das Team aus einem Business Analyst und einem Software Developer. Für einen PoC eine gängige Konstellation, da es noch nicht um ein finales Produkt geht.   Unsere Kolleg*innen erfahren in dieser Phase schon viel über das Zielbild der Auftraggebenden und können so gezielt Impulse für die spätere Entwicklung setzen. Neben der Validierung von Flutter war auch die Erprobung eines Modells zur Zusammenarbeit an der App-Entwicklung zwischen mehreren Feature-Teams erforderlich.

Wir haben uns dabei zwei mögliche Arten des Projekt-Setups angesehen und verglichen:  

• Mono-Repository der Flutter-App (ohne zusätzliche Orchestrierung)
• Dynamisch aufgebautes Code-Repository (orchestriert mitMelos)  

Die Bewertung der beiden Ansätze erfolgte anhand festgelegter Anforderungskriterien der Auftraggebenden. Wichtig dabei war die einfache Handhabbarkeit bei Änderungen und die Integration von neuen Features im Code.  

Am Ende erarbeiteten wir eine Empfehlung für das weitere Vorgehen. Regelmäßiges Feedback wurde in Review- & Feedbackterminen alle 2 Wochen eingeholt. Somit konnten wir schnell reagieren, falls Fragen aufkamen.  

Entwicklungsphase 2 der Flutter-App: App-Entwicklung & Wissenstransfer

Nach erfolgreicher POC-Phase ging es in die eigentliche Entwicklungsphase der App. Das bedeutet, dass unser Team enger mit Ansprechpartner*innen aus Fachabteilungen und internen Expert*innen für das Thema in den Austausch geht.  

Oft wird bei externen Software-Entwicklungsprojekten erst sehr spät klar, wer den Betrieb der Software, sowie Wartung und Weiterentwicklung übernimmt. Das führt dazu, dass i.d.R. Auftraggebende erst in einer sehr späten Phase des Projekts wichtige Informationen von Dienstleistenden übergeben bekommen. Wir wollen das vermeiden.  

Transparenz ist uns wichtig: Wir treten dafür ein, dass diese wichtigen Punkte bereits in einem frühen Projektstand geklärt sind, sodass im späteren Verlauf keine „bösen Überraschungen“ auf beiden Seiten entstehen.

In unserem Fall war zu Beginn klar, dass wir den Weg für die Entwicklung der App gemeinsam mit einem Inhouse-Team des Kunden bestreiten und dieses Team auch den Betrieb der App übernehmen wird. Dies hat uns geholfen, die Entwicklung noch stärker an die Bedürfnisse der Software-Developers vor Ort beim Kunden auszurichten und so gezielt vorhandene Synergien zu nutzen.

Zum Ende unserer Projektphase konnten wir so einen reibungslosen Übergang gewährleisten.

Fazit: Learnings und Take-aways

Gemeinsam mit unseren Auftraggebenden konnten wir in kürzester Zeit eine Mobile-App für den Banking -Bereich entwickeln und den ersten Test ausrollen. Während der Entwicklungsphase hatte für uns die Nähe zum Kunden und dessen Entwicklungsteam oberste Priorität. Der Austausch half uns von Anfang an, schnell Fahrt aufzunehmen und zielgerichtet Wert zu schaffen.

Take-away #1: Features priorisieren

Eine der treibenden Herausforderungen für die Entwicklung der App war die Zeit: viele Features, sportliche Timeline. Dabei definiert sich die Bearbeitungszeit nicht nur aus der reinen Feature Programmierung. Auch die Zeit für Lösungsentwicklung und Fehlerbehebung muss bedacht werden.  

Wir haben daher frühzeitig von mehreren Parteien Informationen zum Umfang der finalen App eingeholt und besprochen, was bis zum gewünschten Release-Termin realistisch ist. So gelang es uns, Features zu priorisieren und schnell in die Ausführung zu kommen. Gemeinsam mit den Auftraggebenden konnten wir priorisieren, welche Features essenziell und welche nice-to-have sind. Wir konnten klären, dass eine fortlaufende Erweiterung problemlos möglich ist.

Take-away #2: Fakten schaffen

In der POC-Phase haben wir bereits durch verschiedene Vorgehensweisen aus Projektmanagement und Business-Analyse Leitfäden zur Ermittlung der Schwerpunkte erstellt. Damit konnten wir in kurzer Zeit viele Informationen zusammenzutragen und das weitere Vorgehen ermitteln. Beispiele sind die Produktumfeld-Analyse oder die Stakeholder-Matrix.  

Wir konnten somit unsere Auftraggebenden optimal abholen und Impulse für die weitere Entscheidungen geben. Außerdem halfen uns die Daten dabei, die Usecases der neuen App mit den Auftraggebenden klar zu diskutieren.‍

Take-away #3: Denke aktualisieren

Mit der Entwicklung der Flutter-App sollte eine bestehende App abgelöst werden. Wo vorher durch die Kombination von Web-Applikation und nativer App ein recht einfacher und sehr flexibler Aktualisierungsprozess vorhanden war, standen wir jetzt einer präziseren Planung gegenüber: Bei der App-Entwicklung muss man prinzipiell davon ausgehen, dass nicht alle Nutzer*innen sofort ihre App auf dem Handy aktualisieren. Die Denke, wie man daher Features entwickelt und ausrollt, ändert sich im Gegensatz zur Website-Entwicklung.

Take-away #4: Kommunikation etablieren

Je mehr Kolleg*innen in einem Team zusammenarbeiten, umso mehr direkte Kommunikationswege sind nötig.Das wiederum kostet mehr Zeit.    

Unser Vorschlag: Kommunikationszeit durch Pair- oder Mob-Programming verkürzen. Mit Pair-Programming können mehrere Kolleg*innen die Umsetzung eines Features verstehen und darauf aufbauen. Das hilft besonders größeren Teams dabei, effizient voranzukommen und fokussiert zu arbeiten.