Trzecia kawa Szkolenie Scrum

Szacowania, szacowania…

Rzecz o estymacjach – czyli czym się różni prowadzenie projektu IT
od urządzania kuchni

Kiedyś wydawało mi się, że w pracy informatyka najtrudniejsze jest samo wykonanie pracy – to znaczy projektowanie lub implementowanie jakiejś nowej funkcjonalności. Myliłem się. Bo od wykonania samej pracy dużo trudniejsze jest wcześniejsze oszacowanie jej pracochłonności…

Ale zacznijmy od przykładu z zupełnie innego podwórka:

Chcieliśmy w domu zmienić meble kuchenne. Za pomocą programu do planowania zaprojektowaliśmy układ i wygląd mebli – czyli tak naprawdę określiliśmy nasze wymagania. Dostarczyliśmy te wymagania do kilku wykonawców. Otrzymaliśmy od nich propozycje cenowe. Komisja przetargowa w składzie Żona i Ja wybrała najlepszą ofertę – głównym kryterium była oczywiście cena. Wybrany wykonawca wykonał meble i zainstalował je. Sprawdziliśmy zgodność produktu ze specyfikacją (meble ładne, szafki się otwierają, woda z kranu leci), a następnie wykonawca zainkasował ustaloną kwotę i rozstaliśmy się w obopólnym zadowoleniu.

W procesie urządzania kuchni możliwe jest dokładne zaprojektowanie i oszacowanie kosztu zmian. W projektach informatycznych już nie jest tak prosto, a składa się na to kilka czynników:

  • Brak powtarzalności procesu. Bardzo często systemy IT oraz zmiany w tych systemach są unikalne.

Zarówno kuchnie, jak i ich umeblowanie są bardzo podobne do siebie. W każdej kuchni jest lodówka, kuchenka, zlew, często zmywarka… Meble różnią się kolorem i wzorem, ale mają bardzo podobne rozmiary. A teraz wyobraźmy sobie, że po mając doświadczenie projektowania stu trzydziestu pięciu kuchni musimy nagle zaprojektować łazienkę. Ile będzie kosztował prysznic, sedes, kafelki i podciągnięcie instalacji?

  • Słabo określone wymagania. Zebranie wszystkich wymagań dotyczących zmiany to potężna praca i bardzo powszechne są sytuacje, gdy w ciągu trwania projektu nagle „objawiają się” nowe wymagania wpływające bardzo mocno na jego pracochłonność.

Dobry projekt kuchni precyzuje niemalże wszystkie wymagania na jednej lub kilku kartkach A4 – meble mają być białe, zmywarka wbudowana, blaty a kamienne. A teraz wyobraźmy sobie, że po stworzeniu projektu kuchni okazuje się, że mają być w niej przygotowywane posiłki dla uczniów w szkole, a instalacje w ścianach są poprowadzone zupełnie inaczej niż na rysunkach…

  • Brak znajomości systemu, w którym są wprowadzane zmiany. Ten problem dotyczy głównie pracy w modelu outsourcing’u – ale nie tylko… Żeby wiarygodnie oszacować zmianę trzeba dobrze znać system, w którym mamy wykonać tę zmianę. W praktyce zdarza się tak, że zmiany szacują osoby, które mają tylko powierzchowną znajomość systemu.

Mamy do zaprojektowania kuchnię – ale niestety nie wiemy, jakie są wymiary pomieszczenia. Wiemy, że są jakieś wyprowadzenia instalacji – ale nie wiemy jakie i gdzie. Gdzieś chyba są drzwi i okna – ale nie wiadomo jakie duże. No to ile to będzie kosztowało?

Co można zrobić, żeby poprawić wiarygodność szacowań? W praktyce najczęściej korzysta się z dwóch rzeczy:

  • szacowania wykonywane są przez doświadczonych programistów lub projektantów, którzy korzystają ze swoich wcześniejszych doświadczeń,
  • korzysta się z dekompozycji projektu na podzadania.

Obiecującym pomysłem jest również prowadzenie bazy danych zakończonych projektów (czyli tak naprawdę gromadzenie wiedzy nie w głowach ekspertów, ale w bazie wiedzy) – ale nie spotkałem się jeszcze z praktycznym wykorzystaniem tej idei.

A jakich technik szacowania zmian Ty używasz?

Jeden komentarz

  1. "praktyk/teoretyk" napisał(a):

    Sprawdzona technika szacowania zmiany oprogramowaniu:

    1. Skracasz wymagania do jednego zdania (jeżeli jesteś wstanie, wybierasz to co najistotniejsze, a jeżeli nie to losowo ograniczasz szczegóły).

    2. Idziesz do programisty, który kiedykolwiek modyfikował dany system (nieważne w jakim zakresie) i pytasz ile czasu potrzebowałby na taką zmianę jak w zdaniu przygotowanym w punkcie 1 – otrzymujesz wartość X godzin.

    3. Idziesz do programisty, który nigdy nie miał nic wspólnego z danym systemem i pytasz jego ile mogłaby zająć taka modyfikacja – otrzymujesz wartość Y godzin.

    4. Wyliczasz czas potrzebny na wykonanie zmiany
    T = (8+((X+Y+K)*S*sqrt(E)+D/4))*(2+RND)
    gdzie:
    X wartość z punktu 2
    Y wartość z punktu 3
    K liczba osób w zespole, w którym pracuje programista wykonujący zadanie
    S standardowy mnożnik niedoszacowania programisty (z moich obserwacji wartość około 3,16)
    E ilość środowisk na jakie ma być wdrożona zmiana (np. dev, test, preprod, prod=4)
    D średnia liczba godzin od zakończenia kodowania do uruchomienia zmiany na środowisku produkcyjnym (z każdą godziną wydłuża się czas rozwiązania problemów wykrytych na środowisku produkcyjnym)
    RND – liczba losowa z przedziału od 0 do 1

    Oczywiście wzór proszę traktować z przymrużeniem oka… najistotniejszy element wzoru to składowa RND ;-)

    Szacowanie czasu potrzebnego na wykonanie zmiany to nie tylko kwestia znajomości systemu, ale całej organizacji… im więcej osób bierze udział we wdrożeniu zmiany tym więcej niewiadomych… potrzeba doświadczenia aby pamiętać faktyczny czas realizacji podobnych zmian w przeszłości lub wprawnie szacować wpływ każdej z nich na całkowity czas i koszt.

    W praktyce często okazuje się, że podając mocno losowe (najlepiej lekko zawyżone) oszacowania wcale nie będziemy gorzej estymować niż ktoś, kto próbuje uwzględnić te wszystkie czynniki…

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *