W poprzednim wpisie omówiliśmy czym jest projekt i dlaczego się nim zarządza. Wiemy, że jest to złożone przedsięwzięcie, w którym zazwyczaj bierze udział wiele osób, różne zespoły. 

#zarzadzanieprojektami

#projekt 

#projectmanagement

#podstawy 

Przedsięwzięcie to ma określony zakres, budżet i czas trwania oraz zdefiniowany cel. W jego rezultacie powinna nastąpić zmiana. Jak wspomniałam, są różne metodyki zarządzania projektami, które wymuszają stosowanie określonych metod.

 Zanim jednak omówimy poszczególne metodyki, spójrzmy na istotny ich podział.

Zwinne i tradycyjne podejście do zarządzania projektami

„Omów różnicę między zwinnymi i klasycznymi sposobami wytwarzania oprogramowania” – takie pytanie otrzymałam na obronie pracy magisterskiej. Z pozoru banalne, jednak po dłuższym zastanowieniu to temat rzeka, który może posłać na dno zestresowaną studentkę. Wtedy jeszcze, mimo że posiadałam już doświadczenie zawodowe, aspekty zarządzania projektami zupełnie mnie nie interesowały. Wolałam być trybikiem projektu, a nie tym, który trybikami kieruje. Tym bardziej pytanie to mi nie leżało i w sumie nie jestem pewna, jakiej dokładnie udzieliłam na nie odpowiedzi. Chyba poszło nie najgorszej, bo zdałam na 5 😊 Z tego miejsca pozdrawiam dr AS, który zadał mi to pytanie! Jaka jest zatem różnica między tradycyjnym a zwinnym podejściem do zarządzania projektami? Poniżej odpowiedź w odniesieniu do projektów wytwarzania oprogramowania. 

Klasyczne metodyki

Klasyczne podejście  do zarządzania projektami (zwane też tradycyjnym czy nawet ciężkim) opisywane jest najczęściej (choć nie tylko) w modelu kaskadowym (wyróżnia się również modele spiralne czy przyrostowe). W modelu tradycyjnym każdy kolejny etap występuje po poprzednim (dopuszczalne są iteracje wybranych etapów, jednak istotne jest to, że rozpoczęcie kolejnego etapu nie może nastąpić przed zakończeniem poprzedniego.

Przy bardzo złożonych projektach poszczególne etapy trwają bardzo długo (czasami wiele miesięcy) i muszą być dokładnie udokumentowane. Metody klasyczne mają dobrze zdefiniowane dokumenty powstające w czasie poszczególnych etapów projektu, odpowiednie procedury oraz całe procesy zarządzania poszczególnymi aspektami projektu (np. ryzykiem).

Cały zakres projektu oraz jego wszystkie wymagania ustalane są na samym początku. Potem są analizowane i uszczegóławiane, po czym następuje wykonanie szczegółowych specyfikacji (planów) technicznych, a potem realizacja. Etapy te są wyraźnie oddzielone i jeden wynika z drugiego. W projektach wytwarzania programowania zazwyczaj w tej sytuacji ma zastosowanie kaskadowy model wytwarzania oprogramowania lub model V).

Czasem kaskadowy sposób zarządzania projektami dopuszcza iterację między etapami planowania, realizacji i monitorowania. Czyli bardzo duży zakres dzielony jest na kilka mniejszych. Możliwie odrębnych elementów. Nadal jednak do momentu przejścia do etapu zakończenia nie mamy działającego produktu. 

Jak działają klasyczne metodyki?

Wyobraźmy sobie sytuację, w której bank postanawia wymienić przestarzałe oprogramowanie. Obecne oprogramowanie jest mało optymalne, bardzo wolne a dodatkowo nie jest przystosowane do obecnych standardów bankowości elektronicznej oferowanych przez konkurencję. Ponadto wszelkie zmiany w nim są czasochłonne i kosztowne.

