Einschätzung einer Änderung am Design-System
So schätzen Sie den Aufwand einer Änderung am Design-System ein: Token-Einführung, Auslaufpfade, Codemod-Abdeckung und die 200 Aufrufstellen, die die alte Komponente verwenden. Bewerten Sie den Umfang der nachgelagerten Auswirkungen.
In dem Artikel wird die neue Komponente geschätzt, wobei die 200 Standorte, an denen die alte Komponente zum Einsatz kommt, außer Acht gelassen werden.
Eine Änderung am Design-System umfasst zwei Bereiche. Der erste betrifft das System selbst: die neue Komponente, das neue Token, die aktualisierte Dokumentation. Der zweite betrifft die Aufrufstellen: jede Produktfunktion, die die alte Version genutzt hat und auf die neue migriert werden muss. Der erste Bereich ist klein und bekannt. Der zweite ist der Grund dafür, dass die Arbeit tatsächlich ein Quartal in Anspruch nimmt.
Teams, die die systemseitige Änderung ohne Auslaufplan bereitstellen, stellen zwei Systeme bereit: das neue und alle Stellen, an denen noch das alte verwendet wird. Die Schätzung muss die Einführung (Codemod oder manuelle Migration, Zeitplan für die Auslaufphase, Strategie zur visuellen Regression) berücksichtigen; andernfalls kommt die Arbeit an dieser Stelle einfach für Monate zum Stillstand, während die Feature-Teams sich darum kümmern, wann immer sie dazu kommen.
Was in dem Raum gesagt wird
Entwickler: „Die Änderung am neuen Token umfasst nur eine Zeile.“
Frontend: „Wie viele Komponenten nutzen es derzeit?“
Leitfrage: „Führen wir einen Codemod durch, oder übernehmen die Feature-Teams die Migration selbst?“
Frage: „Visuelle Regression: Percy? Manuell? Beides?“
PM: „Wie lange läuft die Auslaufphase für die alte Version?“
Fragen, die man sich vor der Stimmabgabe stellen sollte
- Wie viele Standorte sind betroffen – und zwar nach einer genauen Erhebung und nicht nur nach einer Schätzung?
- Codemod oder manuelle Migration? Wie hoch ist die Abdeckung des Codemods?
- Wie sieht der Zeitplan für den Auslaufprozess (Warnung, Fehler, Entfernung) aus?
- Wird die visuelle Regression auf den betroffenen Bildschirmen abgedeckt?
- Teamübergreifende Kommunikation: Wem teilen wir was mit, wann und wie?
- Sollte ein Rollback erfolgen, wenn die neue Komponente einen Fehler aufweist, der erst im Produktivbetrieb zutage tritt?
Die Änderung im vorgelagerten Bereich ist gering, während die Bereinigung im nachgelagerten Bereich den eigentlichen Arbeitsaufwand darstellt; daher teilen Sie diese auf: Die neue Komponente entspricht einer Story, die Migration der Aufrufstellen eine weitere, und der Umfang der zweiten Story richtet sich nach der ermittelten Anzahl und nicht nach einer Schätzung.
Schätzen Sie die Migration in flussabwärts gerichteter Richtung. Das neue Token stellt eine Linie dar; die 200 Aufrufstellen entsprechen dem Viertel.
Ähnlich wie bei der Schätzung eines Framework-Upgrades ist die Änderung im Upstream gering, während der Aufwand im Downstream liegt. Sehen Sie sich die anderen Beispiele für gelungene Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Umfang der Downstream-Arbeiten feststeht.