Einschätzung der Einführung eines Feature-Flags
So planen Sie die Einführung eines Feature-Flags: schrittweise Prozentsätze, Kill-Switches, Gating-Kennzahlen und die Aufräumarbeiten, die niemand einplant. Ein Flag ist ein kleines Produkt, kein Deployment.
In der Geschichte wird die Flagge eingesetzt, doch die Nachbereitung, die Kennzahlen und der Notschalter werden dabei außer Acht gelassen.
Ein Feature-Flag ist kein Deployment-Mechanismus, sondern ein eigenständiges Produkt. Es benötigt einen Standardwert, einen Überbrückungspfad, einen Prüfpfad, einen Kill-Switch und einen Plan zur Deaktivierung. Die meisten dieser Elemente fehlen im ursprünglichen Ticket, in dem es meist nur heißt: „Verpacken Sie es in ein Flag.“ Dieses Ticket ist das Tor, nicht die Funktion.
Der Kostenvoranschlag muss die Einführungsphasen (1 % → 10 % → 50 % → 100 %), die Kennzahlen, anhand derer in jeder Phase über eine Ausweitung oder Rücknahme entschieden wird, sowie das Bereinigungsticket berücksichtigen, mit dem die Markierung entfernt wird, sobald die Funktion dauerhaft implementiert ist. Teams, die keine Bereinigung einplanen, liefern innerhalb eines Jahres eine Codebasis voller veralteter Markierungen aus – was eine eigene Form von operativer Schuld darstellt.
Was in dem Raum gesagt wird
Backend: „Den Aufruf in ein Flag einbinden – ein paar Zeilen.“
SRE: „Anhand welcher Kennzahl lässt sich erkennen, dass die Einführung nicht nach Plan verläuft?“
PM: „Für welche Kohorten wird das Kennzeichen zuerst aktiviert?“
Leitfrage: „Wer entfernt die Flagge, sobald wir 100 % erreicht haben, und wann?“
Backend: „Gibt es einen Kill-Switch, der unabhängig von dem Flag ist?“
Fragen, die man sich vor der Stimmabgabe stellen sollte
- Einführungsmodell: lineare Einführung, kohortenbasiert oder boolescher Übergang?
- Standardwert, wenn der Flag-Dienst ausgefallen ist – altes oder neues Verhalten?
- Kennzahlen, die den Übergang in die nächste Phase regeln – was gilt als „gut verlaufen“?
- Ist der Kill-Switch-Pfad unabhängig vom Flag-System?
- Abholbeleg: im Voraus erstellen oder „das machen wir später“?
- Prüfpfad: Wer hat die Markierung geändert, wann und warum?
Die Lösung ist dieselbe wie bei den meisten Rollout-Stories: split Teilen Sie die Implementierung, den schrittweisen Rollout und die Nachbereinigung in separate Stories auf und erstellen Sie das Ticket für die Rücknahme, bevor Sie vergessen, dass es überhaupt existiert.
Ein Flag ist ein kleines Produkt. Schätzen Sie den Anlauf, die Gating-Kennzahlen und die Nachbearbeitung ein – nicht nur die Fertigstellung.
Siehe Schätzung einer schrittweisen Einführung von Ratenbeschränkungen für dasselbe Muster, bei dem die schrittweise Einführung den Arbeitsaufwand in Anspruch nimmt, sowie die weiteren Beispiele für funktionierende Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Phasen benannt sind.