Celem projektu (w dużym uproszczeniu) jest więc optymalizacja ponoszonych kosztów poprzez przyspieszenie obsługi klienta oraz uzyskanie nowych klientów dzięki nowoczesnej platformie bankowości elektronicznej.

Podjęto więc decyzję o zastąpieniu obecnego oprogramowania nowym. Zainicjowano projekt, zabezpieczono na jego potrzeby ludzi oraz fundusze, rozpoczęto planowanie, określono zakres. Zbieranie wymagań (na poziomie biznesowym), wymaga pogodzenia interesów i oczekiwań pracowników wielu działów, wymagało więc wielu ustaleń i spotkań. Następnie zebrane wymagania należało zamienić na projekt systemu.

Tym sposobem upłynęło kilka dobrych miesięcy, wiele osób przepracowało wiele godzin jednak owoce ich pracy istnieją, póki co wyłącznie w postaci dokumentacji. Kolejne kilka miesięcy zajmie wyprodukowanie systemu, jego przetestowanie oraz poprawa ewentualnych błędów.

Co się okazuje w czasie testów? Że system jest nawet fajny, działa całkiem sprawnie, ale w międzyczasie zmieniły się przepisy (a to się w Polsce zdarza niebywale często) i system wymaga „kilku” zmian. Upssss…. Samo życie.

Czy zatem klasyczny sposób zarządzania projektem jest zły? To nie tak. Jest on mało elastyczny i mało odporny na zmiany. Wymaga sprawnego zarządzania zmianą i dobrego planowania. Pozwala jednak zapanować nad bardzo złożonymi projektami, w których realizacji bierze wiele osób. Zdecydowanie przeznaczony jest do pracy w środowiskach, w których zmiany zachodzą wolno, określane są regulacjami i procedurami (np. w bankowości czy w sektorze public).

Metodyki zwinne

Metodyki zwinne zarządzania projektami to zupełne przeciwieństwo. Są zdecydowanie bardziej dynamiczne i odporne na zmiany. Skupiają się na dostarczaniu produktu (oprogramowania) w małych iteracjach, których zakres planowany jest przed ich rozpoczęciem, a nie z góry dla całego projektu. Oczywiście zakres jako taki znany jest przed rozpoczęciem prac, jednak jego uszczegóławianie następuje w miarę postępu. W zwinnym podejściu odchodzi się też od ton wywarzanej dokumentacji (tona to nie tylko metafora, wiele projektów, mimo że mamy XXI wiek wymaga fizycznego wydrukowania powstającej dokumentacji).

W metodykach zwinnych nacisk kładziony jest na dokumentowanie wyłącznie niezbędnych rzeczy, bliskiej współpracy między osobami określającymi zakres a wytwarzającymi produkt (programistami). Produkt wydawany jest w częstych, małych iteracjach, w wyniku których powstaje działająca wersja oprogramowania. Działająca, czyli taka, z której użytkownicy mogą korzystać, dlatego duży nacisk kładziony jest na testy.

Kluczowym czynnikiem powodzenia w tak prowadzonym projekcie jest zaangażowanie zespołu, w tym, a może nawet przede wszystkim biznesu, czyli ludzi odpowiedzialnych za wyznaczanie kolejnych elementów zakresu i jego uszczegółowienie.

Świetne prawna? Dostajemy to, co chcemy i dostajemy to szybko. W takim razie chcemy to! Ano też nie do końca. Łatwo zatracić się w chęci ciągłego ulepszania, łatwo odpłynąć od pierwotnych założeń i przekroczyć budżet czas i zakres.

Zwinne metodyki wymagają ludzi umiejących pracować w mocno zmiennym środowisku w zespołach, których istotą jest samoorganizacja. Taki sposób pracy jest trudny dla ludzi przyzwyczajonych do pracy zgodnej z procedurami z jasną listą zadań, jakie powinni wykonać. Dodatkowo w wielu firmach konieczność oddelegowania kluczowych pracowników do projektu sprawia spory problem organizacyjny a co za tym idzie pracownicy ci nie mają wystarczająco dużo czasu, by odpowiednio zaangażować się w prace projektowe.

