PManager.pl

Okres dynamicznego rozwoju przemysłu informatycznego, mający miejsce przez ostatnie kilkanaście lat, spowodował zbliżenie się rynku IT do biznesu. Biznes wymaga od IT wsparcia we wszystkich aspektach związanych z zarządzaniem informacją poprzez przeprowadzenie kompleksowych projektów. Pomimo ogromnych nakładów pieniężnych, nadal ponad połowa projektów IT kończy się niepowodzeniem. Na niepowodzenie projektów w branży IT wpływa wiele czynników powiązanych w dużej mierze ze specyfiką prowadzonych projektów IT. Odpowiedzią na powtarzające się w projektach IT problemy było powstanie nowego nurtu prowadzenia projektów – Agile. Zwinne prowadzenie projektów IT skupia swą uwagę na jak najsprawniejszym dostarczeniu działającego oprogramowania oraz na ścisłej współpracy z klientem i reagowaniu na jego potrzeby.

Celem niniejszego opracowania jest próba wskazania możliwości połączenia najlepszych praktyk wykorzystywanych w tradycyjnych metodykach zarządzania projektami takimi jak PRINCE2 ^TM czy PMBoK ^® z podejściem opisywanym przez popularne w ostatnim czasie metodyki adaptacyjne z rodziny „Agile” wykorzystywane przy prowadzeniu projektów branży IT.

Niniejszy artykuł stanowią fragmenty pracy dyplomowej Autora, obronionej w ramach V edycji Podyplomowych Studiów Zarządzania Projektami na Wydziale Informatyki i Zarządzania Politechniki Wrocławskiej.  

Wprowadzenie 

IT (ang. Information Technology), czyli technologia informacyjna to pojęcie, które w ostatniej dekadzie znacznie umocniło się w naszym języku. Zgodnie z definicją jest to jedna z dziedzin informatyki, łącząca telekomunikację, narzędzia i inne technologie związane z informacją. Dostarcza ona użytkownikowi narzędzi, za pomocą których może on pozyskiwać informacje, selekcjonować je, analizować, przetwarzać, zarządzać i przekazywać innym ludziom [10].  W przeciągu ostatnich kilkunastu lat nastąpił ogromny rozwój rynku IT. W Polsce w roku 2007 wartość rynku IT przekroczyła 23,1 miliardy złotych, oznacza to wzrost o 27,8% w porównaniu do roku 2006 [11]. Nieodzownym partnerem IT jest biznes, a jedną z ostatnio obserwowanych zmian jest zbliżanie się IT do biznesu. Informatyka nie zajmuje się już tylko przetwarzaniem informacji, ale ma również wspierać biznes we wszystkich aspektach, począwszy od zarządzania informacją, przez upraszczanie komunikacji, automatyzację procesów, do ułatwienia współpracy. Granica pomiędzy IT
a biznesem zaciera się tak bardzo, że niektórzy analitycy badający rynek zapowiadają, że wkrótce termin IT zamieni się w BT (ang. Business Technology) i nie będzie to zmiana jedynie w sferze językowej [18].

Biznes wymaga od IT przeprowadzania kompleksowych projektów. Pomimo ogromnych nakładów pieniężnych, nadal ponad połowa projektów IT kończy się niepowodzeniem poprzez przekroczenie jednego z czterech podstawowych parametrów projektu: czasu, budżetu, zakresu lub jakości. Dane dotyczące czynników sukcesów oraz niepowodzeń w projektach IT, po raz pierwszy zostały opublikowane przez The Standish Group w raporcie zatytułowanym „Chaos” w roku 1995. Podstawowymi źródłami informacji w raporcie były liczne ankiety, badania oraz wywiady z menadżerami projektów IT prowadzonych w Stanach Zjednoczonych. W badaniach wzięło udział 365 menadżerów, a analizie poddano 8380 aplikacji [5]. Na rysunku nr 1 przedstawiono wyniki badań,
w których projekty zostały sklasyfikowane w trzech grupach:

• projekty zakończone sukcesem – projekty, które zostały zrealizowane w zaplanowanym budżecie, czasie oraz w pełnym zakresie,
• projekty zakończone niepełnym sukcesem – projekty, w których jeden lub więcej z podstawowych parametrów został przekroczony,
• projekty zakończone niepowodzeniem – projekty, które zostały przerwane jeszcze w trakcie ich trwania.

Jak można zauważyć, trend projektów zakończonych pełnym sukcesem stale rośnie, jednak nadal, mniej niż połowa projektów kończy się sukcesem. W roku 2006 zaledwie 35% projektów IT było zakończonych pełnym sukcesem. Badania The Standish Group miały na celu znalezienie podstawowych przyczyn niepowodzeń projektów oraz wskazanie podstawowych czynników wpływających na sukces projektu. Wyróżniono trzy podstawowe czynniki sukcesu projektów, którymi są zaangażowanie klienta, wsparcie kierownictwa oraz jasno określone wymagania. Kompletna lista czynników sukcesu projektu została dołączona do raportu z roku 1995 (Tabela 1).

Opublikowane badania wskazały, iż pomimo istnienia przyjętych standardów zarządzania projektami, znaczna ilość firm ma problemy ze skutecznym prowadzeniem projektów informatycznych. W Stanach Zjednoczonych, organizacja Project Management Institute, już od roku 1969 doskonaliła oraz popularyzowała standard prowadzenia projektów, jakim jest PMBoK®. Wskazane przez The Standish Group podstawowe czynniki niepowodzeń projektów IT, znalazły swe odzwierciedlenie w gwałtownej popularyzacji sprawdzonych metodologii zarządzania projektami, w tym PMBoK®, które licznie zaczęto wdrażać w organizacjach w celu usprawnienia procesów prowadzenia projektów w sposób kontrolowany. Popularyzacja opisywanych metod zarządzania projektami, zwanych również tradycyjnymi, przyniosła znaczne efekty, jednak nadal bardzo wiele organizacji nie potrafiło poradzić sobie z rozrastającymi się procesami, co powodowało, iż skuteczność prowadzenie projektów wcale nie wzrastała, a nawet pogarszała się.

Tabela 1. - Podstawowe czynniki sukcesu projektu wg Standish Group

Badania The Standish Group dotyczące kosztów projektów zakończonych porażką, oraz obserwowane zjawiska (polegające między innymi na wpędzaniu wielu korporacji w poważne kłopoty wskutek rozrastających się procesów) zaniepokoiły grupę ekspertów, która w roku 2001 zorganizowała spotkanie, na którym powstało zrzeszenie Agile Alliance [13]. Celem tej grupy była popularyzacja reguł oraz wartości, które skłonią zespoły projektowe do szybkiego oraz elastycznego wytwarzania oprogramowania, co miało na celu zwiększenie szans na zakończenie projektów IT z pełnym sukcesem. Przez kilka miesięcy grupie Agile Alliance udało się opracować najważniejsze założenia. Efektem tej pracy był dokument zatytułowany The Manifesto of The Agile Alliance. W dokumencie tym przedstawiono cztery główne reguły, które mają zasadniczy wpływ na skuteczność projektów IT:

• Programiści i ich harmonijna współpraca jest ważniejsza od procesów i narzędzi
• Działające oprogramowanie jest ważniejsze od wyczerpującej dokumentacji
• Faktyczna współpraca z klientem jest ważniejsza od negocjacji zasad kontraktu
• Reagowanie na zmiany jest ważniejsze od konsekwentnego realizowania planu

Zgodnie z podstawowymi wartościami Agile Alliance, celem każdego zespołu projektowego w przedsięwzięciach branży IT jest generowanie możliwie jak najwyższej jakości kodu dla klientów [9].

Jeszcze kilka lat temu pojęcie „projekt IT” było kojarzone w głównej mierze z wytwarzaniem oprogramowania, polegającym przede wszystkim na zebraniu wymagań, ich analizie i implementacji. Dziś projekt IT to tylko 40 – 60% oprogramowania, pozostała część to projekt organizacyjny, prawie zawsze ściśle powiązany z biznesem [14]. Środowisko IT wpadło w pułapkę nieustannego rozwijania procesów, które mimo dobrych intencji dodatkowo utrudniły realizację projektów. Należy zatem poszukiwać coraz to skuteczniejszych metod prowadzenia kompleksowych projektów informatycznych. Agile Project Management, czyli adaptacyjne (zwinne) zarządzanie projektami IT zdobywa coraz większą popularność. Przytoczone badania pokazują, że na niepowodzenie projektów
w branży IT wpływa wiele czynników, jednak wg zwolenników zarządzania zwinnego to nierzeczywiste założenie, że można przewidzieć przebieg projektu zawierającego jakąkolwiek dawkę niepewności jeszcze przed jego rozpoczęciem, jest główną przyczyną niepowodzeń.  Z drugiej strony „tradycyjni” Project Managerowie zarzucają technikom adaptacyjnym lekceważące podejście do harmonogramu, kosztu oraz zakresu projektu.

Poznanie oraz zrozumienie tradycyjnych oraz lekkich metodyk zarządzania projektem, oraz próba ich połączenia i uzyskania efektu synergii, może pomóc liderom projektów, dyrektorom firm i innym osobom związanym z prowadzeniem projektów IT
w przełamaniu barier oraz otwarcia na nowe możliwości prowadzenia projektów IT, co może pomóc w wyeliminowaniu lub uniknięciu wciąż popełnianych błędów i zwiększeniu efektywności prowadzenia projektów.

Odpowiedzią na powtarzające się w projektach IT problemy, było powstanie nowego nurtu zwinnego prowadzenia projektów – Agile, w którym to na pierwszym miejscu postawiono szybkie uzyskanie zadowalających efektów [16][6]. Zwinne prowadzenie projektów IT, skupia swą uwagę na jak najsprawniejszym dostarczeniu działającego oprogramowania oraz na ścisłej współpracy z klientem i reagowaniu na jego potrzeby. Doświadczenia zebrane z wielu projektów, pokazują jednak, iż zwinne metodyki prowadzenia projektów nie zawsze spełniają swoje zadanie. Bardzo częstym zaniedbaniem, w szczególności wśród mniej doświadczonych zespołów projektowych, jest całkowite zaniechanie dokumentowania prowadzonego projektu, oraz wytwarzanego produktu. Znaczne problemy pojawiają się w przypadku szacowania kosztów, oraz czasu trwania całego projektu, co jest szczególnie istotne w przypadku projektów ze sfery publicznej. Kolejne problemy mogą pojawić się w przypadku, kiedy projekt IT obejmuje nie tylko wytworzenie oprogramowania, lecz również jego wdrożenie, gdzie znaczna część całego projektu to projekt organizacyjny, o czym metodyki zwinne nie wspominają w szerszym kontekście.

