Estymata dla projektów mobilnych — co to jest, metody szacowania zadań

Czym jest estymata?

Estymata (z ang. estimate — ocena) — to prognozowanie ilości czasu lub wysiłku potrzebnego do wykonania zadania. W programowaniu mobilnym estymaty wyrażane są w godzinach, dniach, story pointach lub ekwiwalencie pieniężnym. Celem estymaty nie jest dokładne przewidywanie, ale zmniejszenie niepewności w celu podejmowania decyzji.

Czym estymata różni się od zobowiązania

Estymata — to prognoza z marginesem błędu. Zobowiązanie (commitment) — to obietnica wykonania zadania w określonym terminie. Różnica jest kluczowa: estymata mówi „prawdopodobnie 5 dni„, zobowiązanie — „zrobimy w 5 dni„. Menedżerowie często mylą te pojęcia, zamieniając estymatę w deadline bez prawa do błędu.

Estymata jako narzędzie komunikacji

Proces estymowania jest równie ważny jak jego wynik. Kiedy zespół omawia ocenę zadania, ujawniają się ukryte wymagania, zależności i ryzyka. Nawet jeśli końcowa liczba jest niedokładna, dyskusja daje wszystkim uczestnikom zrozumienie zadania. Dlatego kolektywne metody oceny (Planning Poker) są skuteczniejsze niż indywidualne.

Metody estymacji w programowaniu

Istnieje kilka metod estymacji, a każda z nich jest odpowiednia dla różnych etapów projektu i poziomów szczegółowości. Wybór metody zależy od dostępnych danych i wymaganej dokładności.

Planning Poker

Planning Poker — najpopularniejsza metoda oceny w Agile. Każdy programista otrzymuje talię kart z liczbami Fibonacciego (1, 2, 3, 5, 8, 13, 21). Po omówieniu zadania wszyscy jednocześnie pokazują kartę. Jeśli oceny się różnią — programiści z minimalną i maksymalną oceną wyjaśniają swój tok myślenia, po czym następuje ponowne głosowanie. Metoda eliminuje wpływ autorytetów i daje dokładniejszą ocenę.

T-Shirt sizing

T-Shirt sizing — zgrubna ocena według rozmiaru koszulki: XS, S, M, L, XL, XXL. Metoda jest używana do szybkiej oceny dużych zadań (epików) na wczesnych etapach, gdy szczegóły nie są znane. Później każde takie zadanie jest dekomponowane i oceniane w Planning Poker. T-Shirt sizing zajmuje 5-10 minut na zadanie, ale daje tylko rząd wielkości.

Three-point estimation (PERT)

PERT wykorzystuje trzy oceny: optymistyczną (O), pesymistyczną (P) i najbardziej prawdopodobną (M). Ostateczna ocena obliczana jest według wzoru: (O + 4M + P) / 6. Metoda uwzględnia niepewność i daje bardziej realistyczny wynik niż pojedyncza ocena. PERT jest szczególnie przydatny w przypadku zadań o wysokim ryzyku lub z nowymi technologiami.

Dokładność estymaty: oczekiwania vs rzeczywistość

Dokładność estymaty zależy od etapu projektu i ilości znanych informacji. Im wcześniej dokonuje się oceny, tym większy margines błędu — to normalne i powinno być uwzględniane w planowaniu.

Stożek niepewności

Stożek niepewności (Cone of Uncertainty) — model opisujący, jak zmniejsza się margines błędu oceny w miarę postępu projektu. Na etapie koncepcji margines błędu wynosi 400% (zadanie może zająć od 1 do 4 miesięcy). W momencie sprintu — 20% (1-1.2 miesiąca). Świadomość tego modelu pomaga nie wymagać dokładnych ocen na wczesnych etapach.

Czynniki wpływające na dokładność

• Złożoność zadania — nowa technologia czy znana? Nieznane zwiększa margines błędu 2-3 razy.
• Rozmiar zadania — małe zadania (do 2 dni) są oceniane dokładniej niż duże. Dekompozycja poprawia dokładność.
• Doświadczenie zespołu — zespół pracujący razem 6+ miesięcy ocenia o 30-50% dokładniej niż nowy.
• Dane historyczne — posiadanie metryk velocity i cyklometrii zwiększa dokładność prognoz.

