Uruchomienie dowolnego projektu informatycznego wymaga estymacji podstawowych parametrów tego projektu. Proces estymacji obejmuje cztery etapy: estymację czasu dostarczenia produktu, estymację nakładów pracy, estymację rozmiaru tworzonego oprogramowania oraz  kosztu jego wyprodukowania.

Na poziomie oceny wartości wpływów oraz wydatków pieniężnych związanych z realizacją
i eksploatacją projektu, najczęściej stosuje się metodę IRR (ang. Internal Rate of Return,
tj. wewnętrzna stopa zwrotu) oraz NPV (ang. net present value, tj. wartość bieżąca netto).

Obliczenie wartości IRR opiera się na na stopie procentowej (dyskontowej) przy uwzględnieniu zmiany wartości pieniądza w czasie, ryzyka oraz inflacji. Polega na znalezieniu wartości stopy dyskontowej r, która spełnia warunek:

 

1

IRR pokazuje bezpośrednio stopę rentowności badanych przedsięwzięć. Gdy wewnętrzna stopa zwrotu jest wyższa od stopy granicznej, najniższej możliwej do zaakceptowania przez inwestora, mówimy wówczas o inwestycji opłacalnej.

NPV to wartość obecna przyszłych przepływów pieniężnych – czyli najprościej mówiąc,  jakiej wielkości przepływów pieniężnych możemy się spodziewać w przeliczeniu na dzisiejszą wartość pieniądza.

2

IRR i NPV to dwie najczęściej stosowane dynamiczne metody oceny opłacalności projektów.
Oprócz nich mamy jeszcze chociażby:

  • PI (Profitability Index) – rentowność inwestycji, wyrażona ilorazem sumy zdyskontowanych dodatnich przepływów pieniężnych do sumy zdyskontowanych ujemnych przepływów pieniężnych.

3

Gdy wskaźnik rentowności PI > 1 wówczas projekt wstępnie zostaje przyjęty do realizacji.

 

  • DPP (Discounted Payback Period) – zdyskontowany okres zwrotu nakładów inwestycyjnych.

Wskazuje on po jakim czasie zwróci się dana inwestycja w opraciu o przepływ pieniężny netto,
a nie zysk netto jako miernik korzyści netto. Uwzględnia zmianę pieniądza w czasie.

Payback Period = 1/stopa zwrotu = nakłady inwestycyjne/ (zysk netto+amortyzacja)

  • ROI (Return on Investment) – zwrot z inwestycji liczony według wzoru:

ROI = (zysk netto/suma kosztów inwestycji) * 100%

TCO (Total Cost of Ownership) – całkowity koszt rozwiązania informatycznego począwszy od jego zakupu, poprzez użytkowanie, aż do likwidacji.

Ocenę opłacalności projektu, jego rentowność czy stopę zwrotu zostawmy jednak managerom.

Z perspektywy zespołu developerskiego wytwarzającego oprogramowanie, zwłaszcza przy zastosowaniu metodyk agile, dużo ciekawsze wydaje mi się zastosowanie innej prostej matematyki do prognozowania postępu prac i możliwych efektów w iteracji.

Prosta matematyka w projektach scrumowych

Burndown Chart/Burnup Chart

Więcej: http://www.agilenutshell.com/burndown

Stosowane w zwinnych metodykach wykresy spalania, dosłownie pokazują, jak „robota pali nam się w rękach”. Pozwalają śledzić i prognozować postępy prac. Dostarczają zespołowi scrumowemu informacji na temat ilości pracy do wykonania przed końcem sprintu lub ilości wykonanych już zadań w trakcie sprintu (w zależności od obranego sposobu graficznego przedstawienia postępu prac). Tworzone są na bazie Rejestru Sprintu (Sprint Backlog), zawierającego informacje o szacowanej ilości pracy w całym sprincie.

4

5

Wykres Spalania zawiera zaplanowaną pracę (Estimated Velocity) oraz długość sprintu ujętą
w dniach. Pokazuje, ile pozostało pracy do ukończenia wszystkich elementów Sprint Backlogu (Burndown Chart) lub w przypadku Wzrastających Wykresów Spalania (Burnup Chart), jaki jest przyrost wykonanych zadań.

Wykres Spalania aktualizowany jest po każdym Daily Scrum. Trend linii spalania powinien przebiegać zgodnie z linią idealnego spalania (linie idealnego spalania pokazują powyższe wykresy i są wyliczone automatycznie). W przeciwnym wypadku nie wystarczy nam czasu na dostarczenie wszystkich zadań zaplanowanych w Sprincie lub przeciwnie – nie doszacowaliśmy „mocy przerobowych” zespołu.

