Software engineering

Przyjrzymy się dwóm powszechnie znanym rodzajem estymacji, a na potrzeby tego artykułu nazwę je:

• estymacja absolutna

• estymacja relatywna

Estymacja absolutna

Ten rodzaj estymacji polega na określeniu w godzinach (lub w dniach), ile coś zajmie np. dodanie funkcjonalności oceniania produktów zajmie 20 godzin. Po realizacji tego zadania widać, czarno na białym, jaki był czas pracy i czy udało się w nim zmieścić.

Ten rodzaj estymacji dobrze się sprawdza przy planowaniu pracy i pozwala wysokopoziomowo zaplanować, na kiedy możemy coś dostarczyć. Ważne jest tutaj, aby dzielić zadania do wyceny na jak najmniejsze. Samo rozbicie żądań na małe kawałki sprawia, że zrozumiesz je lepiej, a co za tym idzie wycena może być bardziej trafna.

Można też sobie ustalić skalę, według której estymujemy zadania:

• małe zadania: 4h

• średnie: 8h

• duże: 16h

Przy wycenach używamy wtedy tej skali i nie zastanawiamy się, czy coś zajmie 5, czy 6 godzin, tylko próbujemy to wpasować w jedną z opcji: małe (4h), średnie (8h).

Estymacja relatywna

W tym przypadku nie estymujemy w godzinach, czy w dniach, a używamy do tego innej miary np.

• ciągu Fibonacciego (liczby 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89)

• rozmiaru koszulek (xxs, xs, s, m, l, xl, xxl)

• potęgi liczby 2 (0, 1, 2, 4, 8, 16, 32, 64)

Ten rodzaj estymacji dobrze się sprawdza na wszelkiego rodzaju refinement ach, gdzie cały zespół estymuje zadania. Początki mogą być trudne i estymacje są rozstrzelone, natomiast po czasie zespół się synchronizuje i estymacje są bardziej trafione.

Rzetelne estymacje

Gdy zapytasz kogoś o czas, jaki jest potrzebny na realizację zadania i ta osoba odpowie „Nie wiem”, to w głowie może CI się zapalić lampka ostrzegawcza, pomimo tego drogi czytelniku tylko spokój może nas uratować. Żeby coś wyestymować trzeba najpierw to zrozumieć. W 99% przypadków zadania są niezrozumiałe, ponieważ są źle zdefiniowane, mają niejasne kryteria akceptacyjne lub jest zbyt dużo niewiadomych odnośnie do sposobu realizacji.

Potrzebny jest czas na zdefiniowanie zadania w taki sposób, aby było one zrozumiałe dla całego zespołu, wtedy można jeszcze raz zapytać o estymację.

Czym jest estymacja

Estymacja nie jest obietnicą ani deklaracją co do terminu. Estymacja to rozkład prawdopodobieństwa ukończenia zadania w planowanym czasie. Czasem zdarzy się, że coś będzie szybciej, a coś potrwa dłużej. Dopóki wierzysz w to i widzisz, że estymacje są robione rzetelnie to wszystko jest w porządku.

Estymacja to uczciwy szacunek. Możesz zapytać: „Jaka jest szansa na ukończenie tego zadania w jeden dzień?” Możesz usłyszeć odpowiedź, że niska albo przekładając to na wartość procentową: 5%.

Gdy zapytasz, jaka jest szansa ukończenia zadania w tydzień to zapewne otrzymasz inną odpowiedź, np. 90%.

Podsumowanie

Moim zdaniem oba rodzaje estymacji są zarówno odpowiednie, jak i nieodpowiednie. Dlaczego? Ponieważ wszystko zależy od pracy konkretnych zespołów i kooperacji na linii zespół inżynierski – właściciel produktu (lub project manager). NIE chodzi tutaj o rodzaj estymacji, a o sposób, w jaki jest ona robiona. Jeśli estymacje są rzetelne, to nikt nie będzie płakał nad ich przekroczeniem. W pracy pojawiają się problemy, czasem można coś niedoszacować, natomiast jest to wszystko do przyjęcia, gdy pracujemy rzetelnie i mamy do siebie zaufanie.

Jeśli pracujesz w zespole lub organizacji, która każe Ci się spowiadać z każdej dodatkowej godziny spędzonej nad zadaniem „u szefa na dywaniku” (pomimo tego, że zrobiłeś estymacje rzetelnie i jak najlepiej mogłeś), to zastanów się, czy to jest odpowiednie miejsce dla Ciebie.

Estymuj bez strachu.