Jeśli zwinne metodyki mają tyle wad, to po co o nich w ogóle rozmawiamy? Ponieważ, jak to w życiu bywa „to zależy”. Zależy od skali projektu, ludzi i tego, co chcemy osiągnąć. 

Porównanie zwinnych i klasycznych metod wytwarzania oprogramowania

 

Metodyki klasyczne Metodyki zwinne

Oczekiwanie na produkt

 

Długi czas oczekiwania na gotowy produkt Małe iteracje pozwalające szybko uzyskać działający produkt

Cel i zakres

 

Cel projektu jest jasny, znany a jego zakres dokładnie uszczegółowiony w początkowych fazach projektu Cel projektu nie jest do końca zdefiniowany. Kolejne elementy zakresu wybierane są i doszczegóławiane na początku kolejnych iteracji.

Wielkość projektu

 

Duży i bardzo duży. Małe, innowacyjne, dobre dla startupów.

Zaangażowanie biznesu

 

Niezbędne w fazach początkowych (analiza, planowanie) oraz na końcu przy testach i odbiorze produktu. Czynny udział w pracach zespołu. Reprezentant biznesu bierze czynny udział w pracach zespołu określając i uszczegóławiając zakres.

Organizacja pracy

 

Zespoły biorące udział w poszczególnych etapach są rozłączne. Istotą metodyk zwinnych jest bliska praca zespołów wytwórczych i biznesu, dlatego biznes jest członkiem zespołu. Wymagane jest duże zaangażowanie przez cały czas trwania projektu.

Zmiana

 

Mało odporne na zmiany zakresu i budżetu. Wymaga procedur zarządzania zmianą.

Odporne na zmianę.

Polega na bieżącym reagowaniu na zmiany. Przed każdą kolejną iteracją zakres jest rewidowany.

Dokumentacja

 

Każdy etap dokładnie udokumentowany i zatwierdzony. Dokumentacja na minimalnym poziomie niezbędnym do zapewnienia pracy zespołu.
Przykłady metodyk

PRINCE2®

PMI/PMBOK®.

 

Agile PM

Scrum

 

 

Podsumowanie

W ogromnych projektach w ogromnych firmach bardzo trudno spełnić założenia zwinnych projektów. W mniejszej skali natomiast albo w projektach innowacyjnych (np. w startupach) jest to świetny model, zwłaszcza dla wytwarzania oprogramowania. Pozwala szybko osiągnąć efekt, który można przedstawić klientom, sponsorom czy inwestorom. W szybko zmieniającym się świecie pozwala szybko reagować na zmiany.

Z drugiej zaś strony są pewne branże, gdzie zwinne metody zupełnie nie mają sensu. Jakoś trudno mi sobie wyobrazić budowę autostrady w iteracjach w myśl metodyk zwinnych. Przecież sytuacja, w której w każdej iteracji przebieg drogi byłby aktualizowany jest co najmniej abstrakcyjna 😊

Wyboru odpowiedniej dla naszego projektu metodyki należy dokonywać wyjątkowo rozważnie. Często wymusza ją życie (a raczej kontrakt między klientem i dostawcą). Czasem wymuszają ją przepisy prawa, które nakładają np. wymóg ogromu dokumentacji.

Pamiętać należy, że niezależnie od motywów podjęcia danej decyzji zdeterminuje ona nasz sposób pracy przez najbliższe miesiące. Choć wizja szybkiego otrzymania pierwszych rezultatów jest niezwykle kusząca czasem okaże się, że mniejszym ryzykiem będzie zastosowanie bardziej klasycznych metod. Nie ma jednej słusznej odpowiedzi, zawsze w końcu padnie „to zależy”.

Zawsze można np. do zarządzania całością złożonego projektu wykorzystywać metodyki klasyczne, ale już w poszczególnych etapach pracować zgodnie z metodykami zwinnymi. Wszystko zależy od sytuacji.

Żródła:

Pozdrawiam, Ruda 🙂

Pin It on Pinterest