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 to nie zgłoszenia. To projekty.
Wersje poprawkowe to zadania. Wersje pomniejsze zazwyczaj również stanowią zadania. 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 jest samym zadaniem; stanowi jedynie opakowanie dla rzeczywistego zadania.
Traktowanie aktualizacji jako pojedynczego szacunku prowadzi do jednego scenariusza niepowodzenia: zespół przyznaje szacunek 13, w trzecim tygodniu kończy mu się czas i wydaje w połowie zaktualizowany 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 — czy należy zapoznać się z dziennikiem zmian i je 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 testami w przypadku Codemodu?
- Zakres testów na zmodyfikowanych obszarach — czy jest wystarczający, czy też powinniśmy najpierw dodać testy?
- Jaka jest strategia wycofania się, gdyby w trakcie sprintu sytuacja uległa 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 — 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 poszczególne zadania, a następnie oszacujcie ich zakres.
W przypadku zadań o mniej sprecyzowanym charakterze lub o większym zakresie proszę zapoznać się z sekcją techniki szacowania, a w odniesieniu do analizy, która powinna poprzedzać szacowanie – z sekcją szacowanie zadania badawczego. Zapraszamy do zapoznania się z innymi przykładami szacowania z objaśnieniami.