Sztuka zarządzania projektami, która znacznie rozwinęła się przez ostatnie piętnaście lat, stanowi dziś, ścisłą, profesjonalną dyscyplinę. Składa się na nią wiedza teoretyczna, konkretny zestaw umiejętności i kompetencji oraz doświadczenie.  Zarządzanie projektem informatycznym, niejednokrotnie stanowi bardzo skomplikowane i trudne organizacyjnie przedsięwzięcie. Project Managerowie prowadzący projekty informatyczne często muszą radzić sobie z sytuacjami, w których jak doświadczenie pokazuje, tradycyjne procesy zarządzania projektem nie zawsze się sprawdzają. Sytuacja ta nie jest spowodowana niedopracowaniem tradycyjnych procesów zarządzania, lecz w dużej mierze specyfiką prowadzonych projektów IT, swoistością środowiska oraz nierzadko, innowacyjnością
i trudnym do zdefiniowania zakresem.

Odpowiedzią na powtarzające się w projektach IT problemy, było powstanie nowego nurtu zwinnego prowadzenia projektów – Agile, w którym to na pierwszym miejscu postawiono szybkie uzyskanie zadowalających efektów [16][6]. Zwinne prowadzenie projektów IT, skupia swą uwagę na jak najsprawniejszym dostarczeniu działającego oprogramowania oraz na ścisłej współpracy z klientem i reagowaniu na jego potrzeby. Doświadczenia zebrane z wielu projektów, pokazują jednak, iż zwinne metodyki prowadzenia projektów nie zawsze spełniają swoje zadanie. Bardzo częstym zaniedbaniem, w szczególności wśród mniej doświadczonych zespołów projektowych, jest całkowite zaniechanie dokumentowania prowadzonego projektu, oraz wytwarzanego produktu. Znaczne problemy pojawiają się w przypadku szacowania kosztów, oraz czasu trwania całego projektu, co jest szczególnie istotne w przypadku projektów ze sfery publicznej. Kolejne problemy mogą pojawić się w przypadku, kiedy projekt IT obejmuje nie tylko wytworzenie oprogramowania, lecz również jego wdrożenie, gdzie znaczna część całego projektu to projekt organizacyjny, o czym metodyki zwinne nie wspominają w szerszym kontekście [16].

Tradycyjne metodyki zarządzania projektami

Doświadczenia z projektów różnej skali, realizowanych w różnych środowiskach oraz rosnąca złożoność współczesnych przedsięwzięć zrodziły potrzebę usystematyzowania wiedzy dotyczącej zarządzania projektami. Liczne problemy związane z zarządzaniem projektami, w różnych obszarach aktywności, stały się przesłankami do powstania w roku 1969 Project Management Institute. Głównym celem instytutu jest zbieranie, analiza i uogólnienie doświadczeń w celu doskonalenia i popularyzacji metod realizacji projektów. W trakcie organizowanego przez Instytut seminarium w Montrealu w roku 1976 zrodziła się idea przedyskutowania i opracowania standardów praktyk i dokumentów używanych w procesie zarządzania projektami [17][12]. W roku 1981 zaakceptowany został projekt rozwoju procedur i koncepcji koniecznych do wspomagania zawodu zarządzania projektami. W wyniku licznych dyskusji przeprowadzonych przez kolejne lata na konferencjach oraz w zespołach roboczych, ogólny zbiór zasad zarządzania projektami został skodyfikowany przez PMI oraz wydany w postaci przewodnika PMBoK (Project Management Body of Knowledge). Jednocześnie w Wielkiej Brytanii w roku 1989 powstała metodyka PRINCE.  Metodyka ta powstała dzięki Central Computer and Telecommunications Agency (CCTA) na bazie metodyki PROMPT opracowanej przez firmę Simpact System w roku 1975. W latach 1979 – 1980 CCTA wprowadziło metodykę PROMPT jako standard do stosowania we wszystkich projektach informatycznych wykonywanych dla potrzeb Rządu Wielkiej Brytanii. Kolejny etap rozwoju przypada na rok 1996, kiedy to wprowadzono unowocześnioną wersję metodyki – PRINCE2 [2]. Nowa wersja stała się dużo bardziej uniwersalna i można ją już stosować nie tylko do projektów informatycznych.

W metodyce PMBoK projekt jest charakteryzowany jako działania, które wykonywane są przez ludzi, realizowane są przy ograniczonych zasobach, są planowane, realizowane i kontrolowane. Ponadto podkreślane jest, że projekt jest działaniem ograniczonym w czasie, podejmowanym dla wykonania unikatowego produktu lub usługi [12][5]. Ograniczenie czasowe oznacza, że każdy projekt należy rozważać w przedziale czasu od jego rozpoczęcia do zakończenia, czyli w cyklu życia. Ograniczenie to oznacza również, że działania podejmowane w ramach realizacji projektu mogą mieć sens biznesowy jedynie w tym konkretnym czasie, co wynika z szansy rynkowej lub powstałej okazji biznesowej. Na ten określony czas realizacji projektu powoływany jest zespół, który ma określone zadania do wykonania w ramach projektu, a po ich ukończeniu jest rozwiązywany. Kolejnym charakterystycznym elementem projektu jest unikatowość wykonywanego produktu lub usługi, co oznacza, że jest to najczęściej praca pionierska, której nikt wcześniej nie wykonywał. Te cechy są charakterystyczne dla projektów. W szczególności wytwarzanie systemu informatycznego spełnia te warunki i jest reprezentatywnym przykładem projektu w rozumieniu PMBoK.

Zarządzanie projektami, według PMBoK, jest natomiast zastosowaną wiedzą, umiejętnościami i technikami wykorzystywanymi w procesie realizacji wymagań projektowych. Metodyka opisuje 5 głównych grup procesów oraz 9 obszarów aktywności:

• Procesy PMBoK:
  • Grupa procesów rozpoczęcia
  • Grupa procesów planowania
  • Grupa procesów realizacji
  • Grupa procesów monitorowania i kontroli
  • Grupa procesów zakończenia
• Obszary aktywności:
  • Zarządzanie integracją projektu
  • Zarządzanie zakresem projektu
  • Zarządzanie czasem w projekcie
  • Zarządzanie kosztami projektu
  • Zarządzanie jakością w projekcie
  • Zarządzanie zasobami ludzkimi w projekcie
  • Zarządzanie komunikacją w projekcie
  • Zarządzanie ryzykiem w projekcie
  • Zarządzanie zamówieniami w projekcie

Standard PMBoK jest bardzo mocno ukierunkowany na usystematyzowany zestaw konkretnych, sprawdzonych technik i narzędzi zarządczych. Podstawą opisu każdego procesu jest zestaw technik, które mogą być wykorzystane do jego realizacji. Większość technik jest opisywana, niektóre tylko wskazywane – na przykład poprzez odniesienie do literatury. Techniki w standardzie PMBoK są rozumiane bardzo szeroko. Można wyróżnić kilka podstawowych grup technik:

• techniki i modele formalne (przykładami mogą tu być Analiza Wartości Uzyskanej wykorzystywana jako metoda oceny postępu prac, analiza wrażliwości czy symulacje stosowane w trakcie ilościowej oceny ryzyka)
• graficzna analiza lub prezentacja danych (przykładami mogą być np. diagramy Ishikawy lub Pareto w obszarze zarządzania jakością)
• opisy czynności niezbędnych do realizacji procesów (przykładem mogą być konferencje oraz ogłoszenia, jako technika wyszukiwania dostawców)
• narzędzia „proceduralne” (przykładowo system zarządzania zmianami czy sposób odbioru prac projektu)
• narzędzia komputerowe
• oceny ekspertów

Standard PMBoK jest bardzo zwarty w swym opisie. Percepcję standardu dodatkowo ułatwia przyjęty i konsekwentnie stosowany sposób prezentacji wiedzy. Wiedza dotycząca zarządzania projektami jest podzielona na dziewięć spójnych obszarów. Każdy obszar składa się z procesów, każdy proces ma dobrze określone wejście, techniki i wyjście. Istnieją diagramy powiązań procesów oraz opis produktów (wejść i wyjść) przekazywanych pomiędzy procesami.

Metodyka PRINCE2 opiera się na kilku głównych zasadach, najważniejsze z nich to:

• projekt musi posiadać swój początek i koniec
• projekt musi być zarządzany tak, aby zakończył się sukcesem danego przedsięwzięcia
•  zarządzający, finansujący oraz pracujący muszą mieć dokładnie określone swoje kompetencje, powinni dokładnie znać cele projektu oraz sposób, w jaki mają zostać osiągnięte i w jakim stopniu ponoszą odpowiedzialność za prowadzenie projektu

Każdy podejmowany projekt musi:

• realizować wszystkie procesy dotyczące stworzenia efektywnego środowiska zarządzania projektem
• mieć określone uzasadnienie biznesowe pokazujące korzyści i ryzyka związane z przedsięwzięciem
• posiadać unikalny zestaw właściwie określonych produktów głównych i cząstkowych
• obejmować odpowiedni zestaw działań służących wytworzeniu tych produktów
• określać właściwe zasoby zdolne do podjęcia takich działań
• mieć skończony czas trwania i właściwie zorganizowane środki do sterowania projektem
• określać strukturę organizacyjną ze zdefiniowanymi zakresami odpowiedzialności
• zawierać zestaw procesów i związanych z nimi technik, które pomagają planować i kontrolować projekt, doprowadzając go do pomyślnego końca

Zgodnie z PRINCE2, projekt dzielony jest na kilka etapów stanowiących odrębną jednostkę. W każdej z nich wykorzystywane są trzy główne elementy, a mianowicie: technika, komponenty oraz procesy [2]. Metodyka opisuje 8 głównych grup procesów, 8 komponentów,a także 3 techniki:

• Procesy PRINCE2:
  • Przygotowanie Założeń Projektu
  • Inicjowanie Projektu
  • Strategiczne Zarządzanie Projektem
  • Sterowanie Etapem
  • Zarządzanie Wytwarzaniem Produktu
  • Zarządzanie Zakresem Etapu
  • Zamykanie Projektu
  • Planowanie
• Komponenty PRINCE2:
  • Uzasadnienie Biznesowe
  • Organizacja
  • Plany
  • Elementy Sterowania
  • Zarządzanie Ryzykiem
  • Jakość w środowisku projektu
  • Zarządzanie Konfiguracją
  • Zarządzanie Zmianą
• Techniki PRINCE2:
  • planowanie oparte na produktach
  • przeglądy jakości
  • zarządzanie zmianą

