In der Peak Season, was den Traffic angeht, wird häufig das Thema „Code Freeze“ angesprochen, um den außergewöhnlich hohen Traffic in dieser Zeit zu bewältigen.

Code Freezes mögen heutzutage wie ein veraltetes Konzept erscheinen, ein Überbleibsel aus der Zeit, als starre Wasserfallmodelle die einzige Option für die Produktentwicklung und Releases waren.

Das ganze Konzept, die Produktion zu stoppen und Releases zu verzögern, nur um Bugs und andere funktionale Probleme zu testen, hat keinen Platz mehr im modernen agilen Produktmanagement und in DevOps-Praktiken, bei denen der Code in jeder Phase des Entwicklungsprozesses getestet und überprüft wird.

Zumindest scheint dies der allgemeine Konsens in vielen technischen Teams zu sein.

Aber ist das wirklich so? Wenn man erstmal an der Oberfläche der häufigsten Argumente gegen die Integration von Code Freezes in das agile Produktmanagement kratzt, erscheinen sie dann immer noch veraltet?

In diesem Artikel gehen wir auf die drei Hauptargumente ein, die gegen die Integration von Code Freezes in dein agiles Produktmanagement sprechen, und wir zeigen auf, wo diese Argumente nicht zutreffen, um dir zu helfen, eine bessere Entscheidung zu treffen, ob du Code Freezes in die Arbeitsabläufe deines Unternehmens integrieren solltest oder nicht.

Was ist ein Code Freeze?

Beginnen wir zunächst damit, was ein Code Freeze eigentlich ist, um zu verstehen, ob es in der modernen Softwareentwicklung noch einen Platz hat.

Ein Code Freeze ist eine traditionelle Praxis unter Entwicklern, die Änderungen oder die Veröffentlichung neuen Codes zu stoppen, um die Stabilität der Website oder App während eines bestimmten Zeitraums zu gewährleisten. Ein Code Freeze wird in der Regel in Zeiten implementiert, in denen ein höherer Traffic als normal erwartet wird, insbesondere bei E-Commerce-Websites in der Peak Season.

Was bedeutet das? In traffic-starken Zeiten im E-Commerce unterlässt du vorübergehend sämtliche Änderungen an der Website. Jegliche Änderungen mit Auswirkung auf die User Experience während der Peak Season können letztlich zu einem Verlust an Conversions und Gewinn führen.

Mit anderen Worten: Ein Code Freeze wird durchgeführt, um sich vor möglichen Fehlern zu schützen, die durch die zusätzliche Belastung der Website entstehen.

Betrachten wir ein praktisches Beispiel: Die Entwickler beschließen, eine neue Code-Änderung während des „Black Friday“ einzuführen, an dem der Traffic besonders hoch ist, da die Kunden auf der Suche nach den besten Angeboten sind. Es stellt sich jedoch heraus, dass es einen Fehler gibt, mit dem sie nicht gerechnet hatten. Während die Entwickler versuchen, das Problem zu beheben, kommt es zu Ausfallzeiten auf der Website, was zu Umsatzeinbußen führen kann, da die Kunden ihre Einkäufe nicht abschließen können.

Um dieses Worst-Case-Szenario zu vermeiden, verhängen die Entwickler stattdessen eine Code-Freeze-Zeit, in der keine weiteren Code-Änderungen vorgenommen werden. Auf diese Weise wird sichergestellt, dass eine Website bis zum Ende der Zeit mit hohem Traffic-Aufkommen ohne Probleme funktioniert.

Was beinhaltet eine agile Methodik?

Im Folgenden werden wir die Idee hinter dem agilen Konzept erörtern, um besser beurteilen zu können, ob es mit Code Freezes vereinbar ist, bevor wir die häufigsten Argumente gegen diese Methode untersuchen.

Die agile Methodik zielt darauf ab, Projekte in regelmäßig wiederkehrende Zyklen, sogenannte Sprints, aufzuteilen, und wird weitgehend durch das Feedback der Kunden bestimmt. Dies hilft den Teams, den Verbrauchern schnell einen größeren Wert zu liefern.

Mit anderen Worten: Diese Methodik fördert die kontinuierliche Iteration und Verbesserung von Produkten und Tests während des gesamten Software Development Life Cycles.

Durch die Aufteilung der Entwicklung in Sprints wird die Zykluszeit verkürzt, was die Markteinführung beschleunigt und es den Teams ermöglicht, schneller auf Marktanforderungen zu reagieren.

Vor diesem Hintergrund kann ein Code Freeze die Fähigkeit von Teams, schnell einen Mehrwert zu liefern, potenziell einschränken, da sie eine Freeze-Phase festlegen.

