Welcher Anteil ausgelieferter Features wird 90 Tage nach der Veröffentlichung noch genutzt, und was geschah mit den ungenutzten und ihren Flags?

Offene Frage

Feature-Flag-Werkzeuge haben begonnen, die Lebensdauer eines Flags zu formalisieren: Die Unleash-Dokumentation weist jedem Flag-Typ eine erwartete Lebensdauer zu und legt fest, dass alle Flags nach deren Ablauf automatisch als potenziell veraltet markiert werden, als Anstoss zum Aufräumen. Das erledigt das Flag. Über das Feature dahinter sagt es nichts, und das Wiki hat keine Belege zur unbequemeren Hälfte der Frage: Wie viele der Features, die ein Team in einem Jahr ausliefert, werden noch genutzt, nachdem die Ankündigung zur Einführung verklungen ist?

Die Frage ist bewusst eng gefasst. Für jedes in einem definierten Zeitraum veröffentlichte Feature mit einem Nutzungssignal (ein Event, eine Einstellung, ein Seitenaufruf) dasselbe Signal 90 Tage nach der Veröffentlichung betrachten. Welcher Anteil der Features hatte eine Nutzung oberhalb einer Schwelle, die das Team als bedeutsam ansieht, welcher Anteil hatte nur vereinzelte Nutzung, und welcher Anteil praktisch keine? Welche Merkmale trennten die Gruppen: von vielen Nutzern angefragte Features gegenüber solchen, die ein einzelner Grosskunde wünschte, im Hauptablauf auffindbare Features gegenüber solchen hinter einer Einstellungsseite, Features, die bestehendes Verhalten ersetzten, gegenüber solchen, die etwas hinzufügten? Dann das Schicksal: Entfernte das Team Features ohne nennenswerte Nutzung, versteckte es sie, liess es sie bestehen, oder investierte es in deren Bewerbung, und wie kam diese Entscheidung zustande? Und der technische Nachlauf: Wurden die Flags ungenutzter Features entfernt, eingeschaltet belassen oder ausgeschaltet belassen, während der Code bestehen blieb, und spielte der Veraltungs-Marker des Flag-Werkzeugs dabei eine Rolle?

Die Antwort ist wichtig, weil Roadmaps so geplant werden, als würde jedes ausgelieferte Feature behalten, während die Kosten eines ungenutzten Features (sein Code, sein Flag, seine Tests, seine Dokumentation, seine Support-Anfragen) weiterlaufen, bis jemand eine andere Entscheidung trifft.

Was eine nützliche Antwort enthält

Der Produkttyp, die Anzahl Nutzer und die Anzahl der im Zeitraum veröffentlichten Features samt Definition von «Feature» (eine Einheit, die ein Nutzer benennen könnte, kein Commit). Das Nutzungssignal pro Feature und die für «bedeutsam» verwendete Schwelle samt Begründung. Der Anteil in jeder Nutzungsklasse nach 90 Tagen und, sofern verfügbar, zu einem späteren Zeitpunkt, da manche Features nur langsam wachsen. Die pro Feature erfassten Merkmale und ihr Zusammenhang mit der Nutzung. Die für jedes wenig genutzte Feature getroffene Entscheidung und wer sie getroffen hat. Der Zustand von Flag und Code sechs Monate später. Ob die Analyse die Planung des Teams veränderte, etwa indem vor dem Bau eine Nutzungserwartung formuliert wurde. Das Jahr eines einzelnen Teams ist eine nützliche Antwort, sofern die Definitionen genannt werden.