Organizacja
Standish Group co roku publikuje swój sławny raport zatytułowany Chaos Report. Raport ten zawiera wyniki badań dotyczących jakości projektów informatycznych. Od kilkunastu lat Standish Group zadaje organizacjom te same pytania dotyczące liczby projektów kończących się sukcesem. Porównanie tych liczb na przestrzeni lat jest ciekawe przede wszystkim dla kierowników projektów, ale nie tylko.
Niedawno przeczytałem nie sam raport, ale wnioski z raportu za 2011 rok zaprezentowane przez Johna Parkera na blogu w artykule
Why so Many IT Projects are Challenged, Under Deliver Promised Value, or Outright Fail.
Autor zamieścił tam następującą tabelkę:
Jest to porównanie liczby projektów zakończonych sukcesem (które zmieściły się w budżecie i harmonogramie i dostarczyły zamawiającemu oczekiwaną wartość), liczby projektów, które się zakończyły, ale nie zmieściły się w zaplanowanym budżecie, bądź były opóźnione lub też miały ograniczony zakres w stosunku do pierwotnych założeń oraz liczby projektów, które zostały zakończone porażką.
Z przedstawionych liczb widać, że na przestrzeni kilkunastu lat nastąpiła nieznaczna poprawa, ale mimo wszystko liczba projektów zakończonych pełnym sukcesem jest bardzo mała.
Najbardziej rzuca się w oczy jednak porównanie liczby projektów zakończonych sukcesem realizowanych według standardowej metody Waterfall -
14%, do liczby projektów zakończonych sukcesem prowadzonych według metodyk zwinnych, Agile -
42%. Różnica jest na tyle diametralna, że w samym opracowaniu raportu zamieszczono komentarz:
“The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.”
Przyznam, że nie zdawałem sobie sprawy z takiej przewagi podejścia Agile nad standardowym cyklem wytwarzania oprogramowania. Ciekawy jestem, czy firmy realizujące projekty informatyczne w ślad za tym opracowaniem w przyszłości będą stawiały jeszcze bardziej na metodyki zwinne.
W każdym bądź razie Standish Group dostarczył znaczących argumentów za tym kierunkiem rozwoju.
A dlaczego Agile miałoby być lekarstwem dla zarządzania wymaganiami?
Otóż, wg Standish Group trzy najważniejsze powody, dla których projekty nie kończą się pełnym sukcesem to:
- Lack of user input
- Incomplete requirements and specifications
- Changing requirements and specifications.
Wszystkie te czynniki są rezultatem niedostatecznej analizy biznesowej. Można wysnuć wniosek, że standardowe podejście, w którym pierwszą fazą projektu jest analiza kończąca się zatwierdzeniem specyfikacji wymagań - jest błędne.
Ja nie spotkałem się jeszcze z projektem, w którym czas przeznaczony na analizę byłby wystarczający lub wyniki fazy analizy byłyby kompletne i zawierałyby dokładnie opisane wszystkie wymagania. Niby zakłada się, że wymagania mogą podlegać zmianom w późniejszych fazach projektu, przy czym istnieje świadomość, że im późniejsza zmiana wymagań, tym koszt jest większy. Ale najczęściej mimo wysiłku całego zespołu projektowego liczba zmian przekracza punkt krytyczny, po którym okazuje się, że sukces projektu jest zagrożony.
Czy zatem stosowanie podejścia Agile do zarządzania wymaganiami i prowadzenia całego projektu może kluczem do sukcesu? Wiele na to wskazuje. Choć w moim odczuciu potrzeba jeszcze wiele czasu, żeby się o tym przekonać na własnej skórze. Sądzę, że potrzebujemy jeszcze więcej opracowań na temat metodyk zwinnych oraz przekonania do nich organizacji i ludzi, którzy od lat realizują projekty zgodnie ze starymi i sprawdzonymi metodami.
