Oszacowanie kosztów modernizacji platformy
Jak oszacować nakład pracy związany z aktualizacją frameworka: dlaczego zmiana wersji głównej to projekt, a nie zgłoszenie, oraz jak podzielić go na zadania, których nakład pracy można faktycznie oszacować.
Aktualizacje do nowych wersji głównej nie są zgłoszeniami. Są to projekty.
Wersje poprawkowe to zgłoszenia. Wersje pomniejsze zazwyczaj również stanowią zgłoszenia. Wersje główne (te, które wiążą się ze zmianami powodującymi niekompatybilność, cyklami wycofywania funkcji, kaskadowymi skutkami zależności między komponentami oraz adnotacjami typu „zalecamy migrację do…” w dzienniku zmian) to projekty, a planning poker nie jest odpowiednim narzędziem do oszacowania ich całościowego zakresu. Zadanie o treści „aktualizacja do React 19” lub „Postgres 16” nie stanowi samego zadania; jest jedynie oprawą dla tego zadania.
Potraktowanie aktualizacji jako pojedynczego oszacowania prowadzi do jednego scenariusza niepowodzenia: zespół przyznaje 13 punktów, w trzecim tygodniu kończy mu się czas i wydaje w połowie zmodernizowany kod, zawierający zarówno błędy nowego frameworka, jak i idiomy starego frameworka. Najbardziej uczciwym rozwiązaniem jest podzielenie aktualizacji na sekwencję mniejszych zadań, z których każde można oszacować niezależnie, a samą aktualizację traktować jako projekt nadrzędny.
O czym się mówi w tym pomieszczeniu
Inżynier: „Kodemod zajmuje się większością tych zadań”.
Wstęp: „Większość czego? A z czym sobie nie radzi?”
SRE: „Czy wszystkie nasze zależności obsługują już nową wersję?”
Pytanie: „Jaka jest nasza strategia testowania regresyjnego dla tej zmiany?”
PM: „Czy w tym sprincie planujemy jeszcze jakieś wydania, czy to już cały sprint?”
Pytania, które warto zadać przed oddaniem głosu
- Ile zmian powodujących niekompatybilność dotyczy naszego kodu źródłowego (proszę zapoznać się z dziennikiem zmian i policzyć)?
- Czy zależności od elementów równorzędnych obsługują wersję docelową, czy też stosujemy kaskadę?
- Codemod czy ręczna weryfikacja? Jaki jest stopień pokrycia sprawdzanego kodu przez Codemod?
- Zakres testów na zmodyfikowanych powierzchniach: czy jest wystarczający, czy też powinniśmy najpierw dodać testy?
- Jaka jest strategia wycofania się, jeśli w trakcie sprintu sytuacja ulegnie pogorszeniu?
- Jeden PR czy wiele? Jeśli wiele, to jaka jest kolejność zależności?
Właściwym wynikiem tej rozmowy jest często stwierdzenie: „to nie jest historia, to projekt, więc zaplanujmy go w ten sposób”, a następnie podzielenie go na części, które każdy członek zespołu może oszacować w odniesieniu do historii referencyjnej.
Nie przypisujcie jednej liczby do dużego ulepszenia. Podzielcie je na zadania, a następnie oszacujcie ich zakres.
Zapoznaj się z technikami szacowania w przypadku zadań o bardziej nieokreślonym charakterze lub większym zakresie oraz z metodą szacowania nakładu na wstępne badania, które powinny poprzedzać samo oszacowanie. Zapoznaj się z innymi przykładami szacowania z obliczeniami.