Einschätzung einer Änderung am Design-System
So schätzen Sie den Aufwand für eine Änderung am Design-System ein: Token-Einführung, Auslaufpfade, Codemod-Abdeckung und die 200 Aufrufstellen, die die alte Komponente verwenden. Schätzen Sie den Umfang der nachgelagerten Auswirkungen ein.
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 monatelang 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?“
QA: „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 davon betroffen – und zwar nach genauer Ermittlung und nicht nur nach 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 Großteil der Arbeit ausmacht; teilen Sie die Aufgaben daher auf: Die neue Komponente bildet eine Story, die Migration der Aufrufstellen eine weitere, wobei der Umfang der zweiten Story anhand der ermittelten Anzahl und nicht anhand einer Schätzung festgelegt wird.
Schätzen Sie die Migration in Richtung Flusslauf. Das neue Token ist eine Linie; die 200 Aufrufstellen sind das Viertel.
Ähnlich wie bei der Schätzung eines Framework-Upgrades ist die Änderung im Upstream-Bereich gering, während der Aufwand im Downstream-Bereich liegt. Sehen Sie sich die anderen Beispiele für Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Umfang des Downstream-Bereichs feststeht.