Zadzwoń do nas (+48) 781 006 800 lub napisz: kontakt@whitecom.com.pl

Szukasz szkolenia?

Kierownik projektu

Najbliższe szkolenia

Obecnie znajdujesz się w:

Stopka

Aktualności

Informacje o firmie

Jesteśmy firmą koncentrującą się na specyficznych potrzebach naszych klientów. Naszym priorytetem jest wybór jak najlepszych rozwiązań zapewniających podniesienie efektywności działania organizacji klienta.

Firma WHITECOM Sp. z o. o. korzysta z Tarczy Finansowej Polskiego Funduszu Rozwoju 2.0.

Więcej informacji

Aktualności

Agile - iteracyjny proces zarzadzania projektami

2012-11-06

W Polsce od pewnego czasu bardzo popularny stał się termin projekt. Terminem projekt określa się każdą zmianę w systemach IT to projekt, modernizację jednego pomieszczenia, ustalenie dwóch szkoleń z klientem etc. Podobnie na popularności zyskuje Agile jako metodyka prowadzenia projektów.

I mówimy tutaj nie tylko o podejściu do realizacji projektu budowy/rozwoju oprogramowania, ale mówimy również o koncepcji zarządzania projektami. Popularność elastycznego podejścia sprawia, ze coraz więcej organizacji zaczyna poszukiwać informacji i "przestawiać się” na podejście Agile, coraz więcej kierowników projektów poszukuje szkoleń z tej tematyki, a certyfikacja PMI poświęcona Agile stała się hitem PMI^® z ponad 1400 osobami na całym świecie, które zdobyły ten tytuł w ciągu kilku ostatnich miesięcy.

Czy w takim razie przyszłość zarządzania projektami to Agile?

I tu dochodzimy do ciekawej dyskusji, która miała miejsce po jednym z seminarium PMI^® w Warszawie, podczas której zwolennik każdej z metodyk (PMBOK^® Guide, Prince2, podejścia Agile) był w stanie udowodnić i przytoczyć bardzo merytoryczne argumenty, dlaczego dany typ projektu da się zrealizować w "jego metodyce". Ja nie będę próbował przekonywać Was do konkretnej z w/w, ale ponieważ najczęściej działam na case study, dlatego przedstawię przykład:

Jedna z firm, która wdrażała system informatyczny tworzony przez wewnętrzny zespół IT, miała narzucony termin zakończenia projektu ze względu na zależności z innymi projektami. Prace w projekcie realizowane były z wykorzystaniem podejścia Extreme programming, tj. użytkownik biznesowy na bardzo niskim poziomie definiował co programista ma wykonać. Podejście było bardzo efektywne jeżeli chodzi o wykorzystanie poszczególnych programistów, ponieważ użytkownik biznesowy co 1 do 3 dni definiował nowe zadania dla zespołu. Niestety taki sposób nie pozwala na odpowiedzenie na podstawowe pytanie: na kiedy skończymy projekt, czy aktualny zespół jest wystarczający do realizacji tego przedsięwzięcia, itd. Dlatego zespół podjął decyzje o zastosowaniu podejścia Agile i… PMBOK^®! Zastosowanie dwóch podejść nie było spowodowane potrzebą przetestowania nowego podejścia w IT (co jest bardzo modne), ale celem była odpowiednia koordynacja i delegowanie uprawnień do zarzadzania projektem.

W efekcie zdecydowano, że z punktu widzenia Komitetu Sterującego potrzebne jest zwymiarowanie parametrów całego projektu i tutaj:

określono na wysokim poziomie koncepcje harmonogramu realizacji projektu,
określono zespół i parametr pracochłonności projektu dostępnej dla kierownika projektu na fazę realizacji przedsięwzięcia,
określono strukturę organizacyjną zespołu dedykowaną do tego projektu,
zdefiniowano strukturę podziału prac,
określono budżet na fazę realizacji,
określono sposób oceny stopnia realizacji całego systemu dostarczanego w ramach projektu.

Powyższe elementy stanowiły minimum niezbędnych informacji do monitorowania statusu i przewidywania końca realizacji projektu.

Dlaczego w takim razie to podejście nie było wystarczające do realizacji projektu? Głownie z dwóch powodów:

projekt został już w organizacji uruchomiony i nie było dokumentacji wymagań (a tworzenie jej aktualnie zajęłoby minimum 6 miesięcy) oraz
projekt był uzależniony od innych ważniejszych projektów, dlatego co chwili zmieniała się koncepcja lub terminy realizacji poszczególnych elementów systemu.

Firma postanowiła, ze dalsza część realizacji projektu zostanie wykonana w iteracjach, gdzie co miesiąc będzie planowany zakres prac w danym obszarze systemu na podstawie priorytetów wymagań (które powstawały na bieżąco) oraz z uwzględnieniu limitów pracochłonności dostępnej na cały projekt.

Codzienna praca dalej odbywała się z zachowaniem elementów extreme programming, gdzie użytkownik biznesowy na podstawie oglądania wyników prac zespołu IT, definiował następne elementy do wykonania.

Czy w takim razie warto rozwijać swoją wiedzę i wiedzę organizacji w tym zakresie?

Krótko podsumowując, jako kierownicy projektu musimy znać wiele metodyk i podejść, aby dopasować model zarzadzania projektem do specyfiki i skali projektu, podejścia organizacji, ilości uczestników oraz podwykonawców. I do tego zdecydowanie zachęcam...

Maciej Bodych

PMI^®, PMP^®, CAPM^®, PMI-ACP^®, PgMP^®, PfMP^®, PMI-RMP^®, PMBOK^® Guide are registered marks of the Project Management Institute, Inc.
PMI^® Registered Education Provider logo is registered mark of the Project Management Institute, Inc.

Czym jesteś zainteresowany?
Email:
Nr tel:
Imię i nazwisko:
Treść wiadomości

Najbliższe szkolenia

Informacje o firmie

Aktualności

Agile - iteracyjny proces zarzadzania projektami

Zaproś nas