Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

W praktyce zarządzanie projektem, kiedy zakres i wymagania nie są w pełni określone, wymaga podejścia elastycznego i zdolności do szybkiego reagowania na zmiany. Tradycyjne metody, takie jak PRINCE2, model V czy model kaskadowy, zawsze zakładają większy nacisk na planowanie upfront, czyli na początku projektu, gdzie cały zakres (lub jego większość) jest ustalany przed rozpoczęciem realizacji. Model kaskadowy bywa stosowany głównie w środowiskach, gdzie produkty są powtarzalne i łatwe do przewidzenia – tutaj zmiany w wymaganiach są prawie niemożliwe do wprowadzenia bez cofnięcia się do wcześniejszych etapów. Model V, często stosowany w testowaniu oprogramowania czy inżynierii systemów, również zakłada ścisłe powiązanie etapów rozwoju i testowania; bardzo trudno tu o zmianę wymagań w trakcie, bo każda poprawka oznacza powrót przez wiele faz. PRINCE2 co prawda na papierze jest elastyczny, ale w praktyce lepiej sprawdza się, gdy mamy jasno zdefiniowany projekt i dużo formalności – jego framework przewiduje „kontrolowane” zmiany, ale to nie to samo, co adaptacja w locie, jaką daje Agile. Moim zdaniem problem polega na tym, że wybór tych klasycznych podejść wynika często z przyzwyczajenia do sztywnego planowania i przeświadczenia, że lepsza dokumentacja rozwiąże wszystkie niespodzianki. Tymczasem w środowiskach, gdzie klient nagle zmienia zdanie albo pojawiają się nowe potrzeby, takie metody zawodzą, bo są zbyt oporne na zmiany. Warto pamiętać, że Agile nie jest panaceum na wszystkie projekty, ale właśnie przy niejasnych wymaganiach i bardzo zmiennych warunkach rynkowych jego iteracyjność i stały kontakt z klientem pozwalają uniknąć wielu typowych pułapek planowania z góry.