PRINCE2 jest to pełny opis procesów zarządczych wykonywanych w trakcie realizacji projektu. Główną częścią stanowiącą opis tej metody jest opis procesów, które trzeba wykonać od momentu podjęcia decyzji o rozpoczęciu prac nad projektem aż po jego zakończenia (a nawet dalej – do czynności, które należy wykonać po zakończeniu projektu, w celu oceny przydatność produktów projektu dla użytkowników). Wszystkie procesy mają określoną kolejność ich wykonywania, wyniki realizacji procesów są przekazywane do ściśle określonych innych procesów. Zależności pomiędzy produktami i procesami oraz pomiędzy procesami są przedstawiane w przejrzystej postaci graficznej. W PRINCE2 dokładnie wiadomo, co trzeba zrobić, żeby rozpocząć projekt, w jaki sposób projekt można przedwcześnie przerwać i jakie muszą być do tego podstawy.

Metodyka PRINCE2 jest nastawiona na uzyskiwane wyniki. Planowanie jest zorientowane na produkt. Wykonywane prace są widziane przez pryzmat tworzonych produktów. Takie podejście sprzyja uzyskiwaniu rzeczywistych efektów realizacji produktu. Konsekwencją techniczną takiego punktu widzenia jest na przykład występowanie Struktury Podziału Produktu zamiast Struktury Podziału Pracy. Takie podejście zdecydowanie promuje efektywność, a przede wszystkim skuteczność prac w projekcie. Żadna praca nie może być rozliczona, jeśli jej wynikiem nie jest konkretny efekt.

Cykl życia projektu

Zgodnie z definicją, cykl życia projektu traktowany jest, jako kolejne etapy łączące początek i koniec przedsięwzięcia [19]. Podział przedsięwzięcia na etapy, usprawnia kontrolę zarządzania oraz umożliwia powiązanie z działalnością operacyjną organizacji realizującej projekt. Nie istnieje jeden, idealny model cyklu życia projektu. Wiele organizacji wypracowało swój własny, znormalizowany cykl życia projektu, który jest stosowany we wszystkich przedsięwzięciach. Modele te najczęściej określają, jakie prace techniczne należy wykonać na danym etapie, kiedy w danym etapie mają powstać produkty cząstkowe, kto ma uczestniczyć w realizacji danego etapu oraz w jaki sposób kontrolować i zatwierdzać dany etap.

Zgodnie z opisem standardu PMBoK®, tradycyjne cykle życia projektu posiadają pewne cechy wspólne, którymi są:

• Następowanie kolejnych etapów jeden po drugim, gdzie początek i koniec etapu określa najczęściej przekazanie informacji lub produktów technicznych
• Poziom ponoszonych kosztów oraz stopień zaangażowania zasobów ludzkich są na początku projektu niskie, następnie wzrastają w trakcie pośrednich etapów, wreszcie gwałtownie spadają, gdy projekt zbliża się do końca
• Poziom niepewności oraz ryzyka na początku projektu jest najwyższy, w miarę realizacji projektu prawdopodobieństwo udanego zakończenia na ogół stopniowo wzrasta
• Możliwości wywierania wpływu przez interesariuszy na końcowe właściwości produktu projektu oraz ostateczny koszt jego realizacji są największe na początku przedsięwzięcia i spadają w miarę jego realizacji.

Diagram przedstawiony na powyższym rysunku przedstawia typową kolejność etapów cyklu życia projektu zgodną z PMBoK®. Każdy etap projektu wyznaczony jest przez ukończenie i zatwierdzenie jednego lub więcej produktów cząstkowych. Ze względu na wielkość, złożoność, poziom ryzyka i ograniczenia przepływów pieniężnych etapy w dowolnym projekcie można podzielić na podetapy. W tradycyjnym podejściu do wytwarzania oprogramowania, etapowy cykl życia projektu intuicyjnie mapowany jest na kaskadowy, zwany także wodospadowym, model wytwarzania oprogramowania [8]. Zakłada on, że każdy etap projektu może zacząć się tylko i wyłącznie wtedy, gdy poprzedni etap zostanie w pełni zakończony. Dodatkowo, powrót do poprzednich etapów po ich zakończeniu nie jest możliwy, choć istnieją odmiany modelu, które pozwalają na powrót do etapu poprzedniego w celu modyfikacji jego produktów cząstkowych  Niewątpliwymi zaletami takiego modelu, są prostota oraz łatwe planowanie i kontrolowanie wyników prac. Model ten jest bardzo prosty i nie wymaga praktycznie żadnych szczegółowych omówień. Prostota i liniowość modelu w znacznym stopniu ułatwia planowanie przebiegu prac. Stosując jednak model kaskadowy w projekcie IT, należy mieć na uwadze jego liczne wady oraz ograniczenia. Jedną z najistotniejszych wad jest niedostosowanie modelu do zmian występujących w projekcie. Zmiany są codziennością praktycznie każdego projektu IT [3]. Poprawnie przeprowadzony etap może poprzez zmiany stać się po pewnym czasie nieaktualny. Stosując model, który nie przewiduje możliwości powrotu do zakończonych faz, powroty do nich wiążą się z wieloma utrudnieniami i wymuszają jawne odstępstwa od modelu. Powoduje to, iż wszelkie takie zmiany są kosztowne. Z tych samych przyczyn, mogą wystąpić również problemy z poprawą błędów, które zostały wykryte już po zakończeniu fazy, w której zostały popełnione. Kolejnym, istotnym minusem modelu kaskadowego, jest długi czas oczekiwania na efekty. Pomiędzy etapem specyfikacji wymagań a dostarczeniem klientowi działającej wersji produktu upływa bardzo dużo czasu. Produkt prezentowany jest klientowi dopiero pod sam koniec projektu. Poprawienie wszelkich zastrzeżeń, jakie zgłosił klient, jest w końcowej fazie bardzo kosztowne.

Ze względu na swoje wady, model kaskadowy może być stosowany w swojej czystej postaci jedynie w bardzo małych i prostych projektach. Jednakże nawet w nich jego wady mogą się ujawniać. Z tych powodów model ten jest w praktyce rzadko stosowany, jednakże jego prostota powoduje, że stanowi on podstawę dla wielu innych modeli w projektach IT.

Agile Project Management 

Współczesna definicja zwinnego wytwarzania oprogramowania rozwinęła się w połowie lat 90-tych, jako alternatywa dla tradycyjnego podejścia opartego o model kaskadowy. Tradycyjne procesy wytwarzania oprogramowania, były uważane za zbyt biurokratyczne, powolne oraz nieefektywne [15]. Uważa się, że agile oraz modele iteracyjne stały się punktem zwrotnym rozwoju metodyk wytwarzania oprogramowania. W roku 2001, grupa ekspertów rozwijająca lekkie techniki wytwarzania oprogramowania, zorganizowała spotkanie w Snowbird, w stanie Utah. Spotkanie to zainicjowało powstanie zrzeszenia Agile Alliance, po raz pierwszy też, przyjęto wspólną nazwę „Agile methods” określającą zwinne, lekkie techniki wytwarzania oprogramowania. Celem tej grupy była popularyzacja reguł oraz wartości, które skłonią zespoły projektowe do szybkiego oraz elastycznego wytwarzania oprogramowania, co miało na celu zwiększenie szans na zakończenie projektów IT z pełnym sukcesem. Kilka miesięcy prac zaowocowało opracowaniem dokumentu zatytułowanego The Manifesto of The Agile Alliance. W dokumencie tym przedstawiono cztery główne reguły, które w zasadniczy sposób miały zmienić podejście zespołów projektowych do wytwarzania oprogramowania:

• Programiści i ich harmonijna współpraca jest ważniejsza od procesów i narzędzi - Reguła ta zwraca uwagę tradycyjnych Project Managerów, aby traktowali ludzi, jako najuważniejszy czynnik decydujący o sukcesie projektu. Nawet najlepiej zorganizowane procesy zarządzania projektem, nie uchronią projektu przed porażką, jeśli kierownik nie będzie mógł zaufać swojemu zespołowi. Co więcej, zły proces może spowodować, że nawet najlepszy zespół będzie pracować nieefektywnie.
• Działające oprogramowanie jest ważniejsze od wyczerpującej dokumentacji - Kolejna reguła dotyczy procesów związanych z wytwarzaniem dokumentacji opisującej oprogramowanie. Dokumentacja oprogramowania jest elementem niezbędnym, jednak zbyt duża liczba dokumentów opisujących oprogramowanie jest gorsza od zbyt skromnej dokumentacji. Tworzenie ogromnych dokumentów wymaga dużych nakładów czasowych, a w skrajnych przypadkach uniemożliwia ich synchronizacji z kodem źródłowym.
• Faktyczna współpraca z klientem jest ważniejsza od negocjacji zasad kontraktu - Zaangażowanie klienta, jako jeden z kluczowych czynników sukcesu projektu stanowi podstawę kolejnej reguły. Oprogramowanie nie może być zamawiane jak zwykły towar w sklepie. Jego opisanie a następnie zlecenie komuś wykonania w określonym terminie i za ustaloną cenę jest w większości przypadków niemożliwe. Wytworzenie oprogramowania zgodnego z oczekiwaniami klienta wymaga stałej współpracy z nim, najlepiej w formie regularnych, możliwie częstych spotkań. Skupienie swej uwagi na zapisywaniu w kontraktach szczegółowych wymagań oraz harmonogramów wykonania prowadzi do sytuacji, w których kontrakty stają się nieaktualne na długo przed zakończeniem realizacji projektu. Należy zatem starać się uzgadniać kontrakty, w których przewiduje się ścisłą współpracę zespołu programistów z przedstawicielami klienta.
• Reagowanie na zmiany jest ważniejsze od konsekwentnego realizowania planu - Ostatnia reguła zwraca uwagę na fakt, iż jednym z głównych czynników sukcesu projektu polegającego na budowie oprogramowania, jest zdolność do częstego i szybkiego reagowania na zmiany. Pracując nad planami realizacji projektu, koniecznie należy upewnić się, że tworzony harmonogram będzie na tyle elastyczny, aby można było w jego ramach wprowadzić zmiany zarówno w wymiarze biznesowym jak i technologicznym.

Na podstawie czterech ogólnych reguł, sformułowano zbiór dwunastu szczegółowych zasad. Zasady te w wyraźny sposób odróżniają praktyki programowania zwinnego od tradycyjnych, ciężkich procesów wytwarzania oprogramowania:

