Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Fokus auf Wachstum – so funktioniert Software-Entwicklung in der mobilen Welt

(Foto: Shutterstock)

Beim Wort „Skalieren“ leuchten die Augen von Investoren und Unternehmern. Welche Rolle die Entwicklung mobiler Software dabei spielt, erläutern zwei Gastautoren.

Geschwindigkeit und Lernfortschritte entscheiden in Sachen Software-Entwicklung über den Erfolg eines rasch wachsenden Unternehmens. Völlig zu Recht sind beide Faktoren Kernelemente von „Running Lean“. Wenn ihr die folgenden drei Ratschläge beherzigt, entwickelt ihr mobile Software von Anfang an so, dass sie auch beim rasanten Wachstum nicht zur Stolperfalle wird.

2008 waren Apps erstmalig im App-Store verfügbar. Seitdem hat sich vieles positiv entwickelt, einige sinnvolle Dinge sind im Laufe der Zeit aber auch verloren gegangen: etwa kurze Release-Zyklen, servergesteuerte Funktionen oder A/B-Testing. Während diese Tools und Schritte bei Web-Produkten zum festen Repertoire gehören, fehlten sie während der ersten Welle der App-Entwicklung. Folge waren gesunkene Produktivität und negative User-Experience (UX). Jetzt feiert dieses von Web-Produkten bekannte Vorgehen ein vollauf verdientes Comeback im mobilen Bereich.

Unsere drei wichtigsten Ratschläge im Überblick:

Kernelement #1: Zweiwöchentliche Releases und wöchentliche Execution-Sprints

Für kleine Unternehmen mit bis zu zehn Mitarbeitern ist ein Release alle zwei Wochen ein guter Ausgangspunkt. Größere Teams sollten sich dagegen an eine Wochen-Taktung halten. So kommen sie schneller voran. Führt dabei mindestens einen Hypothesentest durch, um die Interessen eurer Nutzer besser zu verstehen. Tipp: Nutzt günstige Validierungstools für die wesentlichen Fragen, die ihr zu eurem Produkt oder Service habt. Sean McBride erläutert in diesem Post die Herangehensweise an solch eine Experiment-Priorisierung.

Donnerstag oder Freitag eignen sich für kurze wöchentliche Meetings, damit jeder am nächsten Montagmorgen weiß, was er in dieser Woche zu tun hat. Folgende Punkte stehen auf der Agenda:

  • Durchsicht der Backlogs mit dem Team (maximal 15 Minuten).
  • Wesentliche Erkenntnisse der vergangenen Wochen: Müsst ihr etwas ändern?
  • Aufgaben für euer Team in der kommenden Woche: Jede Aufgabe wird von einem Entwickler übernommen.

Normalerweise ist auch eine Demo fester Bestandteil des Meetings. Die Entwickler präsentieren die Ergebnisse ihrer Arbeit beziehungsweise ihre bisherigen Fortschritte. Das hilft ihnen, fokussiert und eigenverantwortlich zu arbeiten.

Funktioniert dieser Prozess, weiß jedes Teammitglied am Montagmorgen exakt, was er bis Ende der Woche zu tun hat. Das Feedback zu diesem Modell ist äußerst positiv: Teammitglieder sind zufriedener, gerade weil für jeden Einzelnen klar ist, welche Aufgaben er zu erledigen hat. Außerdem sorgt dieses Modell für Transparenz: Jeder weiß, aus welchem Grund welche Aufgabe Priorität hat und welche Ziele er und das Team erreichen sollen.

Typische Struktur:

Üblicherweise testet ihr bei wöchentlichen Releases die App im Laufe der Woche zuerst intern.

