„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 pociągnąć na dno zestresowaną studentkę. Wtedy jeszcze, mimo że posiadałam już doświadczenie zawodowe, zarządzanie projektami nie interesowało mnie tak bardzo. Tym bardziej pytanie to mi nie leżało i w sumie nie jestem pewna, jakiej dokładnie udzieliłam na nie odpowiedzi.

Jaka jest zatem różnica między tradycyjnym a zwinnym podejściem do zarządzania projektami? Poniżej odpowiedź – a raczej wprowadzenie do odpowiedzi.

SPIS TREŚCI:

  1. Klasyczne metodyki zarządzania projektami
  2. Agile, czyli metodyki zwinne
  3. Porównanie zwinnych i klasycznych metod wytwarzania oprogramowania
  4. Podsumowanie
  5. Źródła i materiały dodatkowe

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 i różne zespoły. Przedsięwzięcie to ma określony zakres, budżet i czas trwania oraz zdefiniowany cel. W jego rezultacie powinna nastąpić zmiana. Jak już wspomniałam, są różne metodyki zarządzania projektami.

Przeczytaj artykuł Co to jest projekt i dlaczego się nim zarządza żeby dowiedzieć się więcej.

Klasyczne (tradycyjne) zarządzanie projektami

Jako pierwsze omówimy klasyczne zarządzanie projektami, zwane również tradycyjnym, a czasem nawet ciężkim. Opisywane jest najczęściej, choć nie tylko, w modelu kaskadowym. Wyróżnia się również modele spiralne czy przyrostowe. Najważniejszym założeniem w modelu tradycyjnym jest to, że 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. Następnie są analizowane i uszczegóławiane, po czym następuje wykonanie dokładnych specyfikacji (planów) technicznych, a później realizacja. Etapy te są wyraźnie oddzielone i jeden wynika z drugiego. Zazwyczaj w projektach wytwarzania oprogramowania ma zastosowanie model kaskadowy lub model V.

Czasem kaskadowy sposób zarządzania projektami dopuszcza iterację między etapami planowania, realizacji i monitorowania. Oznacza to, że bardzo duży zakres dzielony jest na kilka mniejszych, możliwie odrębnych elementów. Jednak należy pamiętać, że nadal, aż do momentu przejścia do etapu zakończenia, nie mamy działającego produktu.

Etapy projektu

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 zdobycie 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) wymusza pogodzenie interesów i oczekiwań pracowników wielu działów, a więc i konieczność wielu spotkań i ustaleń. Następnie zebrane wymagania należy 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ą na chwilę obecną 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? 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. Ups…. Samo życie.

Wady i zalety klasycznych metodyk zarządzania projektami

Czy zatem tradycyjne zarządzanie projektami jest złe? To nie tak. Jest ono mało elastyczne i mało odporne na zmiany. Wymaga sprawnego zarządzania zmianą i dobrego planowania. Pozwala jednak zapanować nad bardzo złożonymi projektami, w realizacji których bierze wiele osób. Zdecydowanie przeznaczone jest do pracy w środowiskach, w których zmiany zachodzą wolno, ograniczone są regulacjami i procedurami (np. w bankowości czy w sektorze publicznym).

Wybrane klasyczne metodyki zarządzania projektami

  • PRINCE2
  • PMI/PMBOK

Agile, czyli zwinne zarządzanie projektami

Najlepsza wartość biznesowa wyłania się, gdy projekty są powiązane z jasnymi celami biznesowymi, często dostarczają korzyści, a także angażują do współpracy ludzi zmotywowanych i umocowanych. – Filozofia AgilePM

Zwinne zarządzanie projektami to zupełne przeciwieństwo metod tradycyjnych. 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).

Przeczytaj artykuł Wprowadzenie do Agile, żeby dowiedzieć się więcej.

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). Jest on wydawany w częstych, małych iteracjach, w wyniku których powstaje działająca wersja oprogramowania – czyli taka, z której użytkownicy mogą korzystać. Dlatego duży nacisk kładziony jest na testy.

Wady i zalety metodyk zwinnych

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, prawda? Dostajemy, 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, 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” – od skali projektu, ludzi i tego, co chcemy osiągnąć.

Wybrane zwinne metodyki zarządzania projektami

  • AgilePM (DSDM)
  • Prince2Agile
  • SAFe (Scaled Agile Framework)
  • LeSS (Large Scale Scrum)
  • SoS (Scrum of Scrums)

Zobacz „Wprowadzenie do zarządzania. Jak zbudować pierwszy zespół i poprowadzić swój pierwszy projekt. żeby dowiedzieć się więcej.

Porównanie zwinnych i klasycznych metod wytwarzania oprogramowania

zarzadzanie projektami - Zwinne i tradycyjne podejście do zarządzania projektami
Metodyki klasyczneMetodyki zwinne
Oczekiwanie na produktDługi czas oczekiwania na gotowy produkt.Małe iteracje pozwalające szybko uzyskać działający produkt.
Cel i zakresCel projektu jest znany i jasny, a jego zakres dokładnie uszczegółowiony w początkowych fazach projektu.Polecane, gdy cel projektu nie jest do końca zdefiniowany. Kolejne elementy zakresu wybierane są i doszczegóławiane na początku kolejnych iteracji.
Wielkość projektuDuży i bardzo duży.Małe, innowacyjne, dobre dla startupów.
Zaangażowanie biznesuNiezbędne w fazach początkowych (analiza, planowanie) oraz na końcu, przy testach i odbiorze produktu.Reprezentant biznesu bierze czynny udział w pracach zespołu, określając i uszczegóławiając zakres.
Organizacja pracyZespoł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.
ZmianaMał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.
DokumentacjaKażdy etap dokładnie udokumentowany i zatwierdzony.Dokumentacja na minimalnym poziomie niezbędnym do zapewnienia pracy zespołu.
Przykłady metodykPRINCE2®PMI/PMBOK®Agile PMScrum

Podsumowanie

Zarządzanie projektami to dość złożona dziedzina. W ogromnych projektach i firmach bardzo trudno spełnić założenia zwinnych projektów. Natomiast w mniejszej skali 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 błyskawicznie 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 decydują o tym 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 okazuje się, że mniejszym ryzykiem będzie zastosowanie bardziej klasycznych metod. Nie ma jednej słusznej odpowiedzi, zazwyczaj 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. Jak często powtarzam: wszystko zależy od sytuacji.

Koniecznie zobacz też mój wpis „Zarządzanie projektami – wstęp do Agile” i przeczytaj o roli project managera. Odbierz też darmowy e-book „Jak zrobić harmonogram projektu w 7 krokach”.

ŹRÓDŁA I MATERIAŁY DODATKOWE:

  1. Czym jest projekt i dlaczego się nim zarządza
  2. Wprowadzenie do Agile,
  3. Mój cykl o Agile dla Asystentka Level Master
  4. Manifest Agile
  5. Metodyki w zarządzaniu
  6. Kryteria wyboru metod zarządzania projektami
.

Magda Nicgorska – Analityk, Project Manager

Od zawsze pasjonuje mnie ogarnianie, planowanie, zmienianie. Pomagam małym i średnim firmom w prowadzeniu projektów. Organizuję pracę, tworzę harmonogramy i zajmuję się wszystkim tym, na co Ty nie masz czasu, a co jest ważne by zakończyć z powodzeniem Twój projekt!  Zobacz w czym mogę Ci pomóc.