Kiedy wiemy już jak ułatwić sobie estymowanie całych projektów i na co zwrócić uwagę przygotowując oszacowania, czas przejść do technik i metod szacowania poszczególnych zadań.
Najprostszym sposobem szacowania zadań jest oczywiście przypisanie im określonej wartości liczbowej, wyrażającą liczbę godzin potrzebną do wykonania zadania. Ważne, jest aby zadanie którego określam czas było odpowiednio małe. (Więcej na temat dzielenia projektu na zadania znajdowało się w części 2).
Taki sposób szacowań jest dalece nieidealny. Powodując wiele problemów, a przede wszystkim błędów. Dlatego wymyślono kilka metod, które mogą pomóc.
Szacowanie ważone (trójpunktowe)
Technika szacowania trójpunktowego, pochodzi z Metody PERT. Zdecydowanie jest jedną z najchętniej przeze mnie wykorzystywanych. Polega na wyliczeniu wartości czasu wykonania zadania na podstawie 3 pośrednich wartości:
- Szacunek optymistyczny (To)
- Szacunek realistyczny (Tr)
- Szacunek Pesymistyczny (Tp)
Wartość czasu oblicza się ze wzoru na średnią ważona z następującymi wagami:
T = (To + 4*Tr + Tp) / 6.
Z mojego doświadczenia wartości wag, powinny być jednak różnicowane w zależności od wykonawcy zadania. Na przykład niedoświadczony, początkujący programista, ma zwykle tendencję do podawania znacznie bardziej optymistycznych wartości, niż jego doświadczony kolega. Dla takich osób możemy przyjąć na przykład następujące wagi:
T = (To + 3*Tr+2*Tp) / 6
Szacowanie trójpunktowe jest niezwykle efektywne ponieważ zmusza do zastanowienia się chwilę dłużej za nim podamy prognozowane przez Nas wartości. Poza tym mamy większą świadomość co oznaczają zapisane liczby. W przypadku gdy mamy tylko jedną wartość, to tak naprawdę nie wiemy czy ktoś napisał swoją wersję pesymistyczną, czy może optymistyczną.
Szacowanie względne
Technika ta, o ile dobrze pamiętam, popularyzowana jest w metodykach zwinnych. Pomysł polega na tym, aby wybrać sobie jedno zadanie, które będzie nam łatwo oszacować i każde inne zadanie porównywać i zapisywać jako wielokrotność tego pierwszego.
Wybrane przez Nas zadanie jako wzorcowe powinno być dość małe. Gdybyśmy wskazali duże zadanie (np. 20h), to zapewne w projekcie znalazłoby się sporo prac, które musiałyby być jakimiś wartościami ułamkowymi. O ile stosowanie jeszcze miar na poziomie 0,5 jest w porządku, to już rozdrabnianie się na ułamki typu 1/4, 1/5 itp. wprowadzałoby tylko niepotrzebnie wiele bałaganu.
Metoda ta posiada jeszcze drugi problem. W projekcie, nawet w części programistycznej wiele zadań jest drastycznie różnych od siebie i ciężko jest je porównywać. Weźmy na przykład zadanie zmiany układu wyświetlania strony, a zintegrowanie portalu z systemem płatności. Jakby nie patrzeć, to że przebudowanie widoku zajmuje mi 4h, jakoś nie rozjaśnia sprawy ile czasu potrzeba na integrację z zewnętrznym systemem.
Dlatego moim zdaniem warto korzystać z metody szacowania względnego jako uzupełnienia, a nie samodzielnej techniki.
