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 entschieden wird, ob die Einführung ausgeweitet oder zurückgenommen 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 Verschuldung darstellt.
Was in dem Raum gesagt wird
Backend: „Den Aufruf in ein Flag einbinden – nur 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 nimmt die Flagge ab, 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: Linearer Übergang, kohortenbasierte Einführung oder boolescher Übergang?
- Standardwert, falls 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: Teilen Sie die Implementierung, den schrittweisen Rollout und die Nachbereinigung in separate Stories auf und erstellen Sie das Ticket für die Deinstallation, bevor Sie vergessen, dass es überhaupt existiert.
Ein Flag ist ein kleines Produkt. Schätzen Sie den Anlauf, die Gating-Kennzahlen und die Nachbereitung ein, nicht nur den Abschluss.
Lesen Sie den Abschnitt „Schätzung der Einführung einer Ratenbegrenzung“ für dasselbe Muster „Einführung verschlingt die Arbeit“ sowie die anderen Beispiele für funktionierende Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Phasen benannt sind.