Ocena zmian w systemie projektowym

W artykule oszacowano liczbę nowych komponentów, pomijając jednak 200 miejsc, w których stosowany jest stary komponent.

Zmiana w systemie projektowym obejmuje dwa zakresy. Pierwszym z nich jest sam system: nowy komponent, nowy token, zaktualizowana dokumentacja. Drugi to miejsca wywołania: każda funkcja produktu, która korzystała ze starej wersji i wymaga migracji do nowej. Pierwszy zakres jest niewielki i znany. To właśnie drugi zakres sprawia, że praca faktycznie zajmuje cały kwartał.

Zespoły, które wdrażają zmianę po stronie systemu bez planu wycofania, wdrażają w rzeczywistości dwa systemy: nowy oraz wszystkie miejsca, w których nadal wykorzystywany jest stary. Szacunek musi uwzględniać proces wdrażania (modyfikacja kodu lub ręczna migracja, harmonogram wycofywania funkcji, strategia kontroli regresji wizualnej) – w przeciwnym razie prace po prostu utkną w martwym punkcie na wiele miesięcy, a zespoły funkcjonalne zajmą się tym dopiero wtedy, gdy znajdą na to czas.

O czym się mówi w tym pomieszczeniu

Projektant: „Nowa żetona to zmiana obejmująca jedną linię”.

Frontend: „Ile komponentów korzysta z tego obecnie?”

Wprowadzenie: „Czy przeprowadzamy modyfikację kodu, czy też zespoły funkcjonalne samodzielnie dokonują migracji?”

Pytanie dotyczące kontroli jakości: „Regresja wizualna: Percy? Ręczna kontrola? A może jedno i drugie?”

Premier: „W jakim terminie planowane jest wycofanie starej wersji?”

Pytania, które warto zadać przed głosowaniem

• Ile miejsc wywołań jest objętych tym zjawiskiem – na podstawie pomiarów, a nie szacunków?
• Codemod czy migracja ręczna? Jaki jest zakres działania narzędzia Codemod?
• W jakim harmonogramie będzie przebiegać proces wycofywania funkcji (ostrzeżenie, błąd, usunięcie)?
• Czy przeprowadzono testy regresji wizualnej na ekranach, których dotyczy problem?
• Komunikacja między zespołami: komu, kiedy i w jaki sposób należy przekazać informacje?
• Czy należy przywrócić poprzednią wersję, jeśli nowy komponent zawiera błąd, który ujawnił się dopiero w środowisku produkcyjnym?

Zmiana w górnej części kodu jest niewielka, a prawdziwą pracą jest porządkowanie w dolnej części, dlatego należy je rozdzielić: nowy komponent stanowi jedną historię, a migracja miejsc wywołań – kolejną, przy czym rozmiar tej drugiej opiera się na zmierzonej liczbie, a nie na przypuszczeniach.

Proszę oszacować migrację w kierunku dolnym. Nowy token to linia; 200 miejsc wywołania to kwartał.

Podobnie jak w przypadku oszacowania modernizacji frameworka, zmiana po stronie upstream jest niewielka, a prawdziwą pracą jest uporządkowanie po stronie downstream. Proszę zapoznać się z innymi przykładami oszacowań lub rozpocząć bezpłatną sesję planowania pokerowego, gdy wielkość zadań po stronie downstream jest już znana.