Agile App - und Software-Entwicklung

Navigation aller Website-Bereiche

Management und Strategie

Das sollten Sie wissen

Agile App - und Software-Entwicklung

Laut dem Digitalverband Bitkom nutzten im Jahr 2020 bereits 79 Prozent der Bundesbürger ab 16 Jahren ein Smartphone. Das entspricht rund 56 Millionen Menschen. Für die öffentliche Verwaltung wird es daher wichtig, ihre Leistungen auch über mobile Anwendungen bereitzustellen. Der folgende Beitrag zeigt, wie die App-Entwicklung professionell und sicher gelingt.

Behörden-Apps auf dem Vormarsch

Jeder Besitzer eines modernen Smartphones wird sich schon einmal eine App heruntergeladen haben. Anwendungen für die Navigation, für das Banking , zum Abrufen von Mails oder die beliebten Messenger sind rasch über einen App-Store geladen. Den kleinen Anwendungen sieht man gar nicht an, dass dahinter mitunter sehr komplexe Entwicklungsprozesse stecken. Insbesondere Business-Apps benötigen häufig eine Anbindung an Datenbanken, Content-Management-Systeme oder andere Backend-Software.

Um die Komplexität zu beherrschen, Fehler zu minimieren und die Anforderungen stets an den aktuellen Kundenwünschen auszurichten, erfolgt die App-Entwicklung mit einer agilen Vorgehensweise. So ist es möglich, flexibel und zeitnah auf Veränderungen im Projektgeschehen oder auf veränderte Gesetzgebungen in der Verwaltung zu reagieren. Ein iterativer Entwicklungszyklus bildet hierbei die Grundlage und steuert die Arbeitsschritte. Jede Funktion einer App durchläuft sowohl zu Projektbeginn als auch im laufenden Projekt die verschiedenen Entwicklungsstufen wie die Anforderungsanalyse und die Konzeption, das Design , die Entwicklung, das Testing und den Betrieb.

Die Abbildung zeigt den iterativen Entwicklungszyklus: Anforderungsanalyse, Konzeption, Design, Entwicklung, Testing, Betrieb. Die Abbildung zeigt den iterativen Entwicklungszyklus. Die Abbildung zeigt den iterativen Entwicklungszyklus.


Projektstart auf Augenhöhe

Der erste Schritt in der Entwicklung ist die Anforderungsanalyse. Ein wichtiges Prinzip ist hierbei die transparente Kommunikation der Entwickler mit den Anwendern. Diesem Grundsatz folgend müssen schon zu Beginn die relevanten Stakeholder in das Projektgeschehen eingebunden werden, damit das Team auch wirklich alle Anforderungsquellen ermitteln kann. Diese Analyse ist enorm wichtig, da sich beispielsweise aus Gesetzen und branchenüblichen Standards neue Anforderungen ergeben können. Das spezifische Fachwissen der entsprechenden Mitarbeiter muss daher in die Analyse einfließen.

Es reicht aber nicht, die Anforderungen nur zu erfassen. Vielmehr müssen diese in Requirements Engineering Workshop s detailliert definiert werden, beispielsweise um implizite und explizite Anforderungen zu ermitteln. Bewährte Methoden sind Checklisten oder Interviews sowie Beobachtungstechniken wie Feldbeobachtung oder Apprenticing – hierbei schaut ein Projektmitglied einem fachlichen Anwender bei der Arbeit über die Schulter, um so mehr Wissen über die Abläufe zu sammeln. Zudem gibt es Design Thinking-Workshops. Diese sind besonders effektiv, wenn komplexe Problemlösungen und Anforderungen zu ermitteln sind oder der Einsatz von kreativen Methoden gewünscht ist.

Abschließend werden die Anforderungen in einem Product Backlog festgehalten. Dort fließen auch Anforderungen ein, die im Laufe des Projekts neu hinzukommen. Eine Priorisierung legt fest, in welcher Reihenfolge diese Funktionen umgesetzt werden, wobei fortlaufend eine Prüfung der Priorisierungen erfolgt.

Eine Vision entsteht

In der nun folgenden Konzeptionsphase wird mittels kundenzentrierter Arbeitstechniken, wie beispielsweise Use Cases und Personas, festgelegt, über welche Elemente und Funktionen die Applikation verfügen muss. Dabei wird oftmals ein Minimum Viable Product (MVP) definiert, das die erste Version einer App mit minimalem Funktionsumfang repräsentiert.

Der Product Backlog dient auch hier als zentraler Speicher aller Anforderungen. Aus der kontinuierlichen Priorisierung wird schließlich die wichtigste Funktion in einen Iterationsblock überführt, der einen Sprint definiert. Der Sprint ist eine eng definierte Teilaufgabe des Gesamtprojekts, die von einem Entwicklungsteam in definierter Zeit umgesetzt wird. Das Ergebnis kann eine neue und bereits getestete Programmfunktion sein, die anschließend mit dem Kunden in der Praxis erprobt wird. Durch die ständige Priorisierung des Product Backlogs ist es möglich, rasch auf veränderte Rahmenbedingungen oder auf neue Kundenwünsche einzugehen. So entsteht in den folgenden Schritten eine App , die den aktuellen Anforderungen oder Vorschriften entspricht.

Das Projekt nimmt Gestalt an

Bevor es in die konkrete Ausarbeitung der Design-Elemente geht, werden zunächst die zuvor definierten Use Cases mit Leben gefüllt. Erste Mockups oder Wireframes bilden die Prozesse ab, Elemente wie Eingabefelder werden platziert und Funktionen dargestellt. Häufig erleichtert ein Click Dummy das bessere Verständnis und ermöglicht zu einem sehr frühen Zeitpunkt eine erste Überprüfung der festgelegten Anforderungen. Um das gewünschte Nutzererlebnis zu erreichen, werden an dieser Stelle bereits Tests mit Anwendern durchgeführt. Ein Feedback aus der Zielgruppe ist besonders wertvoll, damit überprüft werden kann, ob die Nutzerführung intuitiv und zielgerichtet ist.

