Dla osób znających choć trochę podejścia zwinne (ang. Agile) w zarządzaniu projektami już tytuł tego tekstu musi wzbudzić z jednej strony niepokój, z drugiej zaś ciekawość. Z pewnością bowiem zastanawiacie się: czy możliwe jest takie połączenie: „zwinna”, w domyśle lekka jak piórko, modyfikowalna i „metodyka”, w domyśle ciężka, z licznymi procedurami i dokumentami?

„Begin at the beginning” – jak mawiała Królowa w „Alicji w krainie czarów”. Więc i ja zacznę od początku. Zwinne podejścia w zarządzaniu projektami najczęściej utożsamiane są z podejściem SCRUM, czyli sposobem pracy niedużego (5-7 osób), samoorganizującego się (czyli nie kierowanego przez Project Managera) zespołu programistycznego, realizującego nieduży (pod względem budżetu i liczby zaangażowanych interesariuszy), trwający często tylko klika (1-3) miesięcy projekt. W takich warunkach SCRUM i podobne podejścia sprawdzają się znakomicie. Tylko czy można zastosować tego typu podejście, gdy projekt dotyczy złożonego problemu biznesowego (np. system leasingowy dostawcy aut, lub system klasy ERP), trwa nie 1-3 miesiące, lecz dłużej, obejmuje wiele kluczowych i wzajemnie powiązanych wymagań i funkcjonalności, a ponadto wymaga akceptacji zarządu, budżetu i oczywiście nadzoru ze strony kadry zarządzającej i obejmuje dużą część naszej firmy, a więc i znaczną liczbę interesariuszy?

Odpowiedź jest oczywista: podejścia w stylu SCRUMa nie pomogą nam w sytuacji, gdy zajmujemy się pełnym cyklem realizacji (dostarczania) projektu, od jego inicjowania, do produkcyjnego użytkowania.

Konieczne jest uzupełnienie zwinnego wytwarzania oprogramowania (gdzie zastosowanie znajduje właśnie SCRUM) o takie elementy, jak choćby: uzasadnienie biznesowe, nadzór strategiczny nad projektem (ang. governance) i zapewnienie możliwości zwinnej pracy dużych, zlokalizowanych w różnych miejscach zespołów.