Die Vorteile dieses Modells im Überblick:

  • Schneller Fortschritt: Längere Zeiträume zwischen Releases stehen im Konflikt zu Parkinsons Gesetz und führen eher zu Leerlauf als zu effizienter Arbeit.
  • Höhere Produktqualität: Ursachen für Probleme und Bugs lassen sich bei einer neuen Version alle zwei Wochen beziehungsweise jede Woche einfacher identifizieren.
  • Individueller Fokus: Wöchentliche Meetings fördern Fokus, Verantwortung und Zufriedenheit.
  • Steile Lernkurve: Mindestens ein sinnvolles Experiment pro Woche verbessert euer Produkt oder eure Dienstleistung (siehe auch Punkt #3).

Kernelement #2: Kontrolle über Mobile-Client-Features dank Server-Steuerung

Ein sehr wichtiger Aspekt bei der nativen App-Entwicklung ist die Kontrolle von Client-Traits durch den Server. Entwickler konfigurieren ihre Anwendungen so, dass sie Flags vom Server ablesen, ihre UI/UX entsprechend anpassen und nur entsprechende Features anzeigen. Dieses Verfahren hat sich in den vergangenen Jahren als Standard etabliert und viele Dienstleister auf den Plan gerufen. Einige größere Software-Unternehmen entwickeln Systeme, die von Anfang an Kontrolle von Client-Features durch den Server ermöglichen. Dazu zählen beispielsweise Gatekeeper (GK) und Quick Experiments (QE) von Facebook. Ähnliche Systeme haben unter anderem auch Uber, Pinterest und Zenefits entwickelt. Beispiele bereits zugänglicher Tools sind Optimizely, Mixpanel, Apptimize und Firebase.

Gründe, weshalb vom Server kontrollierte Client-Traits zum Standard in der App-Entwicklung werden:

  • Bessere User-Experience: Gerade bei iOS dauert es eine Weile, bevor eine eingestellte App veröffentlicht ist und Bugs oder Client-Abstürze durch einen Hotfix behoben sind. Ganz anders sieht es aus, wenn man Client Traits vom Server aus kontrolliert. Ein Beispiel: Ein neues Feature führt zu einem Crash auf Nexus-6-Geräten. Dieses Feature kann auf dem Server umgehend gezielt für alle Nutzer des Geräts abgestellt werden – die Anwendung stürzt nun nicht mehr ab. Auf allen anderen Geräten läuft das neue Feature wie gehabt.
  • Mehr Installationen: Stürzt eine App am Tag der Veröffentlichung ab, drohen negative Bewertungen im Google-Play-Store oder Apple-App-Store. Das wiederum beeinträchtigt in der Folge die Conversion Rate von Besuchern der App-Seite zu App-Installationen (ich installiere mit höherer Wahrscheinlichkeit eine App mit 4,5 als eine mit 3,5 Sternen). Noch ärgerlicher sind unzufriedene Kunden, die euch ein für alle Mal verloren gehen oder negative Pressemeldungen, die euch im schlimmsten Fall eure Marke ruinieren.
  • Weniger monolithische/fließendere Entwicklung: Das Wissen, dass sich ein noch nicht gänzlich entwickeltes Feature durch entsprechende Server-Konfiguration wieder abstellen lässt, verringert den Aufwand für Entwickler.

„Feature Flagging“ ist ein Vorgang, bei dem eine App durch eine API ein Set von „Flags“ abruft. Diese Flags informieren die Anwendung, welche Route sie im Code einschlagen soll.

Ein Beispiel:

  • Du hast ein Mobile-Client-Feature für Zahlungen entwickelt.
  • Du hast ein entsprechendes serverseitiges Flag unter dem Namen „payments_v1“ kreiert. Die Boolesche Variable nimmt entweder den Wert „richtig“ oder „falsch“ an.
  • Während der ersten Client-Session wird dieser Wert abgerufen. Stimmt der Wert, zeigt der Client dieses Feature an – ist er falsch, zeigt er ihn nicht an.

Üblicherweise stellt man den Namen der Plattform, im Normalfall also „ios_“ oder „android_“, voran. So könnt ihr ein Flag nur für die Plattform abstellen, die von einer Störung beeinträchtigt wird. Das Datum, das angibt, wann das Flag kreiert wurde (zum Beispiel „_aug_2017“), stellt man nach. Die erste Version des Zahlungs-Features, das auf iOS veröffentlicht wurde, wird also mit dem Flag „ios_payments_v1_aug_2017“ versehen. So behält das Team die Übersicht darüber, wann es welches Feature veröffentlicht hat.

Kernelement #3: Erweiterte Serverkontrolle über mobile Features für bessere Lernerfolge bei A/B-Tests

Kontroll-Features sind ein binärer Weg (richtig==zeigen, falsch==verbergen), um Features gezielt für User aus- oder einzuschalten. Allerdings sollen häufig verschiedene Varianten der Features ausprobiert werden. Abhängig davon, wie User die verschiedenen Features bedienen, sind ihre Präferenzen dann besser einzuschätzen.

Dafür werden A/B-Tests auf mobilen Endgeräten durchgeführt. Das Konzept ist das gleiche wie sonst auch: In einem Experiment werden verschiedene Varianten getestet, um das beste Resultat herauszufinden. Zusätzlich zu Feature-Flags gibt der Server auch Namen der Varianten an, die angezeigt werden. Abhängig davon erscheint die jeweilige Variante in der App des Users.

Dieser Prozess erlaubt uns:

  • Die beste Variante zu finden: Ihr testet zuvor verschiedene Optionen.
  • Langsames Ausrollen eines schwierigen Features (zunächst für eine Testgruppe): Manchmal werden Features gelauncht, die bereits existierende Funktionen unerwartet zum Zusammensturz bringen können. Das kann beispielsweise ein neues Back-End oder eine neue, kaum getestete Funktion sein. Indem etwas nur für einen kleinen Prozentsatz der Nutzer zugänglich ist, können negative Erfahrungen minimiert werden. Tipp: Nutzt loyale User als Testgruppe. Oft genießen treue Produktfans ihren exklusiven Status.
  • Eine bessere User-Experience zu schaffen: Wenn ihr messt, wie Nutzer die App verwenden und in ihr navigieren, erkennt ihr schneller typische Navigationswege und Interaktionen. So könnt ihr eure App dem Verhalten und den Vorlieben eurer Nutzer anpassen.

Ein Beispiel anhand des obigen Zahlungsfeatures:

  • Ein A/B-Test soll feststellen, ob die Farbe der Zahlungs-Taste einen Einfluss auf die Verkaufszahlen hat.
  • Zusätzlich zu dem „payments_v1“-Flag sendet der Server den “payments_v1_button_color”-Key – beispielsweise mit den Varianten „blue“, „green“, „red“.
  • Nun muss das Verhalten von ausreichend Anwendern der App getrackt werden, damit die Ergebnisse statistisch signifikant sind.
  • Angenommen, der grüne Button erzielt die besten Ergebnisse.
  • Beim nächsten Release wird der Client-Code so geändert, dass der grüne Button immer angezeigt wird.
  • Der Server-Code wird aufgeräumt, sodass der Server immer „payments_v1_button_color“ als „green“ auch für ältere Clients zurücksendet.
  • Der Code wird nochmals aufgeräumt, wenn der Prozentsatz der Nutzer auf alten Clients gering ist.
  • Der „payments_v1_button_color“-Key wird endgültig gelöscht.
  • Wird der Key nicht vom Server verschickt, zeigt ihr eine Default-Meldung an.

Fazit

App-Entwicklung kann und sollte fast so flexibel, sicher und wissensbasiert sein wie die Webentwicklung. Es ist davon auszugehen, dass im nächsten Jahrzehnt sogar die kontinuierliche Weiterentwicklung mobiler Apps gang und gäbe ist.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen

Finde einen Job, den du liebst