• Naszym najwyższym nakazem jest spełnianie oczekiwań klienta przez możliwie wczesne dostarczanie wartościowego oprogramowania.
• Traktujemy zmiany wymagań ze zrozumieniem, nawet jeśli następują w późnych fazach wytwarzania.
• Działające oprogramowanie należy dostarczać klientowi możliwie często (w odstępach kilkutygodniowych lub kilkumiesięcznych).
• Ludzie biznesu powinni ściśle współpracować z programistami na wszystkich etapach projektu.
• Projekty należy planować wokół dobrze umotywowanych programistów. Należy im zorganizować niezbędne środowisko i wsparcie, a także obdarzyć ich potrzebnym zaufaniem.
• Najbardziej efektywną metodą przekazywania informacji do i w ramach zespołu programistów jest rozmowa w cztery oczy.
• Podstawowym miernikiem postępu prac nad projektem jest ilość i jakość działającego programowania.
• Procesy zwinne ułatwiają utrzymywanie ciągłości wytwarzania. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa pracy przez cały czas realizacji projektu.
• Pozytywny wpływ na zwinność projektu ma stała dbałość o doskonałość techniczną i właściwy projekt.
• Kluczowym elementem pomyślnego zakończenia projektu jest prostota, czyli sztuka maksymalizacji ilości pracy, której nie wykonujemy.
• Źródłem najlepszych architektur, specyfikacji wymagań i projektów są zespoły, którym dano wolną rękę w zakresie organizacji. 
• W stałych odstępach czasu zespół zaangażowany w tworzenie oprogramowania powinien analizować możliwości usprawnienia pracy i dostosowywać swoje dalsze działania do wniosków płynących z tej analizy.

Przedstawione powyżej główne reguły zwinnego wytwarzania oprogramowania, oraz wynikające z nich zasady szczegółowe, są wynikami doświadczeń oraz obserwacji specjalistów biorących udział w wielu projektach IT. Obserwacje te pozwoliły im wyróżnić najczęściej zaniedbywane obszary wiedzy zarządzania projektami IT oraz najczęściej pojawiające się problemy podczas wytwarzania produktów w projektach informatycznych. Ich spisanie oraz usystematyzowanie pozwoliło Project Managerom zweryfikować tradycyjne procesy zarządzania projektami informatycznymi oraz sposób, w jaki procesy te są wykorzystywane podczas projektów.

Zrzeszenie Agile Alliance, które jako pierwsze określiło zwinne, lekkie techniki wytwarzania oprogramowania pod wspólną nazwą „Agile methods”, skupiło swą uwagę na określeniu ogólnych reguł, zasad oraz wartości, jakie powinny kierować zespołami projektowymi wytwarzającymi oprogramowanie. Zrzeszenie nie wskazało, ani nie stworzyło, określonych metod jakimi projekty informatyczne, niejednokrotnie będące projektami innowacyjnymi, powinny być zarządzanie, oraz technik jakimi oprogramowanie powinno być wytwarzane zgodnie z wartościami Agile. Nie stanowiło to głównego celu zrzeszenia, gdyż w owym czasie istniały już techniki, które proponowały adaptacyjne podejście to wytwarzania produktów, nie tylko w branży IT. Określenie wspólnej nazwy oraz najważniejszych wartości, pozwoliło jednak na sklasyfikowanie technik oraz metod już istniejących, oraz na opracowywanie nowych technik wspierających założone wartości.

Metodyka SCRUM jest dzisiaj jedną z najczęściej spotykanych metodyk zwinnego wytwarzania produktów oraz prowadzenia projektów innowacyjnych [15]. Nazwa metodyki (SCRUM - młyn) wywodzi się z terminu występującego w grze rugby. Pomysłodawcami jej są Hirotaka Takeuchi i Ikujiro Nonaka, którzy w artykule „The New New Product Development Game”, jaki ukazał się w Harvard Business Review (styczeń-luty 1986), przedstawili ogólne założenia metodyki. W roku 1995 definicja oraz sama metodyka zostały sformalizowane przez Kena Schwabera.

Metodyka SCRUM powstała, aby móc sprawnie zarządzać projektami innowacyjnymi, lub projektami o nieznanych lub wysoce zmiennych wymaganiach. W tym celu zdecydowanie skrócono proces decyzyjny, powierzając podejmowanie wielu decyzji projektowych zespołowi oraz redukując ilość czasu poświęcaną na planowanie projektu. W metodyce SCRUM zespół projektowy pracuje w określonym przedziale czasowym zwanym przebiegiem (ang. sprint). Efektem przebiegu za każdym razem powinno być dostarczenie użytkownikom kolejnego działającego produktu. Zasadą jest to, że zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną. Przebieg może trwać od 2 do 6 tygodni. Zaleca się stosowanie przebiegów o stałych długościach. Metodyka wyróżnia trzy podstawowe role w zespole projektowym:

• Mistrz Młyna (ang. Scrum Master) – rola ta jest bardziej rolą doradcy oraz autorytetu na temat metodyki niż typową rolą kierownika projektu. Scrum Master pełni funkcję doradcy dla właściciela produktu podczas dobierania elementów zapisanych w tzw. product backlog, czyli elementach pozostałych do wykonania. Ponadto ma za zadanie dbać o dobre warunki dla realizacji projektu i usuwać ewentualne trudności poza projektowe.
• Właściciel produktu (ang. Product Owner) – rola sprawowana w projekcie przez klienta lub odbiorcę produktu. Właściciel produktu stanowi źródło wiedzy o wizji i kierunku rozwoju produktu.
• Zespół (ang. The Team) – zespół wytwarzający produkt projektu. Zespół jest odpowiedzialny za przedstawienie efektów swojej pracy właścicielowi produktu.

W metodyce SCRUM można wyróżnić cztery podstawowe fazy wytwarzania produktu: wizja, plan sprintu, sprint, przegląd sprintu.

• Wizja - Projekt rozpoczyna się od wizji realizowanego produktu. Początkowo może to być wizja bardzo ogólna i wyrażona w języku marketingowym, biznesowym, która wraz z realizacją kolejnych faz będzie się krystalizować. Na tym etapie powstaje tzw. product backlog. W dokumencie tym umieszczane są wszystkie funkcjonalne i niefunkcjonalne wymagania, które powinny zostać zrealizowane.
• Plan sprintu - Idea metodyki oparta jest na tzw. sprintach. Sprint jest pojedynczą iteracją o określonym czasie trwania. Iterację rozpoczyna faza planowania, w której właściciel produktu oraz zespół projektowy ustalają, co powinno zostać wykonane w najbliższym sprincie.
• Sprint - W fazie tej zespół projektowy realizuje funkcjonalności zebrane w dokumencie zwanym sprint backlog. Każdy sprint w przeciągu całego projektu powinien mieć określony, stały czas trwania (2- 6 tygodni). Każdego dnia organizuje się krótkie spotkania, na których członkowie projektu wymieniają się informacjami, co już zrobili i co planują zrobić w najbliższym czasie. Celem codziennych spotkań jest synchronizacja wiedzy o projekcie pomiędzy jego uczestnikami.
• Przegląd sprintu - W tej fazie zespół projektowy przedstawia efekty swojej pracy podczas sprintu oraz podejmowane są decyzje dotyczące dalszej realizacji projektu oraz kierunku rozwoju produktu.

Metodyka programowania ekstremalnego (ang. eXtreme Programming) została utworzona przez Kenta Becka, podczas pracy nad projektem C3 (zintegrowany system płacowy) w korporacji Chrysler w roku 1995 [13]. Podstawą programowania ekstremalnego jest synergia wynikające z rozmaitych praktyk, mających wiele zalet, lecz będących trudnymi w zastosowaniu:

• Iteracyjność – programy tworzone w krótkich iteracjach, w których planowanie odbywa się na bieżąco przed każdą następną iteracją.
• Brak projektowania z góry – jeżeli nie można przewidzieć jaka architektura będzie najlepsza dla danego rozwiązania, nie powinno się jej projektować lecz tworzyć w miarę realizacji projektu.
• Testy podzespołów – testy podzespołów powinny być tworzone przed wytworzeniem samych podzespołów. Następnie tworzony jest kod programu, który potrafi je wszystkie przejść.
• Ciągłe modyfikacje architektury – architektura nie powinna być sztywno narzucona, jeżeli zmiana architektury poprawi działanie systemu, należy ją wprowadzić.
• Programowanie parami – programiści pracują w parach, jedna osoba powinna pracować przy klawiaturze i być głównym koderem, druga powinna monitorować pracę oraz zgłasza poprawki.
• Stały kontakt z klientami.

Dynamic System Development Method jest metodyką projektowania oprogramowania zaproponowaną przez brytyjskie konsorcjum DSDM. Metodologia ta powstała na bazie ideologii RAD (ang. Rapid Application Development) oznaczającej szybkie tworzenie aplikacji [6]. Podstawowe założenia DSDM opierają się na stwierdzeniu, że zadania, które należy wykonać w celu stworzenia danego systemy, zawsze podlegają zmianom. Metodyka wyróżnia aż 15 ról w procesie tworzenia oprogramowania, najważniejsze z nich to: Executive Sponsor, Visionary, Ambassador User, Advisor User, Technical Co-ordinator, Team Leader. W skład procesu tworzenia oprogramowania zgodnie z DSDM wchodzą następujące fazy:

• Inspekcja zastosowalności
• Badanie biznesowe
• Iteracyjne opracowanie modelu funkcyjnego
• Iteracyjne projektowanie i implementacja
• Wdrożenia

Cykl życia projektu w zarządzaniu zwinnym

Poza zbiorem wartości wspierających szybkie i sprawne wytwarzanie oprogramowania, techniki lekkie mogą być wyrażone, jako generalne podejście do iteracyjnego oraz przyrostowego dostarczania oprogramowania. Procesy w zarządzaniu zwinnym nie są tak istotne jak ludzie, jednak są niezbędne, muszą być zgodne z wartościami głoszonymi przez Agile Alliance, jednocześnie wspierając cele biznesowe przedsięwzięcia. Zwinny cykl życia projektu powinien przede wszystkim [6]:

• wspierać tworzenie wizji, eksplorację oraz kulturę adaptacyjną
• wspierać zdyscyplinowane zespoły samoorganizujące się
• promować solidność oraz konsekwentnie dążyć do zmniejszenia niepewności w projekcie
• być elastyczny
• udostępniać punkty kontrolne, w celu przeglądu stanu projektu

Założenia te pozwoliły na stworzenie ogólnego modelu zwinnego zarządzania projektem, w którym można wyróżnić pięć podstawowych faz: tworzenie wizji, planowanie adaptacyjne, eksploracja, adaptacja, zamknięcie projektu. Adaptive Project Framework (rysunek 8) został opracowany przez Jima Highsmitha, jest to iteracyjny model wytwarzania produktów i stanowi alternatywę dla tradycyjnego cyklu życia projektu, który składa się z faz następujących kolejno po sobie.

