Einschätzung einer Änderung am Design-System
So schätzen Sie den Umfang einer Ä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 ab.
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 ist 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 einführen, stellen zwei Systeme bereit: das neue und alle Stellen, an denen noch das alte verwendet wird. Die Schätzung muss die Einführung berücksichtigen – sei es per „Codemod“ oder manuelle Migration, den Zeitplan für die Auslaufphase sowie die Strategie zur Vermeidung visueller Regressionen –, 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 betroffen – gemessen, nicht geschätzt?
- Codemod oder manuelle Migration? Wie hoch ist die Abdeckung des Codemods?
- Ablaufplan für die Ausmusterung: Warnung, Fehler, Entfernung – in welchem Zeitrahmen?
- 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 Produktionsbetrieb zutage tritt?
Die Änderung im vorgelagerten Bereich ist gering, während die Bereinigung im nachgelagerten Bereich den eigentlichen Arbeitsaufwand darstellt; daher sollten Sie diese aufteilen:/guides/agile-estimation-guide/splitting-user-stories/ Die neue Komponente entspricht einer Story, die Migration der Aufrufstellen einer weiteren, wobei der Umfang der zweiten Story anhand der ermittelten Anzahl bestimmt wird – und nicht anhand einer Schätzung.
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 gering, während der Aufwand im Downstream liegt. Sehen Sie sich die anderen Beispiele für Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Umfang des Downstreams feststeht.