Magiczny Mnożnik
Jedną z popularniejszych technik stosowaną wciąż przez wielu managerów jest używanie ‘magicznego mnożnika’. Jest to taka liczba, zwykle pomiędzy 1,3-2,6 (czasem nawet więcej), przez którą przezorny kierownik mnoży estymaty dostarczone przez zespół. W ten sposób otrzymuje pewien bufor bezpieczeństwa, chroniący go przed nadmiernym optymizmem developerów. Jeżeli mamy w firmie kilka poziomów zarządzania, to każdy manager zastosuje oczywiście swój własny mnożnik, zwiększając, na wszelki wypadek, czas trwania projektu do kosmicznych rozmiarów. Na końcu, w myśl Prawa Parkinsona, cały zapas i tak zostanie zużyty, a projekt znowu skończy się po terminie. W tej sytuacji przezorny PM zwiększy wartość ‘magicznego mnożnika’ dla przyszłych projektów.
Planując projekt informatyczny szukamy odpowiedzi na pytanie „co i na kiedy jesteśmy w stanie dostarczyć”. W tym celu musimy określić czas potrzebny na wykonanie wszystkich zadań wchodzących w zakres pracy. Jednak już dawno stwierdzono, że szacując ilość pracy w jednostkach kalendarzowych (dni, miesiące itp.) mamy tendencję do podawania zbyt optymistycznych wartości. Tym samym uzyskujemy nierealistyczne plany, a same projekty kończą się po czasie i ze znacznie przekroczonym budżetem.
Szacowanie złożoności
Alternatywną metodą, przynoszącą zdecydowanie lepsze wyniki, jest oszacowanie wpierw złożoności problemu i na podstawie danych historycznych obliczenie czasu potrzebnego na wykonanie projektu. Złożoność możemy liczyć na różne sposoby, od ilości linii kodu (nie zalecane), przez ilość interfejsów, komponentów, czy też operacji na danych (punkty funkcyjne), aż do Story Points, metody najczęściej używanej w projektach Agile.
Story Points
Historyjki Użytkownika (User Stories) możemy estymować przez określenie relatywnej złożoności danego elementu w stosunku do pozostałych. Inaczej mówiąc określamy o ile jedna Historyjka jest większa lub mniejsza od innych. Tym samym właśnie, nie szacujemy wielkości Historyjek w godzinach, dniach czy miesiącach, ale w Punktach (Story Points, SP) nie posiadających żadnej jednostki. Tak więc Historyjka z 2 SP jest po prostu dwa razy większa od Historyjki z 1 SP. Estymata ta nie mówi natomiast nic na temat czasu potrzebnego na dostarczenie Historyjki.
Skala
Łatwo jest rozróżnić między Historyjką, która jest dwa razy większa (2 SP) od trzy razy większej (3 SP), ale w miarę jak przesuwamy się po skali zadanie staje się coraz trudniejsze. Historyjka osiem razy większa (8 SP) jest dość zbliżona do historyjki dziewięciokrotnie większej (9 SP). Dlatego do szacowania Historyjek używa się tylko niektórych liczb. Są to na przykład 1, 2, 4, 8, 16... (skala wykładnicza, popularna pośród praktyków XP) albo 1, 2, 3, 5, 8, 13... (ciąg Fibonacciego popularny w zespołach Scrumowych). Ta druga skala, lekko zmodyfikowana, jest zresztą używana w Pokerze Planującym (Planning Poker), gdzie członkowie zespołu używają kart z liczbami 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 i 100.
Gdy mamy do czynienia ze znaczną ilością Historyjek (od około 20-stu, co ma miejsce w większości projektów) to niestosowanie pełnej skali nie ma większego znaczenia, bo błędy szacowania uśrednią się po całym zakresie prac. Innymi słowy mimo, że część Historyjek nie doszacujemy a część przeszacujemy, to nasze estymaty i tak będą wystarczająco dokładne. Dodatkowo Historyjki z największymi wartościami (20, 40 i 100) będziemy w trakcie trwania projektu rozbijać na mniejsze, uzyskując tym samym dokładniejsze szacunki.
Prędkość i czas trwania projektu
Znając złożoność, czyli sumę Story Points dla wszystkich Historyjek, możemy oszacować czas trwania projektu mnożąc tę wartość przez Prędkość(Velocity), określającą pojemność Sprintu, czyli średnią ilość Story Points, które zespół jest w stanie dostarczyć w trakcie iteracji. Velocity również możemy oszacować, ale dużo lepiej skorzystać z danych historycznych. Przy czym warto tu zwrócić uwagę, że nawet w kompletnie świeżym projekcie, dane historyczne uzyskujemy już po pierwszej iteracji, czyli zwykle po dwóch tygodniach. Po miesiącu albo dwóch dokładność naszych estymat jest zdecydowanie wyższa niż w przypadku tradycyjnych metod planowania.
Szacowanie to zgadywanie
Gdy już dokładnie wiesz ile zajmie Twój projekt, to przypomnij sobie, dlaczego stosujesz zwinne podejście. Dlatego, że wydarzą się rzeczy, których nie przewidziałeś. Klient zmieni zdanie, rozwiązanie okaże się trudniejsze do zaimplementowania i zmieni się otoczenie. Dlatego traktuj wszystkie szacunki z przymrużeniem oka i skup się na wartości dla klienta, nie na czasie trwania i budżecie.