Als Nächstes werden wir uns einige der gängigen Argumente gegen Code Freezes im Kontext einer agilen Methodik ansehen.

Argument 1: Code Freezes sind irrelevant und unnötig

Dieses Argument ist ziemlich simpel und konkret – aufgrund moderner Agile Methodiken und Tools sind spezielle QAs und Testzeitfenster nicht mehr notwendig.

Agile Methoden wie Peer Code Reviews, Pair Programming und die ständige Überwachung des Systemzustands geben dir einen viel besseren Einblick in die Leistung einer Anwendung oder eines Features, während diese entwickelt werden. Fehler und Probleme lassen sich leichter und mit größerer Wahrscheinlichkeit bereits während der Entwicklung erkennen und beheben, bevor spezielle Tests und QA-Aktivitäten durchgeführt werden.

Je ausgefeilter dein agiler Ansatz ist, desto mehr wirst du versuchen, dieses Zeitfenster zu verkleinern. Die derzeit raffiniertesten Agile-Ansätze sind Continuous Integration und Continuous Deployment (CI/CD).

Diese Prozesse zielen darauf ab, die Entwicklung in kleine, inkrementelle Änderungen aufzuteilen, um Änderungen am Code so schnell wie möglich „freizugeben“. Bei der reinsten Anwendung von CI/CD existieren Entwicklung und Release kaum noch als getrennte Phasen – neuer Code wird fast unmittelbar nach seiner Fertigstellung in die Anwendung integriert.

Neue Tools haben auch viele Tests automatisiert. Sie evaluieren permanent den Code, um sicherzustellen, dass er fehlerfrei und jederzeit produktionsfähig ist. Probleme werden in Echtzeit erkannt, und es werden sofort Warnmeldungen zu ihrer Behebung verschickt, so dass weniger manuelle Tests durchgeführt werden müssen.

Das Ergebnis dieser neuen agilen Methoden und Tools liegt klar auf der Hand. Die meisten der wichtigsten Test- und QA-Aktivitäten, die während eines Code Freeze durchgeführt werden, werden entweder während der Entwicklung oder von einer Software durchgeführt.

Bei Agile verlassen Software und Funktionen die Entwicklung jetzt mit einem deutlich höheren Maß an Vertrauen als zuvor, wodurch ein dedizierter Code Freeze immer schwerer zu rechtfertigen ist.

Argument 2: Code-Freezes brechen ein zentrales agiles Prinzip

Das zweite Argument ist ein wenig übergeordneter Natur. Es besagt, dass Code Freezes in der agilen Methodik nichts zu suchen haben, weil sie gegen eines der Grundprinzipien dieser Methodik verstoßen – die Verkürzung der Zeit zwischen Entwicklung und Release.

Im Gegensatz dazu musst du getrennte Entwicklungs- und Release-Phasen beibehalten, wenn du Code Freezes einsetzen willst. Schließlich befindet sich der Code Freeze genau zwischen diesen beiden Phasen.

Anstatt zu versuchen, das Zeitfenster zwischen Entwicklung und Release zu minimieren oder zu eliminieren, wie es bei den meisten agilen Methoden der Fall ist, zwingen Code Freezes dich dazu, dieses Zeitfenster so zu formalisieren, dass du deine Zeitpläne für Entwicklung und Release „drum herum“ erstellen musst.

Wenn Code Freezes nicht mit den Grundprinzipien der agilen Methodik übereinstimmen, dann ist es schwer zu argumentieren, sich methodisch weiter an sie zu halten.

Argument 3: Code Freezes führen zu langsameren Releases minderer Qualität

Dieses letzte Argument ist wichtig und sollte unter verschiedenen Blickwinkeln betrachtet werden.

Erstens wird behauptet, dass Code Freezes die Roadmap komplexer machen und die Wahrscheinlichkeit erhöhen, dass etwas schief geht und der Zeitplan durcheinander gerät.

Selbst wenn nichts schief geht, ist die Arbeit, die mit Code Freezes verbunden ist, zeitintensiv und unvorhersehbar (da man nicht weiß, welche Bugs man finden wird und wie lange es dauern wird, sie zu beheben), so dass die bloße Aufnahme von Code Freezes in die Roadmap zu langsameren Entwicklungs- und Release-Zyklen führt.

Einerseits werden die Entwickler während eines Code Freeze weiterhin Code entwickeln, ohne ihn jedoch zu integrieren oder zu testen, während sie darauf warten, dass der Freeze vorbei ist. Dies führt zu einer Anhäufung von Code und damit zu größeren Risiken und Instabilitäten, was die Dynamik deiner CI/CD-Prozesse erheblich verlangsamen könnte. 

Andererseits möchten die Entwickler vielleicht neue Code-Änderungen herausbringen, bevor der Code Freeze beginnt. Dies kann zu unvollständigem oder schlecht geschriebenem Code führen, der aus Zeitgründen nicht den üblichen gründlichen Tests unterzogen wird, da sie sich beeilen, ihre Projekte vor dem Code Freeze abzuschließen. Das Ergebnis ist eine minderwertige, weniger umfangreiche Software und Anwendung.

Außerdem können Code Freezes die Produktivität deines Entwicklungsteams reduzieren. Während agile Methodiken im Allgemeinen und CI/CD im Besonderen dafür sorgen, dass die Entwickler permanent in einer ungebrochenen Produktionskette arbeiten, zwingen Code Freezes deine Entwickler dazu, die Arbeit in vordefinierten Abständen zu unterbrechen.

Mit anderen Worten: Es könnte deine CI/CD-Pipeline unterbrechen.

Dadurch unterbrichst du den Arbeitsrhythmus deines Teams und zwingst es, deine Code-Freeze-Richtlinien zu umgehen, anstatt den Arbeitsfluss zu suchen und aufrechtzuerhalten, der die größte Produktivität verspricht.

Sich für Code Freezes einsetzen: Ein aussichtsloser Kampf?

An dieser Stelle sieht es für jeden düster aus, der Code Freezes immer noch in die agile Methodik integrieren möchte. Es gibt einige sehr überzeugende Argumente und ein insgesamt solides Argument dafür, dass Code Freezes seit der Entwicklung der modernen agilen Methodik zu etwas anderem geworden sind:

1. Obsolet und irrelevant
2. Nicht mit modernen Entwicklungspraktiken übereinstimmend
3. Ein Hindernis für schnelle, qualitativ hochwertige Releases

Diese Argumente sind zwar überzeugend und enthalten viele zutreffende Informationen, aber sie sind nicht unerschütterlich. Und jedes dieser Argumente weist grundlegende Mängel auf, die diskutiert werden müssen, ehe das Kapitel über Code Freezes als nützliche Komponente des agilen Produktmanagements geschlossen werden kann.

Das Problem mit Argument 1: Automatisierte Tests sind nicht umfassend

Automatisierte QA und agile Entwicklungspraktiken haben die Qualität des Quellcodes verbessert, das ist eine Tatsache. Doch nur weil ein Stück Code die Unit-Tests bestanden hat, heißt das noch lange nicht, dass es tatsächlich produktionsreif ist.

Selbst die ausgefeiltesten CI/CD-Ansätze umfassen nicht immer entscheidende Schritte wie Regressionstests, die sicherstellen, dass ein Code-Teil fehlerfrei ist. Letzten Endes gibt es einfach einige Dinge, die man nicht testen und beheben kann, während ein Code-Teil in Produktion ist.

Wenn du dich für die Verwendung von Code Freezes entscheidest, musst du nicht auf die Vorteile der automatisierten QA und der bewährten agilen Verfahren verzichten.

Du und dein Team werden während der Produktion einfach die kleineren, trivialeren Probleme des Codes erkennen, um die Lage zu sondieren und sich auf größere Probleme mit größeren Auswirkungen während des Freeze zu konzentrieren wie zum Beispiel die Gesamtstabilität und -zuverlässigkeit der neuen Software oder Funktion.

Das Problem mit Argument 2: „Reduzieren“, nicht „eliminieren“

Agile ist zwar darauf ausgelegt, die Zeit zwischen Entwicklung und Release zu verkürzen, aber es besteht ein großer Unterschied zwischen dem Versuch, dieses Zeitfenster zu verkürzen, und dem Versuch, es vollständig zu eliminieren. Dies wäre vor allem bei größeren Projekten nahezu unmöglich.

Der Code Freeze kann bei CI/CD sehr kurz sein – oder nur für eine bestimmte Branche gelten, während die Entwicklung in anderen Branchen fortgeführt wird -, aber es existiert trotzdem.

Unabhängig davon, wie ausgefeilt Agile geworden ist, wird es fast immer einen Punkt in allen Roadmaps für Entwicklung und Releases geben, an dem ein neues Softwareteil oder ein neues Feature in einem festen Zustand evaluiert wird, bevor es an die User in der realen Welt geht.

Das Problem mit Argument 3: Geschwindigkeit und Qualität überdenken

Wenn du Code Freezes verwendest, wird die Entwicklung und dein Release-Zyklus um einen neuen Schritt erweitert, und jedes Mal, wenn du einem Prozess einen neuen Schritt hinzufügst, verlangsamst du diesen Prozess und schaffst eine neue potenzielle Schwachstelle. Code Freezes sind da keine Ausnahme.

Aber es ist wichtig, einen Schritt zurückzutreten und diese „Verlangsamung“ und den Produktivitätsverlust aus einem breiteren Blickwinkel zu betrachten.

