Oszacowanie zakresu zmian w systemie projektowym
Jak oszacować zakres zmian w systemie projektowym: wdrażanie tokenów, ścieżki wycofywania, zasięg narzędzia Codemod oraz 200 miejsc wywołania, w których wykorzystywany jest stary komponent. Proszę oszacować skalę zmian w dalszych etapach procesu.
W artykule oszacowano liczbę nowych komponentów, pomijając jednak 200 miejsc, w których nadal 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łań — 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ą zmiany po stronie systemu bez planu wycofywania, wdrażają w rzeczywistości dwa systemy: nowy oraz wszystkie miejsca, w których nadal korzysta się ze starego. Szacunki muszą uwzględniać proces wdrażania — modyfikację kodu lub ręczną migrację, harmonogram wycofywania — oraz strategię kontroli regresji wizualnej; w przeciwnym razie prace po prostu utkną w martwym punkcie na wiele miesięcy, a zespoły funkcjonalne będą się tym zajmować dopiero wtedy, gdy znajdą na to czas.
O czym się mówi w tym pomieszczeniu
Projektant: „Nowa żetona to zmiana obejmująca tylko jedną linię kodu”.
Frontend: „Ile komponentów korzysta z tego obecnie?”
Wstęp: „Czy przeprowadzamy modyfikację kodu, czy też zespoły funkcjonalne samodzielnie dokonują migracji?”
Pytanie dotyczące kontroli jakości: „Regresja wizualna — Percy? Ręczna? A może obie?”
Premier: „W jakim terminie zostanie wycofana stara wersja?”
Pytania, które warto zadać przed oddaniem głosu
- Ile miejsc wywołania jest objętych badaniem — na podstawie pomiarów, a nie szacunków?
- Codemod czy migracja ręczna? Jaki jest zakres działania narzędzia Codemod?
- Schemat wycofywania funkcji: ostrzeżenie, błąd, usunięcie — w jakim horyzoncie czasowym?
- Czy przeprowadzono testy regresji wizualnej na ekranach, których dotyczy problem?
- Komunikacja między zespołami: komu, kiedy i w jaki sposób przekazujemy informacje?
- Czy należy przywrócić poprzednią wersję, jeśli w nowym komponencie wykryto błąd, który ujawnił się dopiero w środowisku produkcyjnym?
Zmiana w górnej części kodu jest niewielka, a prawdziwą pracą jest uporządkowanie kodu w dolnej części, dlatego należy je rozdzielić: nowy komponent to jedno zadanie, a migracja miejsc wywołań to kolejne, przy czym wielkość tego drugiego zadania wynika z faktycznej liczby wywołań — a nie z przybliżonych szacunków.
Proszę oszacować migrację w kierunku dolnym. Nowy token to linia; 200 miejsc wywołania to kwartał.
Podobnie jak w przypadku szacowania kosztów aktualizacji frameworka, zmiana po stronie upstream jest niewielka, a prawdziwą pracą jest uporządkowanie po stronie downstream. Proszę zapoznać się z innymi przykładami szacowania lub rozpocząć bezpłatną sesję Planning Pokera, gdy znana jest wielkość zakresu prac po stronie downstream.