Niezależnie od sposobu przedstawienia, celem dążeń zespołu developerskiego jest osiągnięcie stanu „zero zadań do wykonania” najpóźniej w ostatnim dniu bieżącego sprintu.

W dłuższej perspektywnie może być dobrym materiałem analitycznym przy planowaniu kolejnych sprintów lub kolejnych wydań produktu.

 

Velocity, Capacity i Focus Factor

Więcej:

https://www.scrumalliance.org/community/articles/2014/february/velocity

http://agilecoffee.com/capacity-planning-worksheet-for-scrum-teams/

 

Czy przystępując do prac nad wytwarzaniem oprogramowania możemy prognozować rezultaty prac zespołu?

Każdy rodzaj planowania potrzebuje zasadniczo trzech parametrów: prędkości pracy zespołu (Velocity), czasu trwania iteracji oraz listy oszacowanych i sprioretyzowanych zadań.

Velocity to ilość pracy, jaką zespół wykonuje w trakcie iteacji. Rośnie zwykle w miarę adaptacji metodyki Scrum w zespole, a większy zakres dostepnych danych historycznych, pozwala nam lepiej określić jej wartość. Przy wyznaczaniu prędkości zespołu istnieje duża zasadnosć stosowania wartości uśrednionej przy jednoczesnym odrzuceniu wartości skrajnych.

Szacowanie i estymowanie  zadań w agile najczęściej odbywa się przy zastosowaniu metody Planning Poker. Zespół developerski szacuje historyjki użytkownika (User Stories), wykorzystując w tym celu karty z określonymi wartościami. Wartości te to nic innego, jak określony rekurencyjnie ciąg liczbowy Fibonacciego, który jest zbiorem liczb naturalnych, w których kolejny wyraz jest sumą dwóch poprzednich (Ciąg Fibonacciego to ciąg liczb: F0 = 0, F1 = 1, Fn = Fn-1  + Fn−2,   dla n ≥ 2).

Capacity to „pojemność zespołu” przez którą rozumie się ilość czasu, jaką mają do dyspozycji członkowie zespołu na wykonanie zadań iteracji.  Wbrew pozorom przy ośmiogodzinnym dniu pracy, nigdy nie bedzie to osiem godzin. Maksymalna wartość współczynnika skupienia (focus factor) wynosi według W. Edwarda Deminga 80%.

W metodyce Scrum uwzględnić musimy także czas poświęcany na spotkania zespołu oraz niezależnie od metodyki – czas na przełączanie się między zadaniami (tzw. multitasking).

Współczynnik Focus Factor wyliczamy w oparciu o prosty wzór: Focus factor = Velocity / Capacity.

Przyjmijmy zatem, że mamy 8 osobowy zespół, w którym każdy pracuje przez 5 dni w tygodniu (iteracja tygodniowa). Velocity zespołu wynosi 28. Focus Factor w tym wypadku wynosi:
28 / (8 * 5) = 0,7.

Na tej podstawie w prosty sposób jesteśmy w stanie zrobić prognozę dla przyszłej iteracji.

Z ośmioosobowego zespołu, dwie osoby bedą przebywaly w najbliższym czasie na urlopie. Ile zatem story points jesteśmy w stanie dostarczyć?

Forecast = Focus factor x Capacity = 0,7 x 6 osób x 5 dni = 21 story points

Brak danych historycznych, zwłaszcza na poczatku projektu, może utrudniać obliczenie focus factor. Jednym ze sposobów poradzenia sobie z tym problemem jest zastosowanie stałej wartości współczynnika w kilku pierwszych iteracjach i na tej podstawie przeanalizowanie faktycznych możliwości zespołu.

Na podstawie wielu obserwacji zespołów agile Mike Cohn zaproponowal następujące mnożniki:

6

Jeśli zespół osiągnął w 3 iteracji 24 story points, wówczas prognoza dla następnej itracji prezentuje się następująco:

Low Multiplier = 0,85 x 24= 20,4

High Multiplier =1,15 x 24= 27,6

Prognoza dla 4 iteracji = (20,4+27,6) / 2 = 24

Dobre narzędzia i wskaźniki projektowe są istotnym elementem na drodze do sukcesu projektu. Umiejętne posługiwanie się nimi umożliwia trafną diagnozę i adaptację Development Teamu do zmian zachodzących w projekcie. Na wczesnym etapie pozwalają ocenić zasadność biznesową planowanego przedsięwzięcia. Wspierają optymalizację procesów oraz sprzyjają samoorganizacji zespołu.

Artykuł autorstwa Joanny Sitkowskiej.