Wenn deine Funktion Fehler aufweist, musst du diese beheben, unabhängig davon, ob du diese Fehler während eines Code Freeze entdeckt hast oder ob sie erst nach dem Release bekannt wurden. Aus der reinen Entwicklungsperspektive betrachtet, ist der Zeitaufwand für die Fehlerbehebung in beiden Szenarien in etwa gleich.

Wenn du jedoch mit Fehlern in einer Live-Umgebung zu tun hast, musst du dich für eine ganze Reihe anderer Probleme Zeit nehmen, darunter:

• Die Entscheidung, ob du die fehlerhafte Funktion zurücknimmst oder sie in Betrieb lassen sollst.
• Deine Entwickler von ihren neuen Projekten abziehen, nachdem sie mit der Arbeit begonnen haben.
• Die Wiedergutmachung gegenüber den Nutzern, die von den Fehlern betroffen waren.
• Die Beantwortung von Fragen und der Umgang mit internen Stakeholdern, die über die fehlerhafte Version nicht sehr glücklich sind.

Die Liste ließe sich weiter fortsetzen. Es gibt nichts Komplizierteres, Zeitaufwändigeres und Produktivitätsschädigenderes – für dich und dein Team – als die Veröffentlichung eines fehlerhaften Features oder Produkts. Code Freezes minimieren die Wahrscheinlichkeit, dass dies geschieht.

Und was das Argument angeht, dass Code Freezes zu qualitativ minderwertigen Funktionen und Produkten führen, weil sie die Menge der Geschäftsanforderungen reduzieren, die du sammeln kannst?

Deine geschäftlichen Anforderungen werden immer nur eine „beste Spekulation“ darüber sein, wie dein Produkt oder dein Feature funktionieren sollte. Die wertvollsten Ansprüche werden immer von Usern in der realen Welt gestellt, wenn dein Produkt oder dein Feature in echten Szenarien eingesetzt wird.

Wie Feature Flags Code Freezes ersetzen können

Wie wir bereits erwähnt haben, wird ein Code Freeze als Präventivmaßnahme gegen riskante und/oder fehlerhafte neue Code-Änderungen in sensiblen Phasen durchgeführt. 

Ein Code Freeze könnte jedoch das Risiko sogar erhöhen. Da die Entwickler weiterhin an neuen Änderungen arbeiten, die während des Code-Freeze-Zeitraums nicht freigegeben werden, bedeutet dies, dass sich in der nächsten Version eine Reihe von Commits ansammeln wird, was diese Version unglaublich riskant macht. 

Wenn irgendwelche Probleme auftauchen, wird es viel schwieriger sein, die Quelle des Problems zu lokalisieren, was bedeutet, dass mehr Zeit damit verschwendet wird, es zu finden und zu beheben.

An dieser Stelle kommen Feature Flags ins Spiel. Durch die Verwendung von Feature Flags sind die Entwickler nicht mehr auf Code Freezes während Zeiten mit hohem Traffic angewiesen, um das Risiko von Code-Änderungen zu verringern. 

Durch die Entkopplung von Bereitstellung und Release ermöglichen es Feature Flags den Entwicklern, eine neue Funktion oder eine Code-Änderung in die Produktion zu überführen und sie für die Benutzer unsichtbar zu machen, um sie dann nach und nach für bestimmte Benutzergruppen freizugeben – zum Beispiel intern in deinem Unternehmen.

Auf diese Weise können Teams kontinuierlich neuen Code bereitstellen und an neuen Funktionen arbeiten, ohne dass die Kunden davon etwas mitbekommen, da sie hinter diesen Flags versteckt sind und jederzeit ein- oder ausgeschaltet werden können. Teams können eine fehlerhafte Änderung auch jederzeit mit einem Kill Switch ausschalten oder zurücknehmen, so dass die Benutzer während der Korrektur keinen Zugriff mehr darauf haben.

Zusammenfassend lässt sich sagen, dass Feature Flags den Teams mehr Kontrolle über den Release-Prozess geben und dazu beitragen, das Risiko der Bereitstellung in der Produktion zu verringern, insbesondere in besonders sensiblen Zeiten mit hohem Traffic, ohne die Benutzererfahrung negativ zu beeinflussen. 

Ist es an der Zeit, den Code Freeze abzuschaffen?

Letztendlich spielen Code Freezes immer noch eine wichtige Rolle, um Ausfallzeiten oder unerwartete Fehler in besonders geschäftigen Zeiten zu vermeiden.

Da jede E-Commerce-Website anders ist, musst du entscheiden, ob ein Code Freeze die richtige Wahl für deine Website ist. Wenn du dich für einen Code Freeze entscheidest, solltest du gemeinsam mit deinem Entwicklungsteam im Voraus einen detaillierten Plan aufstellen. 

So kannst du feststellen, welcher Code „eingefroren“ werden muss, welcher optimiert werden muss und welche Projekte auf Eis gelegt werden sollten, um „unsaubere“ Releases zu vermeiden, bevor du mit dem Freeze beginnst.

Es gibt Fälle, in denen sie eine weniger kritische Rolle spielen. Bei sehr kleinen Projekten sind beispielsweise keine speziellen Code-Freeze-Zeiten erforderlich.

Bei neuen Features, die relativ geringe Auswirkungen haben, lohnt sich vermutlich kein Freeze. Dasselbe gilt für Release-Pläne, die schrittweise erfolgen, wenn du neue Features nur mit einer warmen Zielgruppe testen willst, die du darauf vorbereitet hast, ein fehlerhaftes, nicht perfektes Szenario zu erwarten; in diesem Fall sind Feature Flags ein effizienter Weg, diese Funktionen schrittweise einzuführen.

Aber in den meisten Fällen lohnt sich der Zeitaufwand – auch wenn er noch so klein ist – um sicherzustellen, dass deine neuen Funktionen so perfekt sind, wie du es dir vorstellst, bevor du sie in die Hände der Menschen gibst, die am wichtigsten sind: Deine User in der realen Welt.

An dieser Stelle werden Feature Flags zu deinen größten Verbündeten, da sie es dir ermöglichen, ein optimales Kundenerlebnis zu bieten, ohne deine Implementierungen unterbrechen zu müssen.

Denke jedoch daran, dass Feature Flags ein großartiges Hilfsmittel sind, welches das ganze Jahr über und nicht nur in Zeiten hohen Traffics eingesetzt werden sollte, um das Risiko zu minimieren und die Qualität zu maximieren.

Im digitalen Zeitalter können sich Unternehmen nicht mehr nur auf die Optimierung für den Desktop konzentrieren, zumal immer mehr Verbraucher ihre mobilen Geräte nutzen, um Websites zu besuchen und Einkäufe über Apps zu tätigen.

Da es jedoch Millionen von Apps gibt, sind der Wettbewerb und die Ansprüche und Erwartungen der Verbraucher so hoch wie nie zuvor. Das bedeutet, dass deine App in einem überfüllten Markt herausstechen muss.

Es ist wichtig, darauf hinzuweisen, dass die Entwicklung mobiler Apps nicht demselben Prozess folgt wie die einer Website App.

In diesem Artikel gehen wir auf die Herausforderungen beim Mobile App Deployment – also der Bereitstellung und Veröffentlichung von mobilen Apps – ein und erläutern, wie du mithilfe von Feature Flags optimierte Mobile Apps erstellen kannst, die den Bedürfnissen deiner Kunden entsprechen.

 

Diese Inhalte erwarten dich in diesem Blogartikel:

Die Herausforderungen beim Mobile App Deployment

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Mobile Feature Flags: Use Cases
Use Case 1: Decathlon
Use Case 2: EDF
Use Case 3: Ornikar

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

 

Die Herausforderungen beim Mobile App Deployment

Mobile Entwicklungsteams sind besonders anfällig für Bugs und lange, langwierige Veröffentlichungszyklen.

Kurz gesagt gibt es zwei Hauptprobleme, wenn es um die Freigabe oder Aktualisierung von Funktionen für mobile Anwendungen geht:

1. Du musst warten, bis die App-Stores die Freigabe erteilen (was einige Zeit dauern und die Veröffentlichung erheblich verzögern kann).
2. Danach musst du warten, bis die Nutzer die Aktualisierung manuell aus dem Store herunterladen (was ebenfalls viel Zeit in Anspruch nehmen kann).

Betrachten wir zum Beispiel folgendes Szenario: Du arbeitest an einem Update für deine mobile App. Du gibst es schließlich frei, um dann festzustellen, dass du einen Fehler übersehen hast, der zum Absturz deiner App führt.

In der Zeit, in der du ein neues Update mit einer Fehlerbehebung veröffentlichst, auf die Veröffentlichung im App Store wartest und darauf wartest, dass die Benutzer das Update herunterladen, riskierst du den Verlust einer beträchtlichen Anzahl von Benutzern.

Entwickler und Techniker von Mobilgeräten sind mit einem solchen Szenario nur allzu vertraut. 

Daher kann es ein mühsamer und langwieriger Prozess sein, bis eine Version genehmigt wird. Nach der Genehmigung muss jede fehlerhafte Version korrigiert werden und den App-Store-Genehmigungsprozess von neuem durchlaufen, was zu weiteren Verzögerungen führt. 