Zur Gestaltung des Designs werden verschiedene Faktoren und Einflüsse berücksichtigt. Zum einen müssen sich Entwickler an die Corporate Identity bzw. den Außenauftritt der Behörde halten. Zum anderen werden wichtige Aspekte wie Barrierefreiheit und Mehrsprachigkeit beachtet. Die Berücksichtigung von Human Interface Guidelines von iOS und Material Design von Android ist im Designprozess selbstverständlich, um ein natives Erlebnis für die Nutzer zu schaffen.

Umsetzung erfolgt mit Scrum

Der nächste Schritt ist die tatsächliche Entwicklung, die auf Basis des Scrum Frameworks erfolgt. Ein Scrum-Prozess ist ein agiles Vorgehensmodell, das die Entwicklung in Iterationsblöcke, also die bereits erwähnten Sprints, aufteilt. Ein Sprint hat eine Dauer von ein bis vier Wochen. Wird zu Anfang beispielsweise eine Sprintdauer von drei Wochen festgelegt, wird sie im Projektverlauf beibehalten, um Stabilität zu gewährleisten.

Das Vorgehensmodell Scrum sieht verschiedene Scrum-Rollen vor: Die Stakeholder wurden bereits zu Anfang als Anforderungsquelle identifiziert. Dabei können Stakeholder aus der Fachabteilung einer Behörde kommen oder es ist ein Anwender des zu entwickelnden Produktes. Ein Product Owner definiert das gewünschte Produkt, vertritt die Interessen des Kunden und ist verantwortlich für das Product Backlog. Der Product Owner übernimmt auch die Priorisierung der Aufgaben im Backlog. Des Weiteren sorgt der Scrum Master dafür, dass das Team ungestört arbeiten kann, und achtet darauf, dass das Scrum Framework richtig eingesetzt wird. Das Entwicklerteam ist für die Erstellung und Lieferung eines Produktes verantwortlich – also für die eigentliche Programmierung und das Testing .

Darüber hinaus gibt es die Scrum Events: Im Sprint Planning werden die Aufgaben, die im Sprint durchgeführt werden sollen, aus dem Product Backlog entnommen und in das Sprint Backlog bewegt. Diese Aufgaben werden dann im Laufe des Sprints durch das Entwicklerteam umgesetzt. Im Sprint Planning wird nun ebenfalls die Dauer eines jeden Sprints festgelegt. Abschließend erfolgt ein Sprint Review: Hier präsentiert das Team den Stakeholdern das Ergebnis des letzten Sprints wie zum Beispiel neu entwickelte Funktionen der App. Die Sprint-Retroperspektive wird nach dem Review durchgeführt und dient dazu, die internen Abläufe zu verbessern. Als letztes Sprint Event wird ein Daily eingeführt. Hierbei trifft sich das Team täglich um die gleiche Uhrzeit, um in 15 Minuten die Vorarbeiten des vorherigen Tages und die geplanten Aufgaben für den folgenden Tag zu besprechen.

Die Abbildung zeigt die Vorgehensweise bei der App-Entwicklung (Scrum). Product Owner, Stakeholder, Scrum Master, Product Backlog, Sprint Artefact. Die Abbildung zeigt die Vorgehensweise bei der App-Entwicklung (Scrum). Die Abbildung zeigt die Vorgehensweise bei der App-Entwicklung (Scrum).


Kein Projekt ohne kontinuierliches Testen

Der nächste Schritt in einem Entwicklungsprojekt ist das Testing . Die Philosophie des fortlaufenden Testens ist in allen agilen Projekten fest verankert. Neben den Nutzertests, die beispielsweise anhand von A/B-Tests durchgeführt werden, setzt das Team auf Fehlervermeidung durch Inspektion auf Basis von Pull Requests, Code Reviews und statischer Code Analyse. Pull Requests fördern den Wissenstransfer im Team und die Weiterbildung der Entwickler. Pull Requests können daher auch als eine Kreuzqualitätssicherung betrachtet werden.

Funktionale Tests und Lasttests dürfen nicht fehlen, genauso wenig wie BITV-Tests (Barrierefreie-Informationstechnik-Verordnung) für Barrierefreiheit, die bei Bundesbehörden eine essenzielle Rolle spielen.

Bereit zur Auslieferung

Wurde eine neue Version der App erfolgreich getestet, erfolgen sowohl die Konzeption als auch die Durchführung der Auslieferung und des Betriebs. Dabei werden die Implementierung der Anwendung auf dem entsprechenden System oder gegebenenfalls ebenso das Hosting vorbereitet und durchgeführt, falls die App weitere Backend-Anwendungen benötigt. Im laufenden Betrieb muss der Kunde weiterhin betreut und beraten werden, oder aber die Anwendung wird weiterentwickelt. Ebenso wird der Konfigurationsstand mit zusätzlich notwendigen Komponenten wie Backend-Software abgeglichen und auf den gleichen Stand gebracht, damit die Systeme synchron sind.

Um die App in den Stores zu veröffentlichen, müssen die dafür notwendigen Ressourcen wie Texte, Screenshots, Grafiken und Videos erstellt werden. Eventuell werden auch eine Abstimmung und Koordination mit Apple oder Google notwendig. Anschließend können Anwender die neue App mit ihrem Smartphone herunterladen und nutzen.