Adaptacyjne zarządzanie projektami: Różnice pomiędzy wersjami
m (Infobox update) |
|||
Linia 127: | Linia 127: | ||
* [[Back office]] | * [[Back office]] | ||
* [[Backlog sprintu]] | * [[Backlog sprintu]] | ||
* [[Modern agile]] | |||
==Bibliografia== | ==Bibliografia== |
Wersja z 07:26, 21 maj 2020
Adaptacyjne zarządzanie projektami |
---|
Polecane artykuły |
Adaptacyjne zarządzanie projektami (ang. Agile Project Management) to podejście wykorzystujące zbiór różnych metodyk, określanych jako zwinne, lekkie lub elastyczne (ang. Agile Methodologies) oraz narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami.
Adaptacyjne zarządzanie projektami charakteryzuje się stałą współpracą z klientem, dlatego też ramy projektu nie są ściśle określone, a sam projekt podzielony jest na mniejsze części tzw. funkcjonalności (iteracje). Zespoły Agile dodatkowo często dokonują zmian i korekt w nawiązaniu do wymogów i oceny klienta, uwagę skupiając głównie na pracy nad powierzonym zadaniem.
Szybkie dostosowanie się i otwartość na zmiany w projekcie jest podstawą metodologii Agile. Nie wyróżnia się oddzielnie wyodrębnionej fazy projektowania jak w tradycyjnym zarządzaniu projektami. [Kozłowski R., (2010), s.18-20]
Dynamiczne otoczenie jak i zmieniające się wymagania klienta wymagają krótkoterminowego planowania i zaangażowania całego zespołu projektowego od którego oczekiwane jest duże zdyscyplinowanie i umiejętność współdziałania, z powodu braku jednoznacznego określenia struktury organizacyjnej. Kierownik projektu zaś pełni rolę mentora. Zespoły są ograniczone jedynie do kilku-kilkunastu osób i ich charakterystycznymi cechami są elastyczność, duży poziom kooperacji oraz znaczna efektywność.
Indywidualizm to kolejny aspekt wyróżniający się w metodach zwinnych. Odchodzi się w tym przypadku od standaryzacji. Cechą charakterystyczną adaptacyjnego zarządzania projektami jest stanowcze zmniejszenie ilości dokumentów. Metody Agile zapewniają gamę technik, dzięki którym możliwe jest zaczęcie realizacji projektu bez pewności wykonania założonych celów. Proponują również metody uporządkowania zadań w projekcie, aby zagwarantować że zespół będzie realizował odpowiednie czynności, bez znajomości całego zakresu projektu.
Metody oferowane w ramach adaptacyjnego zarządzania projektami nie są adekwatne do wszystkich rodzajów projektów, szczególnie takich które są bardzo duże i rozbudowane oraz niezbędne są spore wydatki technologiczne. Metody Agile nie nadają się również w zagmatwanych projektach, gdzie ciężko klientowi jest zrozumieć jak będzie wyglądał efekt końcowy.
Agile Project Management jest głównie stosowany w realizacji projektów bardzo innowacyjnych i z dużą dawką niepewności np. informatycznych m.in. w zakresie inżynierii oprogramowania. [Lachiewicz S., Matejuna M., (red) (2007), s. 148, 151][Chrapko M., (2012), s. 26 – 27]
Manifest Agile
Manifest Agile, a dokładniej Manifest Zwinnego Tworzenia Oprogramowania (ang. Manifesto for Agile Software Development) to dokument, który ukazał się w 2001 roku w ośrodku wypoczynkowym Snowbird w USA i zapoczątkował dynamiczny rozwój adaptacyjnego zarządzania projektami.
Manifest Agile spowodował głębokie przemiany w środowiskach programistycznych, a następnie przeniknął w niektóre obszary zarządzania projektami. Powstanie Agile Project Management było w dużej mierze reakcją na mało elastyczne metody zarządzania projektami informatycznymi, które uważano wówczas za zbyt sformalizowane i mało efektywne.
Cele i zasady
Główne cele i zasady, jakie spełniają zwinne metodyki zostały spisane we wspomnianym już wyżej, dokumencie Agile Manifesto.
Poniżej kompilacja głównych celów i zasad przyświecająca stosowaniu zwinnych metodyk w ramach zarządzania projektami:
- elastyczność i adaptacyjność projektowania względem dynamicznie zmieniających się potrzeb i oczekiwań klienta (stąd termin zwinne - ang. agile),
- tworzenie wartościowych i innowacyjnych rozwiązań zarówno dla firmy jak i konsumentów na każdym etapie projektowania,
- minimalizacja kosztów m.in. dzięki skróceniu harmonogramów procesu wytwarzania,
- koncentracja na członkach zespołu projektowego, wzrost motywacji wśród pracowników i bezstresowa realizacja projektów,
- ścisła współpraca z klientem - preferowany jest kontakt bezpośredni,
- prostota i samoorganizujące się zespoły,
- satysfakcja klientów dzięki szybkiemu i regularnemu dostarczaniu wartościowego produktu,
- minimalizacja ryzyka.[Manifesto for Agile Software Development]
Rola zespołu w projektowaniu zwinnym
- Członkowie zespołu projektowego realizują wiele funkcji. Nie jest zachowana żadna struktura organizacyjna, zespół sam sobą zarządza
- Członkowie zespołu są odpowiedzialni za problemy, które są do rozwiązania we wszystkich funkcjonalnościach
- Każdy członek zespołu podejmuje decyzję w jaki sposób zrealizuje wyznaczone przed nim zadania
- Kluczowym wyzwaniem jest ograniczenie do miniumum tworzenie dokumentacji i rozwijanie bezpośredniej wymiany informacji między uczestnikami zespołu. Gdy członkowie projektu pracują z innych lokalizacji, wykorzystuje się regularne formy komunikacji wykorzystujące przystępne różne formy komunikatorów, głównie narzędzi internetowych
[Grucza B, Ćwik K., (red.) (2013), s. 103]
Porównanie adaptacyjnego i tradycyjnego zarządzania projektami
Poniżej zostały przedstawione różnice występujące między adaptacyjnym a tradycyjnym zarządzeniem projektami.
Tabela 1 Porównanie adaptacyjnego i tradycyjnego zarządzania projektami [Highsmith J. (2004)]
Adaptacyjne | Tradycyjne |
Zorientowanie na dostarczanie funkcjonalności | Zorientowanie na podział zadań |
Plany są hipotezą, nie przewidywaniem | Plany są przewidywaniem odnośnie przyszłości |
Sukces rozumiany jako zdolność adaptacji do zmieniających się warunków w projekcie | Sukces rozumiany jako zgodność z wcześniej założonym planem |
Duża precyzja planu dla wczesnych iteracji, bardzo zgrubny charakter planu w dalszej fazie projektu | Szczegółowy plan opracowany jest dla całego projektu |
Przyczyny odchyleń od planu są analizowane i dostarczają informacji do zmiany planu kolejnych faz projektu (adaptive action) | Odchylenia od planu są traktowane jako błędy zarządzania i wymagają bezkrytycznej poprawy (corrective action) |
Zarządzanie zmianą jest motorem dla procesów innowacyjnych | Zarządzanie zmianą często degeneruje się do biurokratycznych procedur blokujących zmianę |
Zorientowane na stworzenie samoorganizującego się, samodyscyplinującego się zespołu projektowego | Zorientowane na procedury i techniki kontroli oraz mikrozarządzanie zadaniami projektowymi |
Mocne i słabe strony adaptacyjnego zarządzania projektami
- Adaptacyjne zarządzanie projektami pomimo niesprecyzowania sposobu osiągnięcia celu projektu, cały czas ściśle współpracuje z klientem, przykłada wagę dla jego wysokiego poziomu zadowolenia i skupia się na zapewnieniu mu jak największych korzyści biznesowych.
- Łatwość dostosowania się i szybkie dokonywanie zmian w projekcie. Dzięki dużej elastyczności wzrastają szansę sfinalizowania projektu z powodzeniem.
- W przeciwieństwie do tradycyjnego zarządzania projektami nie ma potrzeby określania pełnego zakresu zadań w okresie początkowym projektu
- Wzrasta poziom samodzielności członków projektu, którzy biorą odpowiedzialność za wykonywane zadania.
- Słabe strony: Należy wziąć pod uwagę, że adaptacyjne zarządzanie projektami posiada również słabe strony.
- Większe projekty cały czas realizowane są przy użyciu tradycyjnych modeli zarządzania projektami, ponieważ elastyczność umiejętność dostosowania się do zmian nie jest wymagana, a warunki realizacji projektu nie są aż tak zmienne
- Brak koncentracji na kontroli realizacji zadań
- Zespół projektowy musi posiadać duże doświadczenie, wysokie umiejętności oraz wysoki poziom motywacji, co często jest ciężkie do osiągnięcia
- Sprawdza się tylko w małych zespołach
- Cała uwaga zespołu projektowego skupiona jest na realizacji końcowego efektu, ignorowane są inne wymiary projektu takie jak badania rynkowe, wybór odpowiednich członków zespołu i odpowiednie przeszkolenie go, zarządzanie ryzykiem, aspekty prawne i formalne i inne które realizowane są w tradycyjnej metodologii.
[Kozłowski R., (2010), s.18-20][Grucza B, Ćwik K., (red.) (2013), s.100-107]
Metody zaliczane do nurtu Agile
- Metodyka SCRUM (K. Schwaber i J. Sutherland),
- Crystal Clear (A. Cockburn),
- Metodyka Extreme Programming (K. Beck, W. Cunningham i M. Fowler),
- Adaptive Software Development (J. Highsmith),
- Dynamic Systems Development Method,
- Feature-Driven Development,
- Behaviour Driven Development/Acceptance Driven Development
- Lean Software Development (E. Ries),
- Kanban (D. Anderson).
Zobacz także:
- Metodyka MSF
- Programowanie
- Scrum of scrums
- Testy akceptacyjne odbiorcze
- Business Process Modeling Notation
- Back office
- Backlog sprintu
- Modern agile
Bibliografia
- Chrapko M., (2012), Scrum. O zwinnym zarządzaniu projektami, Wydawnictwo HELION
- Conforto E., (2014), Can Agile Project Management Be Adopted by Industries Other than Software Development?, Project Management Journal, Vol. 45, Nr 3
- Grucza B, Ćwik K., (red.) (2013), Zarządzanie projektami - studia przypadków, Oficyna a Wolters Kluwer business, Warszawa
- Highsmith J. (2004), Agile Project Management – Creating Innovative Products, Addison – Wesley, Boston
- Hoda R. (2016), Multi-level agile project management challenges: A self-organizing team perspective, Journal of Systems and Software, Vol. 117, Nr 3
- Kozłowski R., (2010), Wykorzystanie zaawansowanych technologii w zarządzaniu projektami, Wydawnictwo Uniwersytetu Łódzkiego, Łódź
- Lachiewicz S., Matejuna M., (red) (2007), Problemy współczesnej praktyki zarządzania. Tom I, Łódź
- Manifesto for Agile Software Development, http://agilemanifesto.org/
- Serrador P., (2015), Does Agile work? — A quantitative analysis of agile project success, International Journal of Project Management, Vol. 33, Nr 5
- Spałek S., (2013), Dojrzałość przedsiębiorstwa w zarządzaniu projektami, Wydawnictwo Politechniki Śląskiej, Gliwice
Autor: Justyna Gągała, Daniel Biernacki