Każda osoba, która miała okazję pracować przy projektach programistycznych, na pewno spotkała się z problem szacowania czasu wykonywania. Zwykle jest to jedna z pierwszych rzeczy o które pyta Nas klient, kierownik, czy nawet my sami musimy sobie zadać pytanie za nim zaczniemy coś robić - Ile czasu będzie na to potrzebne?
Większość z Nas szczególnie, ta mniej doświadczona zwykle bardzo nie lubi dokonywać oszacowania. Nic dziwnego skoro często zadania to przypomina chodzenie po omacku. Dlatego postaram się tutaj jak najszerzej omówić dostępne metody i narzędzia.
Zacznę od kwestii o których powinniśmy pamiętać wykonując wszelkie oszacowania, później przejdę do sposobów na szacowanie całych projektów, w części trzeciej opiszę metody szacowania czasu trwania poszczególnych zadań, a na koniec wspomnę trochę o dostępnych narzędziach.
Zaczynamy – czyli jak zabierać się do szacowania czasu?
Oszacowanie czasu trwania całego projektu, to zadanie naprawdę trudne. Szczególnie na początku projektu w fazie przygotowawczej, kiedy tak na prawdę nie do końca wiemy jeszcze co trzeba w projekcie zrobić. Ale za nim powiem, jak można sobie pomóc, to ustalmy z czego powinno się składać takie formalne oszacowanie.
1. Założenia
Każde oszacowanie projektu powinno mieć pokrótce opisane założenia, dla których zostało dokonane. Czyli jakie rzeczy zostały uwzględnione, a co nawet ważniejsze, czego ewentualnie nie uwzględniono. Jakie było zakładane rozwiązanie i jakie zaplanowano zasoby. Generalnie wszystkie czynniki, które mogą znacząco wpłynąć na czas trwania projektu.
2. Odchylenie , czyli dokładność oszacowania.
Powinniśmy sobie zdawać sprawę w jakim stopniu dokładny jest prognozowany czas. Czasem mamy naprawdę dużą pewność (np. robiliśmy już podobne projekty) i możemy sobie założyć, że oszacowanie może mieć odchylenie rzędu 10 – 20%. Czasem jednak trafiamy do dzikiej nieznanej krainy i nasze szacunki mogą być naprawdę bardzo orientacyjne. W takim przypadku odchylenie, może sięgać do np. 100% czasu trwania. Jeśli chodzi o wyznaczanie wielkości odchylenia to osobiście przyjmuje pięciostopniową skalę (jak w większości ciężko mierzalnych metryk, taka ilość daje sporą elastyczność, a nie powoduje jeszcze bałaganu).
- Bardzo Niskie 0 – 10%
- Niskie 10 – 20%
- Średnie 20-40%
- Wysokie 40 – 70%
- Bardzo Wysokie 70%+
Warto zwrócić uwagę, że w tym przypadku im większy poziom odchylenia, tym szerszy jego przedział.
3. Czas ważności Oszacowania
Zaleca się też, choć wszystko zależy od przeznaczenia oszacowania, aby określić jego czas ważności. Tzn na przykład, że oszacowanie aktualne jest do końca Marca. (bo wtedy będziemy mieli więcej szczegółów) Zabezpiecza Nas to na wypadek, gdyby ktoś później wyciągał nam takie archiwalne oszacowanie i dochodził jego wyegzekwowania.
Osobiście, niestety raczej rzadko zdarza mi się określać czas ważności oszacowania. Wykonywane oszacowania zwykle są po prostu aktualizowane w ramach napływających danych, czy wykonywania prac, występowania problemów itd.
4. Nakład pracy, a czas trwania
Bardzo ważna rzecz, której trzeba mieć świadomość, jak również zaznaczyć w opisie oszacowania. Pojęcia ‘nakładu pracy’ i ‘czasu trwania’ są często stosowane zamiennie, co jest wielkim nieporozumieniem i trzeba je twardo rozgraniczyć.
Nakład pracy, opisuje szacunek ile godzin roboczych należy poświęcić na zrealizowanie projektu/zadania. Zaś Czas trwania, musi do nakładu pracy doliczyć takie kwestie jak dostępność zasobów, dni wolne, realizację innych projektów i zobowiązań itp.
Koniecznie należy zaznaczyć w oszacowaniu, którą z tych wartości prognozujemy. Inaczej nieraz spotkałem się z nieporozumieniami. Programista mówi, że wykonanie jakieś funkcjonalności to 3 dni roboty, a klient rozumie, że za 3 dni otrzyma gotowe rozwiązanie.
Podsumowanie
Stosowanie wszystkich tutaj wymienionych elementów oczywiście nie jest konieczne. Ale często zabezpiecza nad przed mogącymi wystąpić problemami. W kolejnej części opiszę zasady szacowania całych projektów, a później przejdę do szacowania zadań.
