07.05.2024
6 minut czytania
68 wyświetleń
Metodologie zarządzania projektem
Zastosowanie odpowiedniej metodologii pracy może spotęgować wydajność zespołu i podnieść jakość tworzonego produktu. Sprawdź jakimi cechami wyróżniają się najpopularniejsze z nich i kiedy będą odpowiednim wyborem w twoim projekcie.
Słownik
Zanim przejdę do opisania metodologii zarządzania projektem chciałbym omówić definicję kilku zwrotów związanych z dzisiejszym tematem, a które są ze sobą często mylone. Są to słowa metodologia, metodyka oraz metoda. Ostatnie z nich jest określeniem o dosyć oczywistym znaczeniu, natomiast zwroty metodyka i metodologia mogą wprowadzić w zakłopotanie. Internetowa encyklopedia PWN mówi:
Metodologia – nauka o metodach badań naukowych stosowanych w danej dziedzinie wiedzy
Metodyka – zbiór zasad dotyczących sposobów wykonywania jakiejś pracy
Metoda – świadomie stosowany sposób postępowania mający prowadzić do osiągnięcia zamierzonego celu
Metodyka – zbiór zasad dotyczących sposobów wykonywania jakiejś pracy
Metoda – świadomie stosowany sposób postępowania mający prowadzić do osiągnięcia zamierzonego celu
Powyższe definicje, mimo że są oczywiście poprawne to w odniesieniu do sposobów zarządzania projektem mają nieco inne znaczenie. W obrębie naszego dzisiejszego tematu przyjmuje się poniższe objaśnienia.
Metodologia – zbiór ogólnych założeń wyznaczających kierunek realizacji projektu
Metodyka – zbiór określonych metod pracy stosowanych w trakcie realizacji projektu
Metoda – konkretne rozwiązanie określonego, powtarzalnego problemu
Metodyka – zbiór określonych metod pracy stosowanych w trakcie realizacji projektu
Metoda – konkretne rozwiązanie określonego, powtarzalnego problemu
Metodologie (zwane również filozofiami) w odróżnieniu do metodyk nie wskazują konkretnych rozwiązań, ale określają wartości jakimi należy się kierować dobierając metody działania. Jest to najbardziej znacząca cecha odróżniająca te dwa pojęcia.
Wstęp
Praca w zespole wymaga określenia pewnych norm postępowania i schematów dotyczących osób współpracujących. W zespole programistów równie ważne jak same umiejętności członków zespołu jest to w jaki sposób jest zorganizowana ich praca. Podział obowiązków, przestrzeganie ustalonych norm i trzymanie się wytyczonych ścieżek postępowania pomaga w osiągnięciu określonych celów w zamierzonym terminie unikając dodatkowych, nieprzewidzianych kosztów.
Dobrego programistę, poza bezapelacyjnie niezbędnymi umiejętnościami pisania poprawnego kodu, wyróżnia również zdolność do dopasowania się do wymogów jakie stawia przed nim projekt. Aby usystematyzować, zwiększyć wydajność i uprościć zarządzanie pracą w grupie potrzebne jest zastosowanie konkretnej metodologii dostarczania oprogramowania (ang. software development methodology).
Wraz z rozwojem technologii i zróżnicowaniem problemów jakie niosło za sobą dostarczanie oprogramowania powstawały nowe zasady postępowania w określonych okolicznościach. Z czasem te zasady zaczęto formować w metodologie i rozwijać je, aby realizacja projektów przebiegała jeszcze sprawniej. Specyficzne projekty wymagają od programistów przestrzegania ich, aby zmaksymalizować efektywność pracy jednocześnie minimalizując potencjalne nieoczekiwane konsekwencje pewnych działań. Przedstawię Ci ogólne założenia metodologii, które w ostatnich latach są najczęściej stosowane przez zespoły programistów, aby łatwiej było Ci się odnaleźć w pracy w profesjonalnym środowisku.
Dobrego programistę, poza bezapelacyjnie niezbędnymi umiejętnościami pisania poprawnego kodu, wyróżnia również zdolność do dopasowania się do wymogów jakie stawia przed nim projekt. Aby usystematyzować, zwiększyć wydajność i uprościć zarządzanie pracą w grupie potrzebne jest zastosowanie konkretnej metodologii dostarczania oprogramowania (ang. software development methodology).
Wraz z rozwojem technologii i zróżnicowaniem problemów jakie niosło za sobą dostarczanie oprogramowania powstawały nowe zasady postępowania w określonych okolicznościach. Z czasem te zasady zaczęto formować w metodologie i rozwijać je, aby realizacja projektów przebiegała jeszcze sprawniej. Specyficzne projekty wymagają od programistów przestrzegania ich, aby zmaksymalizować efektywność pracy jednocześnie minimalizując potencjalne nieoczekiwane konsekwencje pewnych działań. Przedstawię Ci ogólne założenia metodologii, które w ostatnich latach są najczęściej stosowane przez zespoły programistów, aby łatwiej było Ci się odnaleźć w pracy w profesjonalnym środowisku.
Agile
Najczęściej stosowaną obecnie filozofią dostarczania oprogramowania jest Agile. Została ona zapoczątkowana przez grupę inżynierów poirytowanych dotychczasowym, kaskadowym podejściem o ściśle planowanych etapach realizacji projektu. Członkowie zgromadzenia wspólnie sporządzili zbiór czterech wartości i dwunastu zasad zwinnego (ang. agile) tworzenia oprogramowania i spisali je w dokumencie zwanym manifestem zwinnego podejścia lub manifestem Agile (ang. Agile Manifesto). Od momentu, w którym pojawił się on w branży, programiści nie musieli już tak bardzo martwić się dokumentacją szczegółowo przygotowaną w pierwszych etapach realizacji projektu – w Agile zeszła ona na boczny tor. Ta filozofia bardzo szybko przypadła do gustu zarówno twórcom jak i odbiorcom systemów informatycznych, a swoją popularność zyskała pod naciskiem potrzeby zmniejszenia wpływu sztywno zaplanowanych działań na produkt końcowy, a zwiększenia wagi bieżących, dynamicznie zmieniających się potrzeb klienta.
Metodologia Agile zachęca do bezpośredniego kontaktu zarówno ze zleceniodawcą jak i pomiędzy członkami zespołu w celu dopasowania usługi do potrzeb biznesowych konsumenta i zwiększenia wydajności pracy. Dostarczenie oprogramowania zgodnie z Agile opiera się na tworzeniu kolejnych funkcjonalności w iteracjach. Oznacza to podzielenie pracy nad kompletnym systemem na pomniejsze części, których realizacja odbywa się w określonym przedziale czasowym. Z założenia każda iteracja powinna być zakończona dostarczeniem sprawnego oprogramowania z dotychczas zaimplementowanymi funkcjami oraz konsultacją z klientem w celu poznania jego opinii na temat dotychczasowych postępów i dokonania ewentualnych korekt.
Twórcy manifestu Agile nie byli w pełni zgodni co do konkretnych rozwiązań, które miałyby stać się panaceum na dotychczasowe problemy związane w wytwarzaniem oprogramowania. Z tego powodu dokument jest zbiorem dość ogólnych reguł, które można interpretować i wdrażać na wiele sposobów. W połączeniu z różnymi wymaganiami konkretnych projektów doprowadziło to do powstania wielu metodyk na bazie metodologii Agile. Do najpopularniejszych z nich należą Scrum oraz Kanban.
Metodologia Agile zachęca do bezpośredniego kontaktu zarówno ze zleceniodawcą jak i pomiędzy członkami zespołu w celu dopasowania usługi do potrzeb biznesowych konsumenta i zwiększenia wydajności pracy. Dostarczenie oprogramowania zgodnie z Agile opiera się na tworzeniu kolejnych funkcjonalności w iteracjach. Oznacza to podzielenie pracy nad kompletnym systemem na pomniejsze części, których realizacja odbywa się w określonym przedziale czasowym. Z założenia każda iteracja powinna być zakończona dostarczeniem sprawnego oprogramowania z dotychczas zaimplementowanymi funkcjami oraz konsultacją z klientem w celu poznania jego opinii na temat dotychczasowych postępów i dokonania ewentualnych korekt.
Twórcy manifestu Agile nie byli w pełni zgodni co do konkretnych rozwiązań, które miałyby stać się panaceum na dotychczasowe problemy związane w wytwarzaniem oprogramowania. Z tego powodu dokument jest zbiorem dość ogólnych reguł, które można interpretować i wdrażać na wiele sposobów. W połączeniu z różnymi wymaganiami konkretnych projektów doprowadziło to do powstania wielu metodyk na bazie metodologii Agile. Do najpopularniejszych z nich należą Scrum oraz Kanban.
Zalety
‣
zredukowane koszty dostarczenia oprogramowania dzięki regularnej kontroli postępów i wysokiej testowalności
‣
możliwość wprowadzenia zmian wstępnych założeń projektu dzięki badaniu opinii klienta po realizacji każdej iteracji
‣
polepszona współpraca zespołu z klientem dzięki regularnym i bezpośrednim spotkaniom
Wady
‣
ograniczona możliwość planowania realizacji projektu z powodu możliwość jego dynamicznych zmian
‣
nieznany czas zakończenia prac nad projektem oraz jego kosztu z powodu pojawiających się, niezaplanowanych wcześniej wymogów klienta
Zastosowania
‣
długoterminowe projekty wymagające dostarczenia sprawnej wersji aplikacji w regularnych, krótkich odstępach czasu
‣
dynamiczne projekty o nieokreślonym celu końcowym
Waterfall
Poprzednikiem filozofii Agile, a zarazem jedną z najstarszych metodologii w branży IT jest wodospad (ang. waterfall). Metodologia ta była bardzo często stosowana w branży budowlanej, skąd została zaczerpnięta przez komputerowców. Z czasem okazało się jednak, że metody wykorzystywane przy budowie wieżowców, nie sprawdzają się tak dobrze przy tworzeniu oprogramowania, szczególnie w przypadku wieloletnich projektów. Z tego powodu w zdecydowanej większości zadań metodologia Waterfall została wyparta przez podejścia zwinne – Agile, jednak wciąż są i takie, przy których może się doskonale sprawdzić.
Metodologia Waterfall jest przeznaczona dla projektów, w których nie przewiduje się żadnych modyfikacji określonego z góry celu, a termin rozpoczęcia i zakończenia planowanych prac jest znany. Filozofia ta opiera się na realizacji zaplanowanych faz projektu w ściśle określonej kolejności. Pracę nad takim projektem można sobie wyobrazić jako wodę spływającą po kolejnych stopniach schodów, gdzie stopniami są następujące po sobie fazy projektu, a wodą aktualny postęp zespołu. Nazwa Waterfall symbolizuje liniowość takiej realizacji – woda dostaję się na kolejny stopień dopiero kiedy pokona poprzedni – jest to tak zwane podejście kaskadowe. Metodologia ta nie przewiduje iteracyjnego podejścia do realizacji celu, natomiast również go nie wyklucza o ile iteracje są ściśle zaplanowane i kontrolowane.
Waterfall stracił zainteresowanie w przypadku współczesnych projektów głównie z powodu odcięcia wpływu klienta na efekt końcowy tuż po fazie planowania. Zleceniodawca nie jest w stanie wprowadzić zmian w oczekiwanym produkcie ani zatwierdzić zastosowanych rozwiązań co przekłada się na jego ewentualne niezadowolenie z wyniku prac.
Metodologia Waterfall jest przeznaczona dla projektów, w których nie przewiduje się żadnych modyfikacji określonego z góry celu, a termin rozpoczęcia i zakończenia planowanych prac jest znany. Filozofia ta opiera się na realizacji zaplanowanych faz projektu w ściśle określonej kolejności. Pracę nad takim projektem można sobie wyobrazić jako wodę spływającą po kolejnych stopniach schodów, gdzie stopniami są następujące po sobie fazy projektu, a wodą aktualny postęp zespołu. Nazwa Waterfall symbolizuje liniowość takiej realizacji – woda dostaję się na kolejny stopień dopiero kiedy pokona poprzedni – jest to tak zwane podejście kaskadowe. Metodologia ta nie przewiduje iteracyjnego podejścia do realizacji celu, natomiast również go nie wyklucza o ile iteracje są ściśle zaplanowane i kontrolowane.
Waterfall stracił zainteresowanie w przypadku współczesnych projektów głównie z powodu odcięcia wpływu klienta na efekt końcowy tuż po fazie planowania. Zleceniodawca nie jest w stanie wprowadzić zmian w oczekiwanym produkcie ani zatwierdzić zastosowanych rozwiązań co przekłada się na jego ewentualne niezadowolenie z wyniku prac.
Zalety
‣
jasno określone cele i terminy realizacji projektu dzięki szczegółowej dokumentacji i dobremu planowaniu
‣
możliwość pełnego zaplanowania potrzebnych zasobów, wykorzystanych narzędzi i kosztorysu dzięki ograniczeniu dynamicznych zmian w projekcie
Wady
‣
brak możliwości wprowadzenia zmian po rozpoczęciu projektu z powodu ścisłego zaplanowania prac
‣
długi czas oczekiwania na pierwsze rezultaty prac z powodu implementacji wszystkich funkcji w tej samej fazie realizacji
Zastosowania
‣
proste aplikacje o jasno określonych wymaganiach i oczekiwaniach użytkowników docelowych
‣
krótkie projekty z możliwością ścisłego zaplanowania poszczególnym etapów prac
RAD
Również jako jedną z pierwszych stosowanych w procesie wytwarzania oprogramowania była metodologia “szybki rozwój aplikacji” (ang. rapid application development – RAD). Różni się ona od poprzednich szczególnie poziomem zaawansowania, ale ma też z nimi kilka cech wspólnych. Pomimo swojego wieku metodologia RAD wciąż jest chętnie stosowana dzięki szybkiemu wprowadzaniu kolejnych prototypów funkcji zgodnych z dynamicznie zmieniającymi się potrzebami klienta.
RAD opiera się na gromadzeniu opinii klienta lub użytkowników końcowych na temat dostarczanych prototypów mających na celu weryfikację ich wymagań. Częsta i jak najszybsza prezentacja nowych prototypów pozwala klientowi na podjęcie decyzji o ewentualnym wprowadzeniu zmian w tworzonym oprogramowaniu – podobnie jak w metodologii Agile najważniejsze jest zadowolenia klienta z zastosowanych rozwiązań. Ostateczny kształt aplikacji tworzonej zgodnie z filozofią RAD nadawany jest w ostatnich fazach realizacji na podstawie zebranych opinii co budzi skojarzenie z metodologią Waterfall.
Podejście RAD wyróżnia nacisk na korzystanie z narzędzi przyspieszających pracę programistów przykładowo przez ograniczenie potrzeby kodowania, zastosowanie gotowych rozwiązań z możliwością ich konfiguracji czy automatyzację niektórych procesów. Głównym założeniem tej filozofii jest jak najszybsze przygotowanie oprogramowania w wersji Beta, która zostanie w pełni zatwierdzona przez klienta, a następnie wdrożona w środowisku produkcyjnym.
RAD opiera się na gromadzeniu opinii klienta lub użytkowników końcowych na temat dostarczanych prototypów mających na celu weryfikację ich wymagań. Częsta i jak najszybsza prezentacja nowych prototypów pozwala klientowi na podjęcie decyzji o ewentualnym wprowadzeniu zmian w tworzonym oprogramowaniu – podobnie jak w metodologii Agile najważniejsze jest zadowolenia klienta z zastosowanych rozwiązań. Ostateczny kształt aplikacji tworzonej zgodnie z filozofią RAD nadawany jest w ostatnich fazach realizacji na podstawie zebranych opinii co budzi skojarzenie z metodologią Waterfall.
Podejście RAD wyróżnia nacisk na korzystanie z narzędzi przyspieszających pracę programistów przykładowo przez ograniczenie potrzeby kodowania, zastosowanie gotowych rozwiązań z możliwością ich konfiguracji czy automatyzację niektórych procesów. Głównym założeniem tej filozofii jest jak najszybsze przygotowanie oprogramowania w wersji Beta, która zostanie w pełni zatwierdzona przez klienta, a następnie wdrożona w środowisku produkcyjnym.
Zalety
‣
szybka prezentacja pierwszych postępów dzięki krótkiemu procesowi planowania i szybkiej realizacji wymogów wstępnych
‣
szybka realizacja kompletnego projektu dzięki zastosowaniu specjalistycznych narzędzi
‣
wysoka wykrywalność błędów dzięki częstym opiniom użytkowników prototypów
‣
pokrycie wszelkich potrzeb klienta dzięki częstej komunikacji z nim i możliwości wprowadzania zmian w projekcie
Wady
‣
potrzeba znajomości specjalistycznych narzędzi do realizacji projektu z powodu stosowania technologii maksymalnie przyspieszających pracę
‣
ograniczona możliwość planowania realizacji projektu z powodu jego dynamicznych zmiany
‣
wymóg dużego doświadczenia i odporności na stres w zespole z powodu wykorzystania zaawansowanych technologii i szybkiego tempa realizacji zadań
Zastosowania
‣
wstępne prototypowanie oczekiwanych funkcjonalności przeznaczonych do późniejszego rozwoju
‣
projekty wymagające szybkiej realizacji niezależnie od kosztów
‣
dynamiczne projekty wymagające częstych modyfikacji ze względu na zmienne oczekiwania względem efektu końcowego
Podsumowanie
Powyższe informacje mają na celu tylko przybliżyć Ci poszczególne sposoby dostarczania oprogramowania, ale z pewnością nie wyczerpują tematu. Niektóre z filozofii są na tyle ogólne, że wręcz niemożliwym jest zastosowanie ich bezpośrednio w projekcie, dlatego na ich podstawie powstały metodyki zgodne z ich założeniami, ale różniące się specyficznymi elementami. Pospolite jest również tworzenie miksów metodologii celem lepszego dopasowania stosowanych metod do założeń projektu i wymogów klienta. Celem takich zabiegów jest zmaksymalizowanie produktywności zespołu i zadowolenia użytkowników docelowych, oraz zminimalizowanie trudności i kosztów związanych z dostarczeniem oprogramowania. Jest to możliwe do osiągnięcia tylko w zespole, który potrafi sprawnie dopasować się do wymogów każdego zadania, a do tego niezbędna jest conajmniej podstawowa wiedza o stosowanych na rynku metodologiach. Teraz już ją masz, ruszaj w świat! 😀
Pytania
Która metodologia ogranicza klientowi możliwość zlecenie zmian w projekcie po rozpoczęciu pracy nad nim?
Jest to metodologia Waterfall. Ze względu na ścisłe zaplanowanie prac nad projektem nie jest możliwe wprowadzenie zmian na życzenie klienta od momentu wykonania analizy wymagań i projektu prac.
Ile iteracji przewiduje się w trakcie realizacji projektu zgodnie z metodologią Agile?
Metodologia Agile nie przewiduje żadnego limitu iteracji. Ich ilość, tak jak i czas trwania, jest zależna od potrzeb klienta i możliwości zespołu realizującego projekt.
Czy metodologia RAD jest możliwa do wdrożenia w każdym zespole?
Nie. RAD wymaga wykwalifikowanego zespołu zdolnego do pracy z zaawansowanymi narzędziami co znacząco ogranicza możliwość jego zastosowania.
Znalazłeś błąd lub masz pomysł na ulepszenie powyższej treści?
Dodaj opinię
Spodobał Ci się ten artykuł? Będę wdzięczny, jeżeli dasz o nim znać znajomym na swoim portalu społecznościowym.