Obwohl sich die Überprüfungszeit in den letzten Jahren verbessert hat, kann es zu weiteren Verzögerungen kommen, wenn deine App nicht den Prüfungsrichtlinien des App Stores entspricht. Dies bedeutet, dass du keine Echtzeit-Updates für die Produktion bereitstellen kannst, wie dies bei Web Apps der Fall ist.

Vereinfacht gesagt, ist der Prozess des Mobile App Deployments nicht so einfach wie die Bereitstellung von Web Apps. 

Im Gegensatz zu Web Apps, die automatisch aktualisiert werden, sobald Besucher auf die Website zugreifen, müssen Benutzer eine Aktualisierung der mobilen App in ihrem Store herunterladen, um die neueste Version zu erhalten.  Da sich die Updates nach dem Überprüfungsprozess stapeln, hast du keine Kontrolle darüber, ob die Nutzer die neuesten Versionen herunterladen. 

Daher kann die Bereitstellung von Updates für mobile Apps im Vergleich zu Web Apps mehr Zeit in Anspruch nehmen. Und in einer Zeit, in der die Kunden immer das Beste verlangen, ist es nicht machbar, sie so lange auf ein Update warten zu lassen, vor allem, wenn es sich um einen Fehler handelt, ganz zu schweigen von der Bereitstellung einer neuen App-Version, sobald der Fehler behoben ist.  

In der modernen Softwareentwicklung, in der eine kontinuierliche Bereitstellung unerlässlich ist, um wettbewerbsfähig zu bleiben und die sich schnell ändernden Anforderungen der Kunden zu erfüllen, müssen die Teams auf eine andere Lösung zurückgreifen, um eine höhere Veröffentlichungsfrequenz zu erreichen.

---

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

---

 

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

An dieser Stelle kommen Feature Flags ins Spiel.

Im Gegensatz zu clientseitigen Tests, bei denen sich die Experimente auf Webbrowser konzentrieren, geben Feature Flags den Teams die Möglichkeit, serverseitige Experimente über mehrere Kanäle, einschließlich mobiler Apps, durchzuführen.

Feature Flags ermöglichen es Teams, Funktionen für Benutzer ihrer Wahl zu aktivieren oder zu deaktivieren, um Risiken und negative Auswirkungen zu minimieren.

Das bedeutet, dass du Funktionen aus der Ferne ein- oder ausschalten kannst, ohne den Code erneut in den App-Stores bereitzustellen und auf die Genehmigung zu warten oder darauf warten zu müssen, dass alle Änderungen zur gleichen Zeit fertig sind, um deine eigenen Änderungen zu veröffentlichen. Auf diese Weise kannst du Code bereitstellen, wann immer du willst.

Lies mehr dazu: Was ist Remote-Konfiguration in der App-Entwicklung?

Auf diese Weise kannst du deine App auf der Grundlage des Feedbacks deiner Nutzer kontinuierlich und in Echtzeit aktualisieren, ohne ein Update an den App Store zu senden oder auf dessen Genehmigung zu warten. Außerdem kannst du nach und nach neue Funktionen freigeben, ohne dass die Nutzer ständig ihre App-Version aktualisieren müssen.

Mit Feature Flags können Mobile-Entwickler in der Produktion sicher mit einer vordefinierten Zielgruppe testen und Funktionen mit einem Kill Switch deaktivieren, falls Probleme auftauchen. Die Entwickler können dann daran arbeiten, das Problem zu lokalisieren und zu beheben, bevor sie die Funktion für alle Benutzer freigeben.

 

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Feature Flags können nicht nur von Entwicklern, sondern auch von Produkt- und Release-Managern verwendet werden, um das mobile Erlebnis auf verschiedene Weise zu optimieren.

Hier sind einige Beispiele für den Einsatz von Feature Flags in mobilen Anwendungen:

