Metodyki projektowe kluczem do sukcesu projektu

Kluczem do skutecznego zarządzania projektami jest dobór odpowiedniej metody projektowej, która pozwoli na zminimalizowanie błędów i realizację wszystkich postawionych celów. Należy pamiętać, że każda metoda ma swoje cechy charakterystyczne, swoje wady i zalety, dlatego ważne jest, aby dopasować ją do realizowanego projektu oraz do zespołu.

Dlaczego wybór metodyki projektowej jest tak ważny? Jaka jest zasadnicza różnica między metodykami zwinnymi a klasycznymi? I jak wybrać tę właściwą? – na te i wiele innych pytań odpowiada Piotr Wyłupek – Ekspert QA / IT.

Diverse CG: Jaka jest kluczowa rola metodyki projektowej i dlaczego jej dobór jest tak ważny?

Piotr Wyłupek: Metodyka projektowa to zespół zasad, którymi kierujemy się podczas prowadzenia projektu. To, w jaki sposób odbywa się praca nad danym projektem, ma kluczowe znaczenie dla jego powodzenia. Projekty potrafią różnić się w sposób diametralny, dlatego tak ważne jest wybranie dla nich odpowiedniego narzędzia.

DCG: Jaka jest zasadnicza różnica pomiędzy metodykami zwinnymi a klasycznymi?  

PW: Kolega kiedyś zażartował, że ilością wytworzonej dokumentacji ;). Nie jest to do końca prawdą, bo przy obu podejściach, jednym z głównych celów może być właśnie wytworzenie porządnej, obszernej dokumentacji (mimo że działające oprogramowanie jest głównym miernikiem sukcesu projektu zwinnego).

Tak naprawdę chodzi tu o możliwość szybszej adaptacji do zmieniających się warunków, która jest niejako wpisana w DNA metodyk AGILE’owych. Sprzyjają temu zwinne cykle wytwórcze, w opozycji do podejścia klasycznego - czyli kaskady, którą można scharakteryzować jako bardziej zależną od wcześniej ustalonego planu. Manifest metodyk zwinnych, który został ogłoszony u zarania tego tysiąclecia, kładł na to szczególny nacisk. Podobnie jak na ludzi i interakcje (w opozycji do procesów i narzędzi) oraz na zgodną współpracę z klientem (ponad negocjację umów).

DCG: W jakich projektach lepiej wykorzystać waterfall, a w jakich Agile?

PW: Metodyki zwinne są naprawdę świetnym rozwiązaniem przy wytwarzaniu i testowaniu oprogramowania, w tradycyjnym sensie. Jednak jak wszystko, mają one swoje ograniczenia.  

Jednym z nich jest dojrzały zespół. I nie chodzi tu o wiek osób uwikłanych w proces, a świadomość, wiedzę i skupienie w dążeniu do celu. Niebagatelną rolę odgrywa też czas – jeśli jest on z góry narzucony w formie nieprzekraczalnej, to głównym narzędziem będzie harmonogram. I tak wędrujemy tutaj po osi, na których krańcach znajduje się z jednej strony coś zakrawającego już na działania operacyjne, a z drugiej prawdziwie unikalny, innowacyjny projekt.

Ogólnie, to wszystko zależy od środowiska, w jakim się znajdujemy. Pomóc odpowiedzieć na to pytanie może model „Cynefin”, gdzie kategoryzujemy, w jakim środowisku się znajdujemy w danej chwili – od prostego, poprzez skomplikowane, złożone, aż do chaosu. I o ile ciężko mówić o metodykach, przy skrajnych wartościach, gdzie raczej reagujemy na ciągle zmieniające się zdarzenia albo prowadzimy tak znane i sprawdzone działania, że przestajemy nazywać je projektami, o tyle decyzję, która metodyka najlepiej się sprawdzi przy danym projekcie, można podjąć bliżej środka wykresu. Oczywiście musimy odpowiednio umiejscowić i skategoryzować nasz projekt i jego środowisko ;).

DCG: Prince2 – jakie są jej wady i zalety? W jakich projektach sprawdzi się najlepiej?

