More success in app distribution with time-based releases

"Kleine Releases ermöglichen schnellere Iterationen in der Entwicklung und beinhalten gleichzeitig weniger Regressionen und Fehler."

Der Rat erscheint zunächst kontraintuitiv. Schließlich ist die Bereitstellung und Distribution von qualitativ hochwertigen App-Updates mit Aufwand und Risiko verbunden. Braucht es daher wirklich mehr davon als unbedingt nötig? Sind die leichtgewichtigen Prinzipien agiler Prozesse überhaupt mit der Behäbigkeit eines Release Prozesses vereinbar?

Wir haben die Erfahrung gemacht, dass

• kleine Releases schnellere Iterationen in der Entwicklung ermöglichen und gleichzeitig weniger Regressionen und Fehler beinhalten.
• regelmäßige Releases für ein eingespieltes Team, welches sich einen pragmatischen, wohldefinierten Release Prozess und Automatisierung zunutze macht, in der Summe weniger Aufwand und Risiko erzeugen.

App Releases hängen von den Prozessen der Plattformen (Apple/ Google) ab

Hand aufs Herz: Wer bisher Erfahrung in der Entwicklung von Webanwendungen gesammelt hat, kann sich durch das releasebasierte Distributionsmodell von Apps eingeschüchtert fühlen. Vor allem die fehlende Kontrolle über die ausführende Plattform und ausgeführte Softwareversion können Kopfschmerzen bereiten.

Wer eine Webanwendung bereitstellt, hat typischerweise direkten Einfluss auf die Serverumgebung und kann umgehend neue Inkremente veröffentlichen oder im Fehlerfall zurückrollen. Desweiteren muss die Anwendung nur für eine kleine, tendenziell sogar schrumpfende Anzahl von verschiedenen Browsern entwickelt und getestet werden.

Im Vergleich ist ein App Release, sobald es den “sicheren Heimathafen” der Versionskontrolle verlassen hat, ultimativ auf sich selbst gestellt:

• Benutzer:innen installieren aktualisierte Versionen ggf. nur unregelmäßig und erwarten dennoch, zumindest mittelfristig, eine funktionale App.
• Apps - egal ob B2C- oder B2B-Apps laufen auf einer großen Anzahl von teilweise sehr unterschiedlichen Endgeräten welche sich u.U. anders verhalten als die Geräte welche zur Entwicklung eingesetzt werden. Gerade im Android Ökosystem ist die Varianz extrem hoch. Durch Eigenentwicklungen der Gerätehersteller, die mal mehr mal weniger in Systemprozesse eingreifen, wird diese Varianz noch verstärkt.

Zudem erfolgt die Freigabe zur Veröffentlichung von Updates in zeitlich und organisatorisch unabhängigen Prozessen durch die jeweiligen Plattformen von Apple und Google. Berechtigte sowie unberechtige Ablehnungen von Freigaben und variable Zeiträume zur Durchführung der Prüfung erschweren das schnelle Verteilen von Updates und Bugfixes.

Kurzum: Wer in diesem Umfeld konsistent qualitativ hochwertige Releases veröffentlichen möchte muss für jedes einzelne Release mit Aufwand für Qualitätssicherung und etwaige Nachbesserungen rechnen.

Best Practices für eine gute offline User Experience (UX). Jetzt lesen

Bedeuten seltenere Releases weniger Aufwand?

Der zu erwartende Aufwand für die Veröffentlichung eines möglichst fehlerfreien Releases kann ein Team schnell dazu verleiten den Release Prozess selten durchzuführen. Der Umfang und Zeitpunkt eines neuen Releases wird so basierend auf der Fertigstellung von größeren, zusammenhängenden Feature-Paketen mit Blick auf die Einhaltung von Deadlines definiert. Unserer Erfahrung nach führt dieses Vorgehen zu erheblichem Aufwand im Release Prozess und dennoch höherem Risiko für Probleme in der veröffentlichten Version:

"Große Releases enthalten mehr Potential für Bugs als kleinere."

Bugs lieben große Releases

Große Releases enthalten mehr Potential für Bugs als kleinere. Dem Umstand wird typischerweise durch intensive, lange Test- und Betaphasen und Nachbesserungszyklen begegnet. Dennoch ist davon auszugehen dass auch zum Zeitpunkt der Veröffentlichung mehr Probleme unentdeckt bleiben.

Zeitdruck erzeugt minderwertige Ergebnisse

Je seltener ein Release Prozess durchgeführt wird, desto mehr zeitlicher Druck lastet auf Entwickler:innen um ein Feature noch vor dem Start des Release Prozesses fertigzustellen oder eine Nachbesserung umgehend einzureichen. Auch auf Tester:innen kann zeitlicher Druck lasten. Unserer Erfahrung nach erzeugt zeitlicher Druck langfristig minderwertige und schwer wartbare Software.

Große Releases machen behäbig