• A/B-Testing: Mit Feature Flags kannst du deine Nutzer in Untergruppen aufteilen, wobei jede Gruppe von Nutzern eine andere Variante der Funktion erhält. Auf diese Weise kannst du testen und feststellen, welche Variante am besten abschneidet und an alle Benutzer verteilt werden sollte. Einfach ausgedrückt: A/B-Tests ermöglichen dir, wertvolles Live Feedback von deinen Nutzern zu sammeln, so dass du fundierte Entscheidungen über die Optimierung deiner Funktionen und Produkte treffen kannst.
• Gezielte Rollouts: Teams können Feature Flags verwenden, um ihre Ideen zu testen, indem sie ihre Funktion schrittweise einführen und nur einer begrenzten Anzahl von Nutzern einen “Early Access” zur App gewähren, z. B. durch Betatests. Auf diese Weise kannst du die Begeisterung für die neue Funktion wecken und die Auswirkungen auf diese ausgewählten Nutzer überwachen. Gezielte Rollouts ermöglichen es den Teams, fundiertere Entscheidungen darüber zu treffen, was zu optimieren ist, und die App auf der Grundlage des Live-Nutzerfeedbacks fein abzustimmen.
• Personalisierung: Feature Flags sind eine großartige Möglichkeit, das Erlebnis für verschiedene Arten von Nutzern zu personalisieren, anstatt ein einheitliches Erlebnis für alle Nutzer zu bieten. Indem du die Funktionen änderst, die bestimmte Benutzer erhalten, kannst du das Benutzererlebnis in mobilen Apps auf einzelne Benutzer oder Benutzersegmente abstimmen. So kannst du z. B. je nach Land, in dem sich der Nutzer aufhält, ein einzigartiges Erlebnis bieten.
• Rollback/Kill Switch: Das wirklich Einzigartige an Feature Flags ist, dass sie Teams in die Lage versetzen, fehlerhafte Updates schnell wieder rückgängig zu machen. Durch einfaches Deaktivieren des entsprechenden Feature Flags kannst du einen Fehler beheben, ohne den langwierigen App-Store-Review-Prozess zu durchlaufen.

Mobile Feature Flags: Use Cases

Wir haben bisher vor allem darüber gesprochen, wie Feature Flags beim Mobile App Deployment eingesetzt werden können. Sie sind aber auch eine großartige Möglichkeit, das Risiko bei der Bereitstellung und beim Testen mobiler Websites zu verringern, insbesondere wenn es um tiefgreifende Änderungen geht, die mit der Backend-Architektur verbunden sind, wie z. B. das Testen neuer Zahlungsmethoden.

Dies lässt sich mit einer Feature-Flagging-Plattform leicht bewerkstelligen, auf der Teams mit einer benutzerfreundlichen Plattform, die von allen Teams genutzt werden kann, regelmäßige Releases sicher bereitstellen können. 

Nehmen wir zum Beispiel an, du hast zwei Zahlungsfunktionen entwickelt: eine für den Desktop und eine für das Handy. Bevor du ein vollständiges Release veröffentlichst, möchtest du sie mit einer kleinen Gruppe von Early Adopters testen, um die Auswirkungen zu überwachen und die Nutzungsrate zu bestimmen.

Mit AB Tasty kannst du ganz einfach einen Anwendungsfall für das Umschalten von Funktionen in deinem AB Tasty Konto erstellen und den KPI auswählen, den du beobachten möchtest, in diesem Fall wären das die Klicks auf den Button „Zur Kasse gehen“ und dann „Conversion Rate“ als Unter-KPI.

Anschließend kannst du zwei Szenarien definieren: eines zur Aktivierung der Funktion auf dem Desktop und ein anderes zur Aktivierung auf mobilen Geräten. Du konfigurierst dann das Flag, das die neue Zahlungsmethode für jedes Szenario aktiviert, wie im Bild unten bei „Scenario mobile“ auf dem Dashboard zu sehen ist.

Mit AB Tasty kannst du ein Szenario speziell für mobile Geräte definieren. (Quelle: Screenshot von der AB Tasty Plattform für Feature Experimentation & Rollouts)

Als Nächstes sehen wir uns Beispiele aus der Praxis an, wie AB Tasty Kunden Feature Flags für mobile Tests verwenden:

Use Case 1: Decathlon

Decathlon, ein französischer Sportartikelhändler mit mehr als 2.000 Filialen in 56 Ländern, wollte die Platzierung von CTAs testen, um deren Wirkung auf allen Geräten, einschließlich Mobilgeräten, und Produktübersichtsseiten, auch Product Listing Pages (PLPs), mit Hilfe von Feature Flags zu messen.

In der ursprünglichen Version, die unten zu sehen ist, wollte das Team von Decathlon APAC eine frühere Platzierung des „In den Warenkorb“-Buttons auf Mobilgeräten auf der Hauptseite unterhalb des Produktbildes testen, um einen positiven Rollout zu gewährleisten und den Uplift zu messen. In der ursprünglichen Version mussten die Nutzer erst auf das Produkt klicken, um zur Produktdetailseite zu gelangen, bevor sie diesen Button sehen konnten.

Decathlon testete für die mobile Version das Hinzufügen eines Warenkorb-Buttons direkt auf der Produktübersichtsseite. (Quelle: Screenshots von Decathlon)

Mit der zuverlässigen Lösung von AB Tasty war das Team in der Lage, die Auswirkungen dieser neuen Funktion auf die Conversions zu testen. Die Änderung der CTA-Platzierung erwies sich als Erfolg und führte zu einem Anstieg der Transaktionsrate um 10,37 % und einem Anstieg des durchschnittlichen Bestellwerts um 11,27 $.

