AgilePM - podejście zwinne, ale łączące w sobie cechy metodyk kaskadowych, np. choćby Prince (mamy nawet nowe podejście - Prince2 Agile). Co to takiego?
Metodyka jest tworem DSDM Consortium, które opracowało The DSDM Agile Project Framework (ang. DSDM - Dynamic Systems Development Method), oparte na podejściu otwartym na zmiany i potrzeby klienta. Co prawda DSDM działa od dosyć dawna, ale dopiero poprzez AgilePM zyskało na popularności.
Wspomniałem, że podejście łączy cechy metodyk kaskadowych (głównie pod względem jasno zdefiniowanych ról), ale promuje głównie tzw. EDUF (ang. Enough Design Up Front) w przeciwieństwie do Prince2 (BDUF - Big Design Up Front). W tym zarządzaniu projektami istotny jest intensywny udział biznesu w procesie tworzenia rozwiązania, nierzadko jest to specjalnie delegowana osoba do takiej pracy. Uczestniczy ona czynnie w procesie wytwórczym. Z jednej strony ułatwia to szybsze podejmowanie decyzji, z drugiej zaś jest to alokacja dodatkowego zasobu. AgilePM jest jednak dosyć dobrze skalowalny w zależności od sytuacji i złożoności projektu. Cel przewodni to spełnienie potrzeby biznesowej, ograniczenie przerostu formalności (chociaż jej poziom nie pozwala na zbyt dużą improwizację) i dostarczenie w terminie. Tutaj fajnie różnice w podejściach prezentuje obrazek:
W przeciwieństwie do tradycyjnych technik czas i koszty projektu są stałe. Natomiast możemy delikatnie żaglować ostatecznymi cechami otrzymanego produktu.
Główne pryncypia AgilePM to:
- Koncentruj się na potrzebie biznesowej
- Dostarczaj na czas
- Współpracuj
- Nigdy nie idź na kompromis w kwestii jakości (to mi się podoba :) )
- Buduj przyrostowo w oparciu o solidne podstawy
- Rozwijaj iteracyjnie
- Komunikuj się ciągle i jasno
- Demonstruj kontrolę (brzmi dziwnie, ale ogólnie chodzi o odpowiedni nadzór nad dostarczaniem produktów i jasność planów i postępów widoczna dla wszystkich członków zespołu. Tutaj duży wysiłek należy do kierownika projektu)
Zespół deweloperski ma dużą i istotną rolę oraz sporą swobodę działania. Priorytety ustalane za pomocą MoSCoW, są definiowane dla danej sesji analitycznej w ramach Timebox (tak jak Sprint w Scrum). Praca dzielona jest na poszczególne Timeboxy (określane przez kierownika), które składają się na przyrosty i w rezultacie dopełniają projekt. Okienka ustalane są w miarę możliwości w ten sposób by rezultat był możliwy do pokazania klientowi. To dobre podejście, niwelujemy błędy w definiowaniu wymagań. Codzienne krótkie zbiórki organizowane w celu podsumowania statusu jasno pokazują w którym miejscu znajduje się projekt. Zespół projektowy kształtuje się następująco:
Jest to podział jasny i dobrze zdefiniowany, ułatwiający współprace. Jak widać na rysunku pojawia się rola facylitatora, otóż warsztaty facylitowane są również istotnym elementem metodyki. Są to uporządkowane spotkania w grupie pod przewodnictwem niezależnego facylitatora, mające na celu elastyczną i swobodną pracę nad określonym problemem oraz poprawę komunikacji. Jedną z metod podejmowania decyzji może stanowić planning poker. Ogólnie pomysł warsztatów w takiej formie bardzo mi się podoba i wiem, że rzeczywiście przynosi oczekiwane rezultaty.
AgilePM jest podejściem ciekawym i wartym poznania. Daje dużo do prowadzenia szybkich projektów i często jest skuteczniejszy od tradycyjnych metod. Sporo zależy od organizacji i zespołu, nie zawsze jednak to będzie dobre rozwiązanie.
Jeżeli chodzi o szkolenia to mamy standardowo AgilePM Foundation i AgilePM Praktitioner. To pierwsze warto zrobić, trwa dwa dni i kończy się względnie łatwym egzaminem certyfikującym. Dużym plusem jest spora ilość ćwiczeń interaktywnych i gra Agile Warrior (w przypadku firmy szkoleniowej Inprogress), która pozwala w ciekawy sposób wcielić się w zespół projektowy i dostarcza mnóstwo zabawy :)
AgilePM jest ciekawy i szczerze polecam poznać go bliżej, a czy poniższe równanie jest prawdziwe odpowiedzcie sami :)
