|

Troy Magennis: używanie danych do szybkiego prognozowanie i podejmowanie decyzji w Agile

Take away z prognozowanie i podejmowanie decyzji w Agile.

  1. Nie ma jednego wyniku prognozy.
  2. Obniżenie czasu dostarczenia o 20% zwiększa przepustowość systemu aż o 33%.
  3. Przez większość czasu realizacji zadania nikt aktywnie nad nim nie pracuje.

Prognoza odpowiada na pytania dotyczące zdarzeń, które jeszcze nie miały miejsca. Dlatego tak trudno opowiedzieć na kiedy będzie to dostarczone? Z pewnością pytanie ile osób potrzebujemy w zespole czy ile to będzie kosztować lub jaki jest koszt opóźnienia.

Przede wszystkim trzeba pamiętać, że nie ma jednego wyniku prognozy. Zawsze będzie kilka możliwych wyników, niektóre bardziej prawdopodobne od innych.

Cycle Time

Cycle Time

Praca nad skróceniem Cycle Time ma bardzo realne uzasadnienie. Obniżenie czasu dostarczenia o 20% zwiększa przepustowość systemu aż o 33%. Przede wszystkim każde skrócenie Cycle Time ma przełożenie na cash flow projektu (zmniejsza się koszt developmentu + wcześniej zaczynamy zarabiać).

W trakcie powstawania oprogramowania przez większość czasu zadanie znajduje się w stanie oczekiwania – nikt realnie nad nim nie pracuje. W związku z tym sprawdź, jak to wygląda w Twoim projekcie. Troy obserwuje, że aktywna praca nad zadaniem to tylko 15% czasu jego faktycznej realizacji.

Prognozowanie projektu czy funkcjonalności to praca z dużą ilością niepewności. Jakie były dotychczasowe dane, jaki zespół będzie pracować, jak bardzo zmieni się zakres rzeczy do zrobienia. Tak na prawdę, to nawet powinien się zmienić z uwagi na zmienność otoczenia biznesowego).

Użycie średniej wartości Cycle Time daje tylko 50% prawdopodobieństwa co przy pracy nad projektami nie jest wartością wystarczającą. Użycie modelu Monte Carlo pozwala na zwiększenie tego prawdopodobieństwa do wystarczająco dobrego poziomu. Przyjmuje się 85% prawdopodobieństwo za właściwy poziom pewności).

Prognozowanie i biznes

Kolejnym krokiem w podejmowaniu decyzji powinna być spojrzenie na biznesowy wpływ prognozy.  Dla danego prawdopodobieństwa mamy określoną datę dostarczenia rozwiązania. Możemy do tego dodać koszt dewelopmentu i koszt opóźnienia. Cost of Dely – ile $ zarobimy lub nie stracimy po wdrożeniu danego rozwiązania. Pozwala to zobaczyć biznesowe konsekwencje różnych scenariuszy i podejmować na tej podstawie racjonalne decyzje. Przykładowo zwiększając siłę zespołu deweloperskiego zwiększają się jego koszty, ale równocześnie zmniejsza się koszt opóźnienia. W związku z tym pytaniem, które trzeba zadać jest co daje większe korzyści biznesowe?

Koszt opóźnienia (Cost of Delay) jest dobrą miarą do ustalania kolejności pracy nad funkcjonalnościami lub projektami. (teraz ptrzeczytaj też dlaczego tak nie jest). Chcemy zmaksymalizować cash flow i zminimalizować ryzyko. Koszt opóźnienia składa się z przychodów z funkcjonalności (nowych lub brak ich utraty) oraz kosztów wytwarzania (koszt zespołu i wszelkiego rodzaju opłaty). To na co trzeba zwrócić uwagę – bardzo często jest to pomijane – to zależności pomiędzy funkcjonalnościami. Powoduje to, że funkcjonalność A wpływa na koszt opóźnienia funkcjonalności B.

Przeczytaj również notatkę z podobnego wystąpienia Troya Magennisa w która uzupełni Twoją wiedzę z tego wykładu.

Źródło oryginalnej prezentacji znajdziesz tutaj.

Podobne wpisy