Große Releases benötigen lange und aufwändige Release Prozesse und erzeugen Abhängigkeiten zwischen eigentlich unabhängigen Features. Das erschwert das kurzfristige Reagieren auf neu entdeckte Bugs und veränderte Anforderungen. Gleichzeitig werden mehr Management- und Entwicklungsressourcen gebunden, welche die Weiterentwicklung des Produktes beschleunigen könnten. Und: Wer einmal einen problematischen Release Prozess hinter sich gebracht hat scheut den nächsten.

Regelmäßige, kompakte Releases ermöglichen Agilität

Die unserer Erfahrung nach erfolgversprechendere Methode schreibt einen festen, zeitbasierten Rhythmus (bspw. alle 1-2 Wochen) für den Start von Release Prozessen vor. Statt auf die Fertigstellung eines immer höher werdenden Berges an Features und Bugfixes zu warten, beschränkt sich der Umfang eines Releases auf die Features und Bugfixes, welche zum Start des Prozesses fertig sind. Weil die Release Prozesse so "einem festen Fahrplan folgen" wird dieser Ansatz auch als "Release Trains" bezeichnet.

"Die unserer Erfahrung nach erfolgversprechendere Methode schreibt einen festen, zeitbasierten Rhythmus (bspw. alle 1-2 Wochen) für den Start von Release Prozessen vor."

Kompakte Releases haben eine höhere Qualität

Wenn regelmäßig Releases auf den Weg gebracht werden, ist der Umfang jedes einzelnen kompakter. Das senkt das Potential für Bugs und teure Nachbesserungs- und Qualitätssicherungszyklen. Die Gefahr von unentdeckten Problemen ist kleiner.

Regelmäßige Releases senken den Zeitdruck

Da das nächste Release nie lange auf sich warten lässt, lastet auf Entwickler:innen weniger Druck ein Feature unbedingt noch in ein bestimmtes Release zu zwingen. Das begünstigt die langfristige und nachhaltige Entwicklung von qualitativ hochwertiger Software und reduziert das Risiko von teuren Nachbesserungs-Zyklen und unentdeckten Fehlern.

Kompakte Releases machen beweglich

Das regelmäßige Veröffentlichen kompakter Software-Inkremente reduziert die benötigten Feedback-Zyklen und damit den Aufwand für jeden einzelnen Release Prozess. Ein agiles Team kann schnell auf geänderte Anforderungen oder Fehlermeldungen reagieren.

Eine Gleichung mit Unbekannten

Die Erkenntnis, dass ein kleines Release weniger Aufwand und Risiko verursacht als ein großes ist nicht wahnsinnig überraschend. Die interessante Frage, die sich stellt, ist: Wie verhalten sich Aufwand von wenigen großen Releases und vielen kleinen Releases? Ist die Summe der Aufwendungen für viele kleine Releases nicht im besten Fall äquivalent zum Aufwand für ein großes Release und typischerweise sogar größer?

"Der Aufwand für ein Release und das damit verbundene Risiko wachsen überproportial zum Umfang, da benötigte Qualitätssicherungsmechanismen und Feedback-Zyklen länger ausfallen und mehrfach ausgeführt werden müssen."

Unsere Erfahrungen, und die vieler anderer Teams die ähnliche Prozesse einsetzen, weisen eher auf das Gegenteil hin: Der Aufwand für ein Release und das damit verbundene Risiko wachsen überproportial zum Umfang, da benötigte Qualitätssicherungsmechanismen und Feedback-Zyklen länger ausfallen und mehrfach ausgeführt werden müssen. Das reduziert die Planbarkeit von Prozessen beträchtlich.
Wenn die Durchführung von Release Prozessen eher die Regel als die Ausnahme darstellt, kann ein eingespieltes Team, welches sich einen pragmatischen Prozess und die Automatisierung von Teilschritten zunutze macht, den Aufwand für jeden einzelnen Prozess kontinuierlich und deutlich reduzieren.

Agile Prozesse im Release Rhythmus

Der Wechsel des Prozesses ist nicht für jedes Team vorteilhaft. Sie ergeben vor allem dann Sinn, wenn von einem eingespielten Team im Produktentwicklungsprozess schnell iteriert wird. Aus unserer Erfahrung heraus knüpfen wir den zeitbasierten Release-Rhythmus an folgende Voraussetzungen:

• Das Produkt sollte kontinuierlich und agil entwickelt werden.
• Es bestehen Potentiale für Optimierung und Automatisierung von Teilschritten.
• Angeschlossene Dienste (etwa ein eigenes Backend) verfolgen ähnliche Prozessmodelle und Release Rhythmen.

Unter diesen Voraussetzungen erzeugt die Einführung eines eng getakteten Release Rhythmus und der damit einhergehende mentale Shift ein besseres Produkt, reduziert den Auffrewand für Releases und lässt die Vorteile von agilen Prozessen auch über die Einschränkungen von App Stores und ihren undurchsichtigen Prozessen hinweg wirken.