Tworzenie wizji – to początkowa faza projektu, nazywana często tworzeniem zakresu wersji. Ma ona zakres dość podobny do fazy planowania w tradycyjnym modelu zarządzania projektem. Definiuje się w niej warunki sukcesu projektu, cele projektu, zadania, których wykonanie ma prowadzić do celu oraz zespół, który ów zadanie będzie realizował. Określone są też mierzalne rezultaty projektu.

Planowanie adaptacyjne – spekulacja, faza polegająca w głównej mierze na wstępnym zaplanowaniu tworzonego produktu. Bazując na niekompletnych informacjach tworzy się pierwszą wersję wymagań funkcjonalnych oraz niefunkcjonalnych, szacuje się ilość pracy potrzebną do wykonania poszczególnych funkcjonalności, tworzy plan dostarczania kolejnych wydań oprogramowania. Tworzy się plan zarządzania ryzykiem oraz szacuje wstępne koszty projektu.

Eksploracja – faza dostarczająca produkty cząstkowe, stanowiące najczęściej poszczególne funkcjonalności oprogramowania. Z punktu widzenia zarządzania projektem w fazie tej można wyróżnić trzy podstawowe działania: dostarczanie produktu, tworzenie samoorganizującego się zespołu, potrafiącego samodzielnie współpracować, zarządzanie komunikacją pomiędzy klientem a zespołem.

Adaptacja – punkt kontrolny klienta. W fazie tej następuje przegląd jakości dostarczonych funkcjonalności, pomiar wydajności zespołu realizującego projekt, oraz ocena stanu całego projektu. W fazie tej następuje podjęcie decyzji, co do następnego etapu realizacji projektu, przejście do kolejnej iteracji (planowanie adaptacyjne) czy też decyzja o zakończeniu projektu. W ten sposób następuje iteracyjne wytwarzanie kolejnych funkcjonalności w trzech fazach planowanie – eksploracja – adaptacja.

Zamknięcie projektu – ostatnia faza cyklu życia projektu, może zostać osiągnięta w momencie, kiedy sponsor uzna, że kontynuacja projektu nie ma sensu, lub kiedy oceni, że osiągnięty efekt to produkt, który spełnia jego oczekiwania.

Stosowanie w projektach IT opisanego powyżej modelu pociąga za sobą wiele pozytywnych jak i negatywnych aspektów. Niewątpliwą zaletą takiego modelu jest jego dostosowanie do zmian występujących w projekcie. Przedstawiony w rozdziale 2.3 kaskadowy model wytwarzania oprogramowania, który bazuje na tradycyjnym, etapowym, cyklu życia projektu, zakłada jak najdokładniejszą analizę tworzonego systemu oraz szczegółowe zaplanowanie jego realizacji, APF natomiast zakłada minimalistyczną strategię wymagań, w której ich zbieranie od klienta, analiza oraz planowanie powtarzają się cyklicznie w trakcie trwania projektu, a nie kończą się wraz z rozpoczęciem fazy implementacji. Podejście takie pozwala błyskawicznie reagować na zmiany w tworzonym systemie, zakłada wręcz oczekiwanie na zmiany oraz gotowość do ich wprowadzenia. Kolejną, niewątpliwą zaletą, jest szybkie dostarczenie gotowych funkcjonalności do klienta. Tradycyjny model przeprowadza projekt przez kolejne fazy a dostarczenie działającego oprogramowania następuje na końcu cyklu. Model adaptacyjny, przedstawiony na rysunku 8, zakłada jak najwcześniejsze dostarczenie klientowi części funkcjonalności już po pierwszej iteracji. Pozwala to sponsorowi projektu kontrolować kierunek rozwoju produktu, już od samego początku.
Stosowanie iteracyjnego cyklu życia projektu, może spowodować pojawienie się poważnych problemów podczas estymacji i planowania projektu. Minimalistyczna strategia wymagań może powodować, że wiele istotnych czynników odkrywa się dopiero w trakcie realizacji projektu, co powoduje, że początkowe szacowania (spekulacje) nie oddają rzeczywistości, dodatkowo wstępnie uzgodniona lista funkcjonalności może wielokrotnie ulegać zmianie lub aktualizacji, co znacząco może wydłużyć czas realizacji, a co za tym idzie także koszt całego przedsięwzięcia. Kolejny problem może wynikać z jednego z podstawowych założeń iteracyjnego cyklu projektu, a mianowicie założenia, że czas każdej iteracji powinien być stały w ciągu całego projektu. Zakres kolejnych iteracji powinny być tak dobierany, aby sumaryczny czas poszczególnych faz iteracji planowanie adaptacyjne – eksploracja – adaptacja był stały, co niejednokrotnie może być trudne do zapewnienia. Implementacja złożonych funkcjonalności, których nie można podzielić na mniejsze, dodatkowo czas poświęcony na testy i zapewnienie jakości mogą powodować trudności w zapewnieniu stałych czasów kolejnych iteracji.

Podsumowując wady i zalety cyklu życia projektu w zarządzaniu zwinnym, należy przede wszystkim uwzględnić kompromisy, na jakie Kierownik Projektu może sobie pozwolić. Prowadząc projekt o wysokim stopniu ryzyka oraz wysoce niepewnym zakresie, zdecydowanie warto rozważyć możliwość zastosowania iteracyjnego cyklu życia projektu, który pozwala na ścisłą kontrolę przez sponsora projektu jego kierunku rozwoju. W przypadku, kiedy mamy do czynienia z projektem, w którym wymagany jest dokładniejszy harmonogram realizacji oraz kosztorys planowanych prac, stosowanie adaptacyjnego cyklu życia projektu może nastręczać wiele trudności lub być wręcz niemożliwe.

Zarządzanie tradycyjne z wykorzystaniem podejścia Agile

Przedstawione w poprzednich rozdziałach metodyki tradycyjne oraz zwinne wyróżnia przede wszystkim odmienne podejście do podstawowych parametrów projektu, jakimi są: zakres, czas oraz budżet, przy zachowaniu najwyższej jakości. Metodyka PMBoK® zakłada zrealizowanie pewnego zakresu projektu, w określonym czasie i przy określonych kosztach. Zaleca się, aby parametry te zostały określone już na początku projektu. W większości przypadków, a w szczególności w projektach IT, dokładne określenie wszystkich trzech parametrów, jest jednak bardzo trudne, lub wręcz niemożliwe. Dlatego często stosowaną praktyką jest tworzenie tzw. macierzy kompromisów projektowych, w której to dokładnie jedna zmienna musi być ustalona, dokładnie jedna może się zmieniać w określonych granicach (optymalizowana), pozostałe mogą zmieniać się dowolnie (negocjowane) [4]. Kaskadowy model wytwarzania produktów w projektach IT, stanowiący najczęstszą interpretację tradycyjnego cyklu życia projektu, zakłada, że stosunkowo najmniej elastyczną zmienną jest zakres projektu, który domyślnie ma zostać zrealizowany w całości. W projektach zwinnych natomiast, zakres projektu jest zmienną stosunkowo najbardziej elastyczną, natomiast harmonogram i koszt są ściśle określone lub optymalizowane, co w założeniu ma stymulować zespół projektowy do dostarczenia gotowych i działających produktów w skończonym czasie i budżecie – nawet wówczas, gdy będą to produkty niekompletne pod względem funkcjonalnym.

Różnica w podejściu do „trójkąta projektowego” została zilustrowana na powyższym rysunku. Odwrócenie paradygmatu trójkąta budżet – czas – zakres został po raz pierwszy zaproponowany przez firmę DSDM, która opracowała metodę Dynamic System Development Method. Odpowiednie dopasowanie oraz połączenie ze sobą wszystkich procesów związanych z projektem i produktem ułatwia ich koordynację [17]. Tradycyjne procesy zarządzania projektami w dużej mierze skupiają swoją uwagę na planowaniu i kontroli planów, w celu uniknięcia zmiany zakresu projektu. W celu połączenia metodyki PMBoK® ze zwinnymi technikami wytwarzania produktów w projektach IT, które wychodzą z założenia, że zmiana zakresu projektu jest wręcz oczekiwana, wymagane jest dostosowanie pewnych grup procesów w wybranych obszarach wiedzy zarządzania projektem.

Wytwarzanie produktów IT - nowy cykl życia projektu

Jak wspomniano wcześniej wielu Kierowników Projektów branży IT stosujących metodykę PMBoK®, połączyło ją w sposób odruchowy z wodospadowym modelem wytwarzania oprogramowania, traktując go, jako jedyny i słuszny, w pełni wspierający procesy PMBoK®. Pomimo, iż metodyka PMBoK® od początku swojego istnienia nie narzuciła konkretnej metodyki, paradoksalnie stała się granicą w tym kontekście. Kolejne edycje przyniosły jednak znaczne zmiany, w zestawieniu z edycją z roku 2000, edycja trzecia stała się znacznie bardziej otwarta. Wyraźnie mówi, że: „Nie istnieje jeden, idealny model cyklu życia projektu” oraz jasno wskazuje, że to Kierownik Projektu, we współpracy z zespołem projektowym, jest zawsze odpowiedzialny za ustalenie odpowiednich procesów oraz stopnia rygorystyczności każdego procesu w danym przedsięwzięciu. Stanowi to doskonałą podstawę dla praktyk zalecanych przez Agile, które mogą nawiązywać do najlepszych praktyk omawianych w PMBoK®.

Próbując wypracować nowy cykl życia projektu, zgodny z metodyką PMBoK®, należy przyjrzeć się jego definicji, która mówi, że jest to „zbiór etapów projektu przeprowadzonych na ogół w określonym porządku”, a etapy projektu (zwane również fazami) wykonuje się na ogół sekwencyjnie. I to właśnie słowo „sekwencyjnie” stanowi najczęściej punkt blokujący, prowadzący do częstej nadinterpretacji, że sekwencyjny = kaskadowy (wodospadowy). Metodyka Agile również posiada sekwencyjne fazy projektu, zwane iteracjami, gdzie dostarczanym produktem każdej iteracji (fazy) jest działający kod programu. Natomiast, standardowo wykonywane sekwencyjnie procesy takie jak: analiza, projektowanie, implementacja i testy są wykonywane w ramach każdej iteracji.