Ocena względna vs bezwzględna

Ocena względna (w story pointach) jest dokładniejsza niż bezwzględna (w godzinach), ponieważ ludzie lepiej porównują zadania niż oceniają czas. „To zadanie jest dwa razy bardziej złożone niż tamto„ — to bardziej wiarygodny osąd niż „to zadanie zajmie 8 godzin„. Oceny względne nie zależą od konkretnego programisty i zachowują dokładność przy zmianie wykonawcy.

Jak poprawić dokładność oceny: najlepsze praktyki

Dokładność estymaty można poprawić poprzez systematyczne podejście, kolektywne omówienie i analizę przeszłych błędów. Istnieje kilka sprawdzonych praktyk.

Dekompozycja do 1-2 dni

Każde zadanie ocenione na więcej niż 2 dni powinno zostać zdekomponowane na podzadania. Zasada: jeśli zadania nie można ocenić z dokładnością 50%, znaczy, że jest zbyt duże. Podziel je na kroki, z których każdy jest zrozumiały i ocenialny. Po dekompozycji sumaryczna ocena często okazuje się 1.5-2 razy większa niż początkowa.

Dane historyczne i metryki

Prowadź historię ocen i porównuj z faktycznym nakładem pracy. Na przykład: „zadania ocenione na 3 story pointy średnio zajmują 4 dni, a nie 2„. Używaj velocity zespołu do prognozowania: jeśli zespół zamyka 20 story pointów w sprincie, nie planuj 30. Analiza dokładności poprzednich ocen to najlepszy trening umiejętności estymacji.

Kotwiczenie i kalibracja

Kotwiczenie — efekt psychologiczny, w którym pierwsza głośno wyrażona ocena wpływa na wszystkich uczestników. Aby uniknąć kotwiczenia, w Planning Poker wszyscy pokazują karty jednocześnie, a nie po kolei. Kalibracja — regularne porównywanie ocen z faktami: po 10-20 sprintach zespół uczy się oceniać dokładniej dzięki informacji zwrotnej.

Uwzględnianie ryzyk w ocenie

Każde zadanie zawiera ukryte ryzyka: choroba programisty, problem z API, zmiana wymagań. Dodawaj do oceny risk-adjusted factor: dla zadań z wysokim ryzykiem — mnożnik 1.5-2, z niskim — 1.1-1.2. Przejrzyście pokazuj klientowi, jakie ryzyka są uwzględnione i jak wpływają na terminy.

Typowe błędy przy estymacji

Błędy przy estymacji powtarzają się w większości zespołów, niezależnie od ich dojrzałości. Znajomość tych błędów to pierwszy krok do ich naprawienia.

Optymistyczna ocena

Najczęstszy błąd — ocena według najlepszego scenariusza: „jeśli wszystko pójdzie idealnie, zrobimy w 3 dni„. W rzeczywistości nic nie idzie idealnie: bugi, pytania dotyczące wymagań, zależne zadania. Rozwiązanie: oceniać według najbardziej prawdopodobnego scenariusza, a nie optymistycznego. Używaj PERT do uwzględnienia zmienności.

Ocena pod presją

Kiedy menedżer mówi „potrzebujemy do piątku„, programista podświadomie dostosowuje ocenę do tego terminu. Ocena pod presją jest zawsze zaniżona i prowadzi do przekroczenia terminów. Rozwiązanie: ocena powinna poprzedzać deadline, a nie odwrotnie. Najpierw zespół ocenia, potem strony ustalają terminy.

Mylenie złożoności z czasem

Złożoność zadania (ile myśleć) i czas (ile robić) — to różne metryki. Zadanie może być proste, ale czasochłonne (zakodować 10 ekranów). Albo złożone, ale szybkie (znaleźć błąd w legacy). W story pointach zazwyczaj ocenia się złożoność, a czas wyprowadza się z velocity zespołu.

Ignorowanie przełączeń kontekstu

Programista nie pracuje 8 godzin bez przerwy nad jednym zadaniem: spotkania, code review, pomoc kolegom, sprawy administracyjne pochłaniają 30-50% czasu pracy. Przełączenia kontekstu powinny być uwzględnione w estymacie: realnie programista pisze kod 3-4 godziny dziennie.