W tych bardziej złożonych sytuacjach projektowych konieczna jest więc metodyka zwinnego zarządzania projektami. Metodyka, którą oczywiście można dopasować do konkretnej organizacji i konkretnego projektu. Jedną z takich zwinnych metodyk jest Agile Project Management (Agile PM), oparta o metodykę DSDM^® Atern^®, opracowaną przez DSDM Consortium (http://www.dsdm.org) już w 1995 roku!

Sam zajmuję się zarządzaniem projektami od wielu, wielu lat, łącząc w swojej praktyce kierownika projektu (dawniej) i doradczej (obecnie) elementy różnych podejść i różne techniki, zarówno te bardziej tradycyjne, jak i te bardziej zwinne. W początku 2013 zdobyłem certyfikat Agile Project Management Practitioner, związany ze znajomością metodyki Agile Project Management. Ponieważ sądzę, że metodyka Agile PM to bardzo interesująca propozycja dla wszystkich kierowników projektów (i nie tylko) zajmujących się złożonymi projektami w dużych i średnich organizacjach, to w tym tekście przedstawię jej podstawowe założenia i najistotniejsze elementy.

Zacznę od struktury metodyki Agile PM. Obejmuje ona następujące elementy:

• Filozofia: każdy projekt musi być powiązany z precyzyjnie zdefiniowanymi celami strategicznymi firmy i powinien koncentrować się na dostarczeniu rzeczywistych korzyści dla biznesu
• Pryncypia: 8 następujących zasad:

1. Orientacja na potrzebie  biznesowej
2. Dostarczenie „na czas”
3. Współpraca strony biznesowej i realizacyjnej
4. Jakość nie podlega kompromisom
5. Inkrementalne (przyrostowe) tworzenie rozwiązania na mocnej podstawie
6. Iteracyjne tworzenie produktu
7. Ciągła i precyzyjna komunikacja
8. Demonstrowanie kontroli nad projektem

• Cykl życia projektu, czyli procesy realizowane w ramach tego cyklu oraz związane z nimi produkty
• Role i odpowiedzialności uczestników projektu, czyli aspekt ludzki
• Stosowane techniki, zwane także praktykami.

Filozofia i pryncypia to jakby „filozoficzna” i teoretyczna podstawa metodyki. Bardzo mocno trzymają się one filozofii metod zwinnych, dodatkowo akcentując kwestie potrzeb i korzyści  biznesowych, mocno podkreślanych także w tradycyjnym zarządzaniu projektami.

Główna różnica na poziomie filozofii podejścia metodyki Agile PM dotyczy parametrów (nazywanych w metodyce: zmiennymi) projektu. Agile PM przyjmuje bowiem, że zmiennym parametrem w projekcie jest zakres, czyli funkcjonalności rozwiązania, natomiast stałymi, niezmiennymi w trakcie projektu parametrami są: czas, koszt i jakość. Oznacza to w praktyce, że jedynym buforem w projekcie jest właśnie zakres. Klient na pewno otrzyma produkt, rozwiązanie w terminie, w budżecie, o przyjętej jakości. I wydawać by się mogło (na podstawie wcześniejszego zdania), że nie wie on tylko co (czyli jakie funkcjonalności) otrzyma.

Napisałem celowo „wydawać by się mogło”, gdyż tak naprawdę klient wie, co dostanie i co może dostać. Pomocna jest tu jedna z technik metodyki Agile PM, tj. priorytetyzacja MoSCow (Must Have, Should Have, Could Have, Won’t have this time) dotycząca wymagań klienta, a więc i funkcjonalności. Zgodnie z metodyką Agile PM klient na pewno (gwarancja!) dostanie wymagania zdefiniowane jako „Must Have”, czyli tzw. minimalny zestaw użytkowy (Minimum Usable Subset – w terminologii metodyki), a więc te najważniejsze wymagania/funkcjonalności, które zadecydowały o podjęciu projektu. Ponadto ma duże szanse otrzymać  także wymagania typu „Should Have”, a gdy wszystko pójdzie dobrze, także wymagania „Could Have”. W tym momencie spytacie: a jak to jest możliwe?  Odpowiedź związana jest z pewnym trikiem metodyki:  otóż nakazuje ona, by wymagania „Must Have” nie obejmowały więcej niż 60% pracochłonności projektu, a wymagania „Should Have” i „Could Have” stanowiły po około 20% pracochłonności projektu. Dzięki takiemu podejściu możemy gwarantować dostarczenie wymagań „Must Have” w określonym czasie, gdyż pozostałe dwa typy wymagań stanowią swego rodzaju bufor w projekcie.

Takie odejście bardzo mi się podoba, uważam je za kluczowy element powodzenia projektu w praktyce. Oczywiście w praktyce może nie być łatwe przekonanie klienta do takiego właśnie podejścia.

Druga rzecz, która także bardzo mi się podoba w Agile PM i która także decyduje o jej przydatności w dużych projektach, w średnich i dużych organizacjach jest zdefiniowany w niej cykl życia projektu. Cykl życia projektu obejmuje bowiem cały cykl dostarczania (ang. delivery) projektu, a nie tylko prace programistyczne/wytwórcze oprogramowania i zawiera następujące fazy:

1. Pre-Project: formalizacja propozycji projektu, umieszczonej w kontekście innych projektów i prac planowanych do realizacji lub aktualnie realizowanych w firmie
2. Feasibility (Studium wykonalności):  pierwsza ocena, czy projekt jest istotny z punktu widzenia biznesowego i możliwy do realizacji z technicznego punktu widzenia, a także określenie ram czasowych i kosztowych projektu oraz organizacji i nadzoru nad projektem
3. Foundation: finalne, choć nadal bardzo zgrubne, a jednocześnie zwinne ze swej natury planowanie projektu, w ramach którego określane są m.in.:
   
   • Wymagania (na wysokim poziomie), z podziałem na wymagania typu: Must Have, Should Have, Could Have, Won’t Have
   • Szczegółowy business case projektu
   • Ramowy harmonogram na poziomie wydań (ang. release) oraz ryzyka projektu
   • Organizacja i nadzór (ang. governance) nad projektem
4. Exploration: realizacja koncentrująca się na wymaganiach funkcjonalnych – stworzenie w iteracjach (nazywanych w metodyce time-boxami) wstępnego rozwiązania, sfinalizowanego w następnej fazie
5. Engineering: druga część realizacji rozwiązania, koncentrująca się na wymaganiach nie funkcjonalnych i umożliwiająca osiągnięcie przez rozwiązanie pełnej gotowości operacyjnej
6. Deployment: wdrożenie i uruchomienie przygotowanego rozwiązania
7. Post-Project: ocena i analiza projektu pod kątem rzeczywiście osiągniętych wartości biznesowych.

Dzięki w/w fazom mamy więc pełny cykl realizacji projektu, od jego inicjowania, poprzez planowanie, realizację rozwiązania, do uruchomienia i analizy projektu, a nie tylko prace programistyczne, jak to jest w SCRUM-ie. Cały projekt jest w tym podejściu podzielony na inkrementy (czyli wydania), a każdy z tych inkrementów na iteracje (nazywane time-boxami), gdzie ostatnia iteracja dotyczy uruchomienia rozwiązania (deployment). Dzięki temu kierownictwo może nadzorować projekt i zapewnić jego zgodność ze strategią, kierownik projektu ma narzędzia do zaplanowania projektu i „panowania” nad jego realizacją, a agile-owy, samo-organizujący się zespół może wytwarzać rozwiązanie.

To teraz: co mi się w metodyce Agile PM nie podoba. Nie podobają mi się produkty proponowane przez metodykę: jest ich  za dużo, są za detaliczne i już na pierwszy rzut oka niezbyt praktyczne. Lecz nie jest to duży problem. Wystarczy zrobić, tak, jak zrobiłem ostatnio przygotowując wraz z klientem spory projekt biznesowo-informatyczny. Wystarczy bowiem zamapować produkty metodyki Agile PM na produkty znane w firmie klienta z bardziej tradycyjnego zarządzania projektami (np. karta projektu, plan projektu, koncepcja rozwiązania, itp.) oraz „odchudzić” niektóre z nich (czyli dokumenty proponowane przez Agile PM). I już mamy i podejście Agile-owe i zbiór produktów zarządczych, bardzo praktycznych, bardzo potrzebnych do zarządzania projektem na poziomie strategicznym (Sponsor), jak i  na poziomie kierownika projektu.

Ponadto w metodyce znajdziecie opis ról projektowych, będący rozszerzeniem ról znanych choćby ze SCRUM-a, a także zestaw technik agile-owych, jak: wspomniana wcześniej priorytetyzacja MoSCoW, iteracyjne tworzenie rozwiązania, modelowanie, czy time-boxing.

Metodyka Agile PM, to - jak mawia jeden z moich znajomych i z czym się w pełni zgadzam - „Agile w krawacie”. To nie tylko ogólna filozofia podejścia, czy zbiór wskazówek i praktyk jak SCRUM, lecz prawdziwa, pragmatyczna metodyka, jaką chciałby stosować każdy doświadczony kierownik projektów w odniesieniu do nietrywialnych, złożonych projektów biznesowo-informatycznych.