W projektach zwinnych, proces planowania jest częścią pierwszej iteracji (etap początkowy), a dostarczanym produktem jest wysoko poziomowy plan projektu [3]. Fazy pośrednie są rozumiane jako wydania i/lub iteracje, gdzie dodatkowe funkcjonalności są dostarczane w postaci działającego kodu. Ostatnia faza projektu zwinnego to przekazanie gotowego produktu, w fazie tej w przeciwieństwie do tradycyjnego cyklu, wszystkie czynności związane z przygotowaniem systemu do wdrożenia są już zakończone. Następuje tu przegląd projektu oraz inne procesy kończące projekt.

Jednym z podstawowych warunków cyklu życia projektu według PMBoK® jest stwierdzenie, że każdy kolejny etap projektu wyznaczony jest przez ukończenie i zatwierdzenie jednego lub więcej produktów cząstkowych, które są wymiernymi, konkretnymi i sprawdzalnymi rezultatami lub przedmiotami. Sformułowanie takie może budzić pewne wątpliwości czy procesy zwinne są zgodne z tą definicją. Jeżeli jednak zinterpretujemy zatwierdzenie i przekazanie produktu, jako zatwierdzenie i przekazanie inkrementacji działającego kodu do klienta, to możemy stwierdzić, że Agile nadal pasuje do definicji zawartej w PMBoK®. Kolejnym istotnym warunkiem, jaki powinny spełniać poszczególne fazy cyklu życia projektu, jest rozpoczęcie każdej fazy procesem inicjowania, w którym należy zdefiniować dokładnie, jakie produkty cząstkowe zostaną dostarczone w danym etapie. Faza powinna zakończyć się formalnym przeglądem oraz zostać zatwierdzona w celu przejścia do fazy następnej, lub powinna zostać podjęta decyzja o zatrzymaniu projektu. Zwinny cykl życia projektu spełnia te warunki, kolejne iteracje są inicjowane przez klienta w sposób nieformalny lub formalny w zależności od kontraktu. Każda iteracja rozpoczyna się jej zaplanowaniem w celu zdefiniowania jakie funkcjonalności powinny zostać wykonane, jak również kończy się jej przeglądem w celu wyciągnięcia wniosków i uczenia się oraz w celu uzyskania akceptacji od klienta, co do zaimplementowanych funkcjonalności.

Na poniższym rysunku przedstawiono sposób mapowania cyklu życia zilustrowanego w PMBoK® na cykl życia projektu zgodnego z Adaptive Project Framework. Mapowanie to można określić jako rekurencyjne. Jak zilustrowano projekt zwinny może składać się z dowolnej liczby wydań (ang. Release), każde wydanie z kolei może składać się z dowolnej liczby iteracji, w których to zespoły wytwarzają kolejne inkrementacje kodu. Każda z przedstawionych faz składa się z trzech kluczowych etapów, inicjalizacji, w której głównym procesem jest planowanie, faz pośrednich oraz fazy końcowej, w której najważniejszą rolę odgrywają procesy związane z akceptacją produktów oraz przeglądem projektu.
 

Zwinny projekt, oparty na wartościach Agile Manifesto, powinien składać się z kolejnych wydań (ang. Release), lub kolekcji iteracji w celu podzielenia niezbędnej do wykonania pracy, na mniejsze, łatwiej zarządzalne „paczki”. Metodyka PMBoK® traktuje wydania jako fazy. Zwinny projekt rozpoczynają procesy tworzenia wizji, mapy produktu oraz definicji listy funkcjonalności, które powinny zostać zaimplementowane (tzw. product backlog). Procesy te można porównać do procesów Tworzenia Karty Projektu (PMBoK® – 4.1), oraz Tworzenia Wstępnej Deklaracji Zakresu Projektu (PMBoK® – 4.2). Kolejne procesy porównać można z procesami Opracowania Planu Kierowania Projektem (PMBoK® – 4.3), w których to należy zdefiniować dla projektu zwinnego między innymi: środowisko, szablony dokumentacji, standardy kodowania itd.
Etapy pośrednie projektu zwinnego to wydania, które składają się z kilku iteracji, i które można traktować w projekcie jako kamienie milowe, z tym, że w projekcie zwinnym takie kamienie milowe oznaczają dostarczenie zbioru działających funkcjonalności.
Końcowym procesem projektu zwinnego jest proces związany z przeglądem projektu, który angażuje cały zespół projektowy, interesariuszy projektu oraz klienta. Jego celem jest przejrzenie całości projektu, zarówno pod kątem pozytywnych i negatywnych aspektów związanych z prowadzeniem projektu w celu usprawnienia sposobu zarządzania przyszłymi projektami. Kolejne procesy ostatniego etapu można utożsamić z procesem Zamknięcia Projektu (PMBoK® – 4.7), które obejmują typowe czynności administracyjne.

Zwinne wydanie składa się z kilku iteracji, które w PMBoK® określone są jako podetapy. Zazwyczaj, w projektach zwinnych zaleca się stosowanie kwartalnych okresów wydań, składających się z kilku iteracji. Planowanie Wydania to proces rozpoczynający wydanie, który zazwyczaj trwa jeden lub dwa dni i angażuje cały Zespół Projektowy. Rezultatem takiego planowania jest plan wydania zawierający zbiór celów wydania oraz podstawowych założeń, które mają prowadzić zespół projektowy do sprawnego dostarczenia wartości klientowi. Plan wydania luźno nawiązuje do harmonogramu projektu, ograniczając się jedynie do aktualnego wydania, szczególnie w projektach długoterminowych. W projektach krótkoterminowych plan wydania może być równoważny z planem projektu.
Fazy pośrednie wydania to kolejno następujące po sobie iteracje, natomiast faza końcowa stanowi przegląd wydania.

Zwinna iteracja to jeden, stały przedział czasowy pracy o ściśle określonej dacie początkowej i końcowej, w którym zespół lub zespoły wytwarzają produkty. Zaleca się stosowanie iteracji trwających od tygodnia to sześciu tygodni. W tym okresie zespół wytwarzający produkty sam organizuje sobie codzienną pracę.
W momencie uzyskania zgody od klienta na rozpoczęcie kolejnej iteracji, zespół projektowy spotyka się w celu jej zaplanowania. W procesie tym uczestniczy klient lub jego przedstawiciel, który decyduje jakie funkcjonalności zostaną zaimplementowane w aktualnej iteracji. Następnie, zespół wytwarzający produkty dekomponuje funkcjonalności na poszczególne zadania oraz estymuje czas ich trwania. Materiałem wyjściowym planowania iteracji jest plan zawierający listę funkcjonalności do zaimplementowania w danej iteracji (ang. iteration backlog), plan uwzględnia także ryzyko, komunikację oraz założenia dodatkowe.
Przegląd iteracji stanowi ważny punkt zwinnego projektu, w którym podejmowane są decyzje odnośnie dalszego rozwoju produktu, a także mierzona jest wydajność zespołu oraz oceniany stan projektu. Uzyskiwana jest informacja zwrotna od klienta na temat zaimplementowanych funkcjonalności, jak również przegląda się proces wytwarzania produktu w celu weryfikacji, co idzie zgodnie planem a co wymaga usprawnienia.

Najniższy poziom zdekomponowanego cyklu życia projektu to codzienna praca, która reprezentowana jest przez zadania zaplanowane w iteracji. Zespół realizujący zadania sam organizuje sobie pracę i sposób realizacji zadań, dlatego zalecaną praktyką jest codzienne, krótkie spotkanie zespołów roboczych w celu synchronizacji pracy i kontroli wykonywanych zadań.

Zaproponowany powyżej cykl życia projektu, łączący tradycyjny – kaskadowy oraz zwinny – przyrostowy model wytwarzania oprogramowania, stanowi próbę pogodzenia praktyk opisanych w PMBoK® z wartościami głoszonymi przez Agile Alliance. Na każdym etapie cyklu życia projektu można zauważyć, że stosowanie praktyk zwinnych nie wyklucza możliwości stosowania procesów opisanych w PMBoK®, co więcej, metody zalecane w zwinnym cyklu życia projektu nie odbiegają od definicji zawartych w PMBoK®.
Jednym z nielicznych obszarów, w których Agile oraz PMBoK® nie zgadzają się, jest zaangażowanie klienta w trakcie trwania projektu [9]. W projekcie zwinnym oczekuje się, że klient lub jego przedstawiciel będzie brał aktywny udział w trakcie realizacji projektu przez cały czas jego trwania. Od momentu tworzenia wizji w procesie inicjowania projektu, poprzez kolejne wydania oraz planowanie i przegląd iteracji, aż do momentu ostatniego wydania i przekazania gotowego produktu, w pełni spełniającego oczekiwania klienta. PMBoK® natomiast stanowi, że możliwość wywierania wpływu przez interesariuszy projektu na końcowe właściwości produktu oraz ostateczny koszt jego realizacji są największe na początku przedsięwzięcia i w miarę jego realizacji maleją.
 

Zespół zarządzania projektem

Zespół Zarządzania Projektem jest w projekcie odpowiednikiem struktur zarządczych organizacji [5]. Od jego zaangażowania i decyzji na poziomie zarządzania strategicznego i operacyjnego zależeć będzie powodzenie projektu. W każdym projekcie wyróżnić można trzy strony: Biznes – czyli strona zainteresowana korzyściami wynikającymi z realizacji projektu, z reguły finansująca projekt, Użytkownik – strona, która będzie eksploatować wytworzone przez projekt produkty specjalistyczne oraz Wykonawca – strona, która te produkty wytworzy i dostarczy Użytkownikowi.

Metodyki tradycyjne opisują wzorcowe role i zakresy odpowiedzialności, zalecając ich dostosowanie do specyfiki projektu oraz profilu kompetencyjnego i psychospołecznego konkretnych osób. Zaleca się uzgodnienie opisu ról z zainteresowanymi stronami, w celu uzyskania akceptacji ich zrozumienia, oraz zaangażowania w ich pełnienie [4]. Jak opisano we wstępie pracy, zaangażowanie, to jeden z kluczowych czynników wpływających na sukces projektu. W celu zwiększenia zaangażowania stron projektu, metodyki tradycyjne definiują strukturę organizacyjną projektu zwaną Zespołem Zarządzania Projektem. Jest to trójpoziomowa struktura organizacyjna projektu, która określa trzy obowiązkowe role w projekcie: Komitet Sterujący, Kierownik Projektu oraz Zespoły techniczne.

Komitet Sterujący to organ 3 – 7 osobowy, złożony z przedstawicieli klienta i dostawcy. Przewodniczącym Komitetu jest przedstawiciel biznesowy klienta. Nazywany jest przedstawicielem uzasadnienia biznesowego projektu, co doskonale odzwierciedla jego funkcję. Poza przewodniczącym, w skład Komitetu Sterującego wchodzą jeszcze Główny Użytkownik oraz Główny Dostawca. Członkowie Komitetu Sterującego muszą mieć uprawnienia do przydziału zasobów i inicjowania dalszych prac. Podstawowy zakres odpowiedzialności Komitetu Sterującego to:

• Zatwierdzenie struktury i składu członków zespołu zarządzania projektem
• Sterowanie całością projektu
• Zapewnienie środków finansowych oraz zasobów ludzkich i rzeczowych
• Zatwierdzenie zmian w projekcie
• Przyjmowanie produktów projektu
• Całkowita i ostateczna odpowiedzialność za wyniki projektu

Podstawowe zadania Przewodniczącego Komitetu Sterującego:

• Określenie celów i zakresu projektu
• Określenie uzasadnienia biznesowego przedsięwzięcia
• Określenie ogólnych parametrów (czas, budżet, formuła realizacji)
• Przyjmowanie produktów projektu
• Zatwierdzanie istotnych zmian w projekcie
• Mediacja
• Zapewnienie niezbędnych zmian w organizacji klienta

Pozostałe role w Komitecie Sterującym odpowiadają przede wszystkim za specyfikację, wytworzenie i odbiór produktów specjalistycznych projektu. Główny Użytkownik reprezentuje interesy przyszłych odbiorców produktów projektu. Do jego podstawowych zadań należy:

• Specyfikacja potrzeb użytkownika
• Zapewnienie zasobów użytkownika
• Kontakty użytkownika z zespołem projektowym
• Monitorowanie zgodności produktów z wymaganiami

Główny Dostawca reprezentuje interesy dostawców produktów specjalistycznych, do jego zakresu odpowiedzialności należy:

• Wiedza, umiejętności, doświadczenie w zakresie projektowania, wytwarzania, dostarczania i wdrażania produktów projektu
• Zapewnienie niezbędnego wyposażenia i zasobów dostawców

Dodatkowo na wniosek Komitetu Sterującego może zostać powołany Nadzór Projektu, któremu Komitet Sterujący może przekazać zadania bieżącego nadzoru, jednak odpowiedzialność za nadzór nadal pozostaje po stronie Komitetu.

Kierownik Projektu zarządza projektem w warstwie operacyjnej. Zgodnie z metodykami tradycyjnymi, do podstawowego zakresu jego odpowiedzialności należy:

• Organizacja projektu (m. in. Mianowanie Kierowników zespołów i wsparcia projektu)
• Ogólne planowanie projektu
• Ustalenie standardów i zasad
• Kontrola postępu i koordynacja prac
• Raportowanie Komitetowi Sterującemu
• Prowadzenie i gromadzenie dokumentacji
• Realizacja zatwierdzonych zmian
• Eskalacja problemów
• Dostarczanie produktów do testów i odbioru
• Wyłączne reprezentowanie projektu na zewnątrz 

W metodyce PMBoK® Kierownik Projektu odpowiedzialny jest za większość procesów zarządczych. Po ustanowieniu projektu, Kierownik Projektu odpowiada za wszystkie procesy z grupy procesów planowania, realizacji, monitorowania i kontroli oraz zakończenia.

Kierownicy Zespołów mianowani są przez Kierownika Projektu. Poprzez zarządzanie Zespołami Roboczymi, zarządzają wytwarzaniem produktów specjalistycznych projektu. Ich zakres odpowiedzialności to:

• Pomoc w planowaniu projektu, określaniu produktów, testach, akceptacji
• Bezpośrednie kierowanie przebiegiem prac w zakresie specjalności
• Przydzielanie zadań specjalistom, rozliczanie z wyników
• Jakość dostarczanych produktów
• Raportowanie do Kierownika Projektu

Metodyki zwinne nie definiują struktury organizacyjnej zespołu w sposób szczegółowy, tak jak jest to zrobione w metodykach tradycyjnych. Zamiast tego Agile definiuje trzy podstawowe role projektu zwinnego wraz z ich zakresami odpowiedzialności. Wyróżnione role to: Właściciel Produktu (ang. Product Owner), Lider Zespołu oraz Zespół Projektowy.

Właściciel Produktu w metodykach zwinnych traktowany jest zarówno jako przedstawiciel uzasadnienia biznesowego, jak i główny użytkownik. Z punktu widzenia uzasadnienia biznesowego, odpowiada za zyskowność przedsięwzięcia. Z punktu widzenia produktów specjalistycznych projektu, odpowiada za definiowanie wymagań i wartości produktów. Odpowiada także za wizję produktu i przekazanie jej zespołowi projektowemu. Decyduje o kolejności implementowania funkcjonalności zgodnie z potrzebami. Jest także odpowiedzialny za utrzymywanie listy funkcjonalności (składników systemu) tzw. Product Backlog. Stanowi także główną rolę decyzyjną przy akceptacji lub odrzuceniu rezultatów prac zespołu projektowego.

Lider Zespołu, nazywany różnie w zależności od stosowanej metodyki (najczęściej ScrumMaster, metodyka Scrum opisana w rozdziale 3.2.1), zapewnia efektywność i produktywność. Do jego najważniejszych zadań należy zapewnienie ścisłej współpracy pomiędzy reprezentantami wszystkich funkcji i ról w zespole, a także poza nim. Zapewnia maksymalną produktywność zespołu, usuwając napotkane przez zespół przeszkody oraz osłaniając zespół przed czynnikami mogącymi zaburzyć jego pracę. Odpowiada za postępowanie zgodnie z praktykami zalecanymi przez metodyki zwinne. Jego rola nie jest typową rolą Kierownika Projektu, polegającą między innymi na wydawaniu poleceń oraz kontroli ich wykonania. ScrumMaster jest w większym stopniu doradcą oraz autorytetem na temat metodyki, pełni też funkcję doradcy dla Właściciela Produktu podczas dobierania elementów zapisanych na liście funkcjonalności.

Zespół Projektowy to samoorganizująca się, interdyscyplinarna, a przez to w dużej mierze samowystarczalna grupa. Zespół Projektowy ma prawo (i obowiązek) samodzielnie podejmować decyzje prowadzące do osiągnięcia celu iteracji. Grupa powinna być jednorodna pod względem hierarchii służbowej, a także, powinna być jednolita pod względem składu na cały czas trwania projektu (ewentualne zmiany zalecane tylko pomiędzy iteracjami / wydaniami).

Stosując zwinne techniki wytwarzania produktów w tradycyjnym projekcie IT, należy uwzględnić zmiany zakresu odpowiedzialności poszczególnych członków Zespołu Zarządzania Projektem, a także zmiany w procesie komunikacji w strukturach projektu, wynikające bezpośrednio z zakresów obowiązków.

 Istotną zmianą w strukturze organizacyjnej projektu jest połączenie roli Głównego Użytkownika oraz Przedstawiciela Uzasadnienia Biznesowego projektu. Metodyki tradycyjne nie wykluczają możliwości połączenia ról w strukturze Komitetu Sterującego. Praktyka pokazuje jednak, że ze względu na możliwość pojawienia się konfliktów interesów, nie zaleca się łączenia roli Głównego Użytkownika oraz Głównego Dostawcy, którego role w metodyce Agile przejmuje Lider Zespołu. Tak więc rola Właściciela Produktu, opisywana przez Agile nie wykracza poza zasady metodyk tradycyjnych, oraz dobrych praktyk z nimi związanymi. Kolejna zmiana dotyczy zarówno Kierownika Projektu jak i Kierowników Zespołów Roboczych. Metodyki spod znaku Agile nie wyróżniają w sposób bezpośredni żadnej z tych ról. Jak opisano powyżej, metodyki zwinne wyróżniają role Lidera Zespołu oraz Zespołu Projektowego (roboczego), jednak zakresy obowiązków oraz odpowiedzialności tych ról różnią się na tyle od ról Kierownika projektu oraz Kierowników Zespołów Roboczych i Zespołów Roboczych, opisanych w tradycyjnej strukturze organizacyjnej Zespołu Zarządzania Projektem, że nie można zmapować ich w sposób jawny do tej struktury. Jak przedstawiono na rysunku numer 12, rolę Lidera Projektu opisywaną przez Agile, można umieścić gdzieś pomiędzy Kierownikiem Projektu a Kierownikiem Zespołu. Natomiast obowiązki i część zakresu odpowiedzialności Kierowników Zespołów (niewystępujących w projektach zwinnych) zostały wchłonięte przez zwinny Zespół Projektowy (roboczy), który zgodnie z założeniami metodyki Agile, jest zespołem samowystarczalnym, mającym prawo podejmować decyzje.

Decyzję, odnośnie roli Lidera Zespołu, zwanego też ScrumMaster w metodyce SCRUM, czy będzie on bardziej Kierownikiem Projektu czy Kierownikiem Zespołu, należy podjąć indywidualnie dla każdego projektu. W przypadku projektów będących w przeważającej części ich organizacji zgodnych z metodykami tradycyjnymi, takimi jak PMBoK®, należy rozważyć opcję współpracy zarówno Kierownika Projektu jak i Lidera Zespołu zwinnego. W takim przypadku, rola Kierownika Projektu pozostaje w dużej mierze zgodna z rolą Kierownika Projektu tradycyjnego, natomiast Lider Projektu (ScrumMaster) przejmie obowiązki Kierownika Zespołu Roboczego, skupiając swoją uwagę, zgodnie z wybraną techniką, na zwinnym wytwarzaniu produktów i organizacji pracy Zespołu Projektowego. Natomiast, w przypadku projektów, które w przeważającej części skupiają uwagę na zwinnym prowadzeniu całego przedsięwzięcia, zgodnie z cyklem życia projektu omówionym przez Adaptive Project Framework, należy rozważyć możliwość połączenia roli Kierownika Projektu oraz Lidera Zespołu zwinnego (ScrumMaster). Taki połączony zakres obowiązków i odpowiedzialności Kierownika Projektu i Lidera Zespołu w dużej mierze upraszcza organizację projektu, wymagając przy tym samowystarczalnego oraz interdyscyplinarnego Zespołu Roboczego, którego prace nie będą w sposób ścisły kontrolowane przez Kierownika Zespołu.

Wytwarzanie zwinne - harmonogram oraz budżet

W projektach branży informatycznej szacowanie poszczególnych elementów projektu takich jak czas realizacji, pracochłonność, koszty, wydajność, zużycie materiałów i inne, jest przedsięwzięciem złożonym. Najistotniejszym przedmiotem szacowania projektu informatycznego, jest część dotycząca wytwarzania oprogramowania [5]. Szacowanie zadań związanych z implementacją oprogramowania jest zadaniem wymagającym współdziałania Kierownika Projektu z zespołami, które będą realizować te zadania. W projektach informatycznych, szacowanie nie jest tak oczywiste jak w naukach ścisłych, gdzie uwaga badaczy skoncentrowana jest wokół jednostki miary i metody powtarzalności pomiaru. Niejednokrotnie wymaga dostępu do informacji na temat podobnych przedsięwzięć lub jego fragmentów, aby można się posłużyć np.: techniką analogii.