PW: Prince2 powstał pod koniec ubiegłego wieku, w wyniku współpracy z instytucjami rządowymi w Wielkiej Brytanii. Można by pomyśleć, że pasuje tylko do działania z nimi, ale oczywiście jest to tylko wierzchołek góry. W metodyce tej położono szczególny nacisk na ciągłe uzasadnienie biznesowe prowadzonego projektu i jeśli ono znika – to samo powinno stać się z projektem. Jest to sposób myślenia, który jak się przyjrzeć bliżej, powinien przyświecać każdemu projektowi.

PRINCE2 nie określa też jedynie pracy przy jednym projekcie, a ukazuje proces zarządzania w szerszym zakresie strategicznym, gdzie w portfelu może znajdować się kilka projektów, które wewnętrznie mogą opierać się np. na SCRUMie. Im większa skala działania, tym bardziej potrzebne jest narzędzie, którym „ogarniemy” poszerzające się portfolio – jak właśnie PRINCE2 czy SAFE.

Struktura prowadzenia projektu w PRINCE2 oparta jest na etapach, a cała praca prowadzona w projekcie musi być udokumentowana odpowiednimi produktami zarządczymi. I o ile spotkałem się z opiniami, że PRINCE2 może dostarczać równie szybko co np. SCRUM, o tyle należy pamiętać, że „czysty” SCRUM wymaga dostarczenia jedynie działającej inkrementacji produktu, natomiast „czysty” PRINCE2 wymaga dostarczenia całej masy produktów bazowych, zapisów i raportów (jakkolwiek „odchudzone” by nie były) przy kolejnych etapach. Jeśli klient, z którym współpracujemy wymaga dostarczania takich produktów lub jeśli z jakichś względów chcemy, żeby takie produkty powstały, naturalnie wybieramy PRINCE2.

DCG: W jakich projektach najlepiej skorzystać z PMBOK, zbioru zasad stworzonych przez PMI (Project Management Institute)?

PW: W skrócie – w każdych ;).

PMBOK (Project Management Body of Knowledge) to gigantyczny i stale rosnący standard zarządzania projektami. Jest to kompendium wiedzy na temat prowadzenia projektów od branży IT przez budowlaną, na instytucjach rządowych kończąc. Posiadanie wiedzy z zakresu metod, narzędzi czy technik wdrażanych przy różnego rodzaju projektach, pozwala spojrzeć na wyzwania projektowe z szerszej perspektywy.

Zapoznanie się z całością jest to jednak - mówiąc po staropolsku - „overkill”, jeśli projekt, nad którym pracujemy, jest np. małą mobilną aplikacją. W takim wypadku lepszym podejściem byłoby zapoznanie się z jedną z wielu metodyk zwinnych i na niej oprzeć wytworzenie produktu. 

DCG: Kiedy warto skorzystać z techniki Kanban? Wady i zalety?

PW: Kanban jest świetną techniką do obserwowania przepływów prac i znajdywania „wąskich gardeł” ograniczających płynną pracę w projekcie. W swej istocie polega na przesuwaniu zadań w prawo na osi, od „do zrobienia” do „zrobione”, z dostosowanymi do potrzeb projektu etapami. I o ile technika ta powstała przy produkcji samochodów Toyoty, to zaadoptowanie jej do pracy w środowiskach programistycznych nie wymagało w zasadzie żadnych zmian. Doskonale sprawdza się w projektach testowych, gdzie ciężko przewidzieć ilość odnalezionych błędów (i tym samym założyć cel sprintu w SCRUMIE). Wadą, a raczej cechą techniki jest możliwość przesuwania zadania tylko w jednym kierunku, także należy przewidzieć i skonstruować tablicę w taki sposób, aby nie było to konieczne (np. retesty).

DCG: W czym tkwi popularność Scrum? Wady i zalety?

PW: SCRUM oprócz bycia świetnym narzędziem przy typowych projektach IT, jest po prostu łatwy do nauczenia – cały przewodnik po tej metodyce to bodajże około 20 stron tekstu. Inną sprawą jest opanowanie materiału. I zgodnie z zasadą „easy to learn, hard to master”, powstała olbrzymia ilość prac rozwijających zagadnienia działania w tej metodyce.