Use Case 2: EDF

EDF (Electricité de France) ist seit über 70 Jahren der größte Stromlieferant in Frankreich. Das Team von EDF wollte die Zahl der Online-Abonnements und -Anrufe über seine App erhöhen.

Insbesondere wollten sie die Auswirkungen einer Änderung des CTA-Designs in der App überwachen. Durch die Verwendung von Feature Flags zur Erhöhung der Sichtbarkeit der CTAs konnte das Team die Auswirkungen auf die Klicks für Online-Abonnements bzw. -Anrufe bei EDF-Beratern messen (und steigern).

Das Team führte einen A/B-Test durch, bei dem der CTA für das Abonnement vor einem orangefarbenen Hintergrund und der CTA für den Anruf vor einem grünen Hintergrund angezeigt wurde. Sie fügten auch Text hinzu, um die Öffnungszeiten zu kommunizieren.

EDF testete die Auswirkungen einer Änderung des CTA-Designs in seiner App. (Quelle: Screenshots von EDF)

Der Anruf-CTA war derjenige, der positivere Ergebnisse lieferte und es dem Team ermöglichte, mehr qualifizierte Leads zu generieren und die Zahl der Anrufe mit EDF-Beratern zu erhöhen.

Mit einem Anstieg der Anrufe um 20 % konnte das Team dann zuversichtlich eine angepasste Variante in der App entwickeln und einführen, bei welcher der neue Anruf-CTA besser sichtbar war.             

---

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

---

Use Case 3: Ornikar

Oft sind A/B-Tests eine todsichere Methode, um potenzielle Verzerrungen zu beseitigen, und können ein Unternehmen davor bewahren, in eine Optimierungskampagne zu investieren, die ansonsten viel wertvolle Zeit und Ressourcen in Anspruch nehmen würde.

Das war der Fall bei Ornikar, einer Fahrschulplattform in Frankreich mit mehr als 2,5 Millionen Kunden. Das Team wollte den Startbildschirm seiner App überarbeiten und musste herausfinden, welche Änderungen beibehalten und welche verworfen werden sollten.

Das Team richtete einen A/B-Test auf AB Tasty ein, um das bestehende Karussell mit vier Slides und zwei CTAs (linkes Bild) durch einen neuen Startbildschirm mit den Vorteilen von Ornikar, einer neuen CTA-Anordnung und einem detaillierteren Karussell (rechtes Bild) zu ersetzen.

Die Ergebnisse waren nach zwei Wochen immer noch negativ und das Team beschloss, den neuen Startbildschirm nicht in Betrieb zu nehmen.

Dank der Flexibilität der AB Tasty Plattform war das Team in der Lage, innerhalb eines kurzen Zeitraums schnelle Iterationen vorzunehmen. Vor allem konnte Ornikar den Verlust von Konversionen und die Verschwendung von Zeit und Ressourcen vermeiden und die negativen Auswirkungen minimieren, indem es den neuen Startbildschirm zunächst testete, bevor es ihn für alle seine Nutzer einführte.

 

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

Wie wir gesehen haben, sind Feature Flags ein leistungsfähiges Tool, mit dem Teams in einem Unternehmen mehr Kontrolle über mobile Tests und Veröffentlichungen haben und gleichzeitig Risiken reduzieren können.

Feature Flags unterstützen dich nicht nur beim Mobile App Deployment und geben dir die volle Kontrolle über die Veröffentlichung neuer Funktionen trotz der Genehmigungsprozesse im App und Play Store, sondern ermöglichen es den Teams auch, ihre mobilen Anwendungen zu optimieren und das Benutzererlebnis zu personalisieren. Sie ermöglichen dir auch, Funktionen häufiger zu veröffentlichen und schnelles Feedback von deinen wichtigsten Nutzern zu erhalten.

Angesichts der zunehmenden Nutzung mobiler Geräte und der Millionen von Apps, mit denen du konkurrieren musst, ist es von entscheidender Bedeutung, die bestmögliche Benutzererfahrung auf mobilen Geräten zu bieten. Die Durchführung von Experimenten und die Verwendung progressiver Rollouts mit Feature Flags sind der Schlüssel zur Bereitstellung optimaler und großartiger mobiler Erlebnisse.

Die Verwendung einer Plattform eines Drittanbieters für Feature Flags erleichtert das Ein- und Ausschalten von Funktionen und die Fernkonfiguration deiner Flags direkt von der Benutzeroberfläche aus. Indem du alle deine Feature Flags in einem benutzerfreundlichen Web Dashboard kontrollierst, stellst du sicher, dass du mit den wichtigsten Best Practices Schritt hältst, um erfolgreich zu sein und dich von der Konkurrenz abzuheben.