W tradycyjnym podejściu do zarządzania projektami podstawą prac nad szacowaniem zadań jest opracowanie w miarę dokładnej struktury projektu, którą należy dekomponować do zadań, które realizują pojedyncze osoby lub specjalistyczne zespoły w stosunkowo krótkim czasie [4]. Uwzględniając informacje dotyczące nakładu pracy (ang. effort), czasu trwania zadania (and. durration) oraz obciążenia ludzi (ang. manpower loading), a także niezbędne informacje kosztowe, można posłużyć się metodami, które pozwalają na oszacowanie między innymi: prognozowanej pracochłonności, kosztów, złożoności oraz jakości. Nie istnieje uniwersalna metoda, która w zadowalający sposób określiła wszystkie te parametry, można się jednak posłużyć metodami takimi jak:

• Metoda Punktów Funkcyjnych – stosowana przede wszystkim do szacowania pracochłonności i jakości oprogramowania [7].
• Modele parametryczne, np.: COCOMO, znane jako najlepsze do szacowania kosztów [1].

Podstawowymi czynnikami, które w największym stopniu mogą wpłynąć na możliwość oszacowania czasu oraz kosztów wytwarzania oprogramowania są: wymagania klienta oraz technologia. Tradycyjne podejście, oparte na dekompozycji struktury projektu do poziomu zadań, może okazać się w przypadku projektów IT nie zawsze możliwe. Przedstawiony na rysunku 13 wykres obrazuje kompleksowość projektów IT w zależności od wymagań oraz stosowanej technologii [15]. Na osi pionowej umieszczono wymagania zdefiniowane przez klienta, które mogą znajdować się w przedziale od pewnych do niepewnych. Oś pozioma natomiast przedstawia stosowaną w projekcie IT technologię, która może zmieniać się w przedziale znana – nieznana. Wpływ tych dwóch czynników decyduje o złożoności projektu, a także o możliwości dokładnego oszacowania parametrów projektu. Złożoność projektu może zmieniać się w granicach od prostego, przez złożone do skomplikowanych, w których zarówno zdefiniowane wymagania są niepełne lub niepewne, jak i stosowana wytwarzanym oprogramowaniu technologia jest nieznana.

W przypadku projektów złożonych pod kątem wymagań jak i skomplikowanych technologicznie, doskonałą alternatywą mogą okazać się zwinne techniki wytwarzania oprogramowania. Nie wymagają one dokładnego szacowania całego projektu, gdyż zakładają możliwość zmiany wymagań oraz zakresu przez cały cykl życia projektu. Szacowania dotyczące kosztu oraz przybliżonego czasu trwania projektu bazują na tzw. opowieściach użytkownika. „Opowieści użytkownika” to technika opracowywania wizji produktu opartej na rejestrze produktowym (liście funkcjonalności). Poszczególnym funkcjonalnością przypisuje się punkty w określonej dla całego projektu skali, które na etapie planowania iteracji przekładają się na rzeczywisty czas realizacji oraz koszty.
 

Podsumowanie

Przeprowadzanie kompleksowych projektów IT, które wspierają kluczowe procesy biznesowe organizacji, wymaga stosowania sprawdzonych standardów zarządzania. Projekty informatyczne obarczone są dużym ryzykiem bardzo często wynikającym z braku dokładnego zdefiniowania zakresu lub jego częstych zmian. Stosowanie tradycyjnych metodyk zarządzania projektami może w takiej sytuacji spowodować wpadnięcie w pułapkę nieustannego rozwijania procesów, co dodatkowo może utrudnić realizację projektów.
W pracy przedstawiono tradycyjne oraz zwinne metodyki zarządzania projektami. Omówiono w sposób szczegółowy procesy metodyki PMBoK® związane z planowaniem, realizacją oraz monitorowaniem i kontrolą projektu. Przedstawiono tradycyjny cykl życia projektu oraz jego najczęściej spotykaną w projektach IT interpretację w postaci modelu kaskadowego. Następnie przedstawiono założenia zdefiniowane przez zrzeszenie Agile Alliance, które zaproponowało całkowicie odmienne podejście do prowadzenia projektów branży informatycznej. Omówiono najczęściej spotykane metodyki wywodzące się z nurtu Agile oraz przedstawiono zalecany przez Agile iteracyjny cykl życia projektu.

Przedstawione tradycyjne oraz zwinne metodyki zarządzania projektami posłużyły jako punkt odniesienia w trakcie analizy możliwości połączenia obu metodyk. Określono podstawowe różnice w sposobie zarządzania projektem zwinnym oraz tradycyjnym, wskazano główne zmiany jakie zaszły w zakresie definiowania ról oraz kompetencji w zespołach projektowych.

Do jednych z najważniejszych osiągnięć pracy można ponadto zaliczyć wskazanie możliwości połączenia tradycyjnego podejścia do zarządzania projektem z możliwościami zwinnego wytwarzania produktów IT. Bazując na dwóch kluczowych obszarach wiedzy zdefiniowanych przez metodykę PMBoK®, zaproponowano zmiany jakie należy wprowadzić w głównych grupach procesów zarządczych, tak aby można było wytwarzać produkty projektu w sposób zwinny, zgodny z wartościami Agile. Omówiono obszar wiedzy związany z Integracją Projektu oraz Zarządzaniem Zakresem projektu. Wskazano główne punkty styku, w których techniki lekkie są w pełni zgodne ze standardami proponowanymi przez PMBoK® oraz podstawowe rozbieżności w obu podejściach wraz z możliwymi kompromisami. Zaproponowano również nowy cykl życia projektu zgodny zarówno z definicją zawartą w metodyce PMBoK® oraz z wartościami technik lekkich. Co więcej, omówiono również podstawowe zmiany jakie powinny zajść w tradycyjnym Zespole Zarządzania Projektem w przypadku stosowania zwinnych technik wytwarzania produktów. Omówiono nowe zakresy kompetencji i odpowiedzialności członków zespołu projektowego.

Przydatnym z praktycznego punktu widzenia może okazać się również przykładowe zastosowanie zaproponowanego modelu zarządczego w projekcie branży IT. Przeprowadzona analiza oraz wstępne planowanie projektu wskazuje kluczowe aspekty na które należy zwrócić uwagę w przypadku stosowania nowego modelu zarządczego.

Przedstawione we wstępie pracy badania The Standish Group obrazują, że pomimo istnienia przyjętych standardów zarządzania projektami, nadal znaczna większość projektów kończy się niepowodzeniem lub niepełnym sukcesem. Badania te miały na celu znalezienie podstawowych przyczyn niepowodzeń projektów, spośród których wyróżniono trzy główne czynniki sukcesu projektu: zaangażowanie klienta (15,9%), wsparcie kierownictwa (13,9%) oraz jasno określone wymagania (13,0%). Przedstawione wyniki wpłynęły na popularyzację lekkich technik zarządzania projektami branży IT, których podstawowym założeniem jest organizowanie projektów w sposób pozwalający na szybkie i elastyczne wytwarzanie oprogramowania, oraz możliwość szybkiego reagowania na zmiany w projekcie.

Techniki zwinne pozwalają na weryfikację tradycyjnych procesów zarządzania projektem pod kontem możliwości reagowania na zmiany. Coraz większa popularność zwinnych metodyk takich jak SCRUM czy XP, świadczy o potrzebie zmian w tradycyjnych procesach zarządzania projektami oraz w sposobie organizacji zespołu projektowego. Możliwość połączenia metodyk tradycyjnych oraz zwinnych może przynieść znaczne efekty odzwierciedlone w skuteczności prowadzenia projektu oraz zadowoleniu klienta, dostarczając mu wartościowe produkty, w znacznie krótszym czasie.

Literatura

[1] Boehm W.B. and all, Software cost estimation with COCOMO II, Prentice-Hall, July 2000
[2] Bradley K., Podstawy metodyki PRINCE2, Centrum Rozwiązań Menedżerskich S.A., 2004
[3] Chin G., Agile Project Management: How to Succeed in the Face of Changing Project Requirements, AMACOM, 2004
[4] Dałkowski B., Hołodnik K., Podstawy zarządzania projektami. Organizacja projektu, Get Manager 2006., Materiały prezentacyjne, Politechnika Wrocławska Centrum Kształcenia Ustawicznego
[5] Frączkowski K., Zarządzanie projektem informatycznym. Projekty w środowisku wirtualnym. Czynniki sukcesu i niepowodzeń projektów, Oficyna Wydawnicza Politechniki Wrocławskiej, 2003
[6] Highsmith J., APM: Agile Project Management, Jak tworzyć innowacyjne produkty, Edycja polska, Wydawnictwo Mikom, 2005
[7] IFPUG, International Function Point Users Group, Function Point Counting Practices Manual, Release 3.0, IFPUG, Werterrille, Ohio, 1990
[8] Kuliński R., Inicjowanie i prowadzenie projektów innowacyjnych w firmie, 4PM, 2008
[9] Larman C., Agile and Iterative Development: A Manager's Guide, Addison Wesley Professional, 2003
[10] Lisowski, Z., Technologia informacyjna, Wikipedia, 2007, http://pl.wikipedia.org/wiki/Technologia_informacyjna
[11] PMR Publications, Rynek IT w Polsce 2008. Prognozy na lata 2008 - 2012, 2008, http://www.pmrpublications.com/press_room/pl_Ponad-16_-wzrost-rynku-IT-w-Polsce.shtml
[12] Project Management Institute, PMBOK Guide Third Edition – Kompendium wiedzy o zarządzaniu projektami, MT&DC, 2006
[13] Robert M., Micah M., Agile – Programowanie zwinne, Helion, 2008
[14] Schmidt P., Projekty Softwareowe, Grupa PM, 2009
[15] Schwaber K., Agile Project Management with Scrum, Microsoft Press, 2004
[16] Sliger M., Broderick S., The Software Project Manager's Bridge to Agility, Addison Wesley Professional, 2008
[17] Szyjewski Z., Metodyki zarządzania projektami, Wydawnictwo Placet, Warszawa, 2004
[18] Tomkiewicz, M., IT spotyka się z biznesem, Computerworld, 2008, Nr 42/835
[19] Westland J., Project Management Lifecycle, Kogan Page, 2006