SCRUM pozwala dostarczać kolejne iteracje działającego produktu (inkrementy) w szybkich (pojęcie względne ;) ) 1-4 tygodniowych cyklach. Kładzie duży nacisk na kontakt z klientem (ProductOwner musi się ciągle zapoznawać ze zdaniem interesariuszy) i na szybką adaptację do zmieniających się warunków - tak, aby cel sprintu cały czas miał sens… można by nawet użyć słów - uzasadnienie biznesowe ;). Cały proces wytwórczy jest bardzo przejrzysty dla wszystkich stron, co buduje zaufanie zarówno w zespole jak i poza nim. Wadami (jeśli można je tak nazwać) są dość duża ilość spotkań (około 20% czasu pracy przy projekcie) i chyba jak w każdej zwinnej metodyce – potrzeba pracy w doświadczonym zespole.

W ostatnich latach SCRUM stał się niejako synonimem metodyki zwinnej. Oczywiście jest on jedną z wielu takich metodyk, ale właśnie dzięki jej popularności powstało to błędne myślenie.

DCG: Rapid Applications Development – na czym polega ta metodyka? Wady I zalety? 

PW: Metodyka zwinna, której celem jest szybkie dostarczanie oprogramowania – w swej istocie zbliżona do takich metodyk jak ExtremeProgramming czy SCRUM (model inkrementacyjny), z którymi może dzielić wiele technik. Właściwie to sama nazwa była/jest myląca, gdyż określa jednocześnie metodykę zwinną i technikę tworzenia oprogramowania, którą można np. wykorzystać w kaskadzie. Jak sama nazwa wskazuje główny nacisk położony jest na gwałtowny rozwój oprogramowania, a robi się to poprzez dostarczanie prototypów (można tu zauważyć podobieństwo do inkrementów w SCRUMie). Praca podzielona jest na cztery fazy – planowania wymagań, projektowania, konstrukcji i przejścia, po których następuje wytworzenie prototypu. Z plusów można oczywiście wymienić skrócenie czasu dostarczenia oprogramowania poprzez zrównoleglone[AP1]  wytwarzanie komponentów, większą interakcję z użytkownikami i tym samym większą satysfakcję klienta. Wadami metodyki są wymaganie posiadania doświadczonego zespołu oraz mniejszy nacisk na wymagania niefunkcjonalne (których użytkownicy często są nieświadomi, do momentu, kiedy te nie zaczną szwankować). Z tych względów nie wskazane jest też wykorzystanie RAD’a przy projektach małych albo wysokiego ryzyka.

DCG: Lean – filozofia pracy gwarantująca produktywność. Kiedy warto ją stosować? Wady i zalety?

PW: Lean management, czyli szczupłe zarządzanie może nie gwarantuje produktywności, bo to zależy od wielu czynników, ale jest na pewno koncepcją, która sprzyja jej zwiększeniu. Zawsze więc warto się z nią zapoznać i ją stosować.

Zasadami Lean jest m.in. określenie wartości dla klienta i budowanie strumieni przepływu w oparciu o jego potrzeby. Widać tutaj podobieństwo i inspiracje dla wspomnianych metodyk projektowych (np. SCRUMa). Bardzo ważnym czynnikiem jest też eliminacja marnotrawstwa (w tym czasu - jak w wykorzystywanej w zwinnych metodykach technice JBGE – „Just Barely Good Enough”). Najważniejszą jednak zasadą LEAN jest wg mnie dążenie do doskonałości, czy to drobnymi krokami (kaizen) czy też dużymi skokami w przyszłość (kaikaku). Jednocześnie należy oczywiście pamiętać o ograniczeniach, przy których dobrze wybrzmiewają słowa T. Roosvelta „rób to, co możesz, tym co posiadasz, tam gdzie się znajdujesz”.

Podsumowując – zawsze warto dążyć do zwiększenia efektywności przy pracy nad projektami, a filozofia LEAN jest do tego idealnym narzędziem.