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 dotyczy miejsc wywołania: każdej funkcji 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 ta 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, 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, kiedy tylko będą miały na to czas.
O czym się mówi w tym pomieszczeniu
Projektant: „Nowa żetona to zmiana obejmująca tylko jedną linię”.
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?”
PM: „W jakim terminie zostanie wycofana stara wersja?”
Pytania, które warto zadać przed oddaniem głosu
- 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 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 porządkowanie w dolnej części, dlatego należy je rozdzielić: nowy komponent stanowi jedną historię, a migracja miejsc wywołań – kolejną, przy czym wielkość tej drugiej historii określa się na podstawie zmierzonej liczby, a nie na podstawie przypuszczeń.
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 w części upstream jest niewielka, a prawdziwą pracą jest uporządkowanie części downstream. Proszę zapoznać się z innymi przykładami szacowania lub rozpocząć bezpłatną sesję „planning poker”, gdy wielkość części downstream zostanie oszacowana.