Kryteria wyboru metod zarzČdzania projektami informatycznymi

Problemy ZarzÈdzania, vol. 10, nr 3 (38): 25 – 40
ISSN 1644-9584, © Wydziaï ZarzÈdzania UW
DOI 10.7172.1644-9584.38.2
Kryteria wyboru metod
zarzÈdzania projektami informatycznymi
Witold Chmielarz
Zasadniczym celem niniejszego artykuïu jest identyfikacja metod zarzÈdzania projektami informatycznymi wĂród tradycyjnych i nowoczesnych. W ostatnich latach podejĂcie do zarzÈdzania projektami systemów informatycznych
ulega szybkim i wielokierunkowym przemianom. Klasyczna teoria projektowania i obecna pragmatyka coraz bardziej siÚ rozmijajÈ. Wydaje siÚ, ĝe zastosowanie lekkich metod projektowania przynajmniej czÚĂciowo minimalizuje
powstajÈce róĝnice. Przeprowadzona analiza stara siÚ wyjaĂniÊ zaistniaïe wbtym
zakresie wÈtpliwoĂci oraz pokazuje, jak wybraÊ wïaĂciwÈ metodÚ dla okreĂlonego przypadku zarzÈdzania projektem.
1. Wprowadzenie
ZarzÈdzanie projektami informatycznymi jest istotnÈ, wiodÈcÈ czÚĂciÈ
zarzÈdzania projektami i najczÚĂciej utoĝsamiane jest z analizÈ i projektowaniem systemów informatycznych oraz tzw. inĝynieriÈ oprogramowania.
KategoriÈ najszerszÈ – z teoretycznego punktu widzenia – jest tu zarzÈdzanie
projektami utoĝsamiane z okreĂlonÈ dziedzinÈ naukowÈ, opartÈ na rozwiÈzaniach teoretycznych problemów praktycznych wynikajÈcych „z koniecznoĂci zaspokojenia zanalizowanych wymogów zleceniodawcy przy pomocy
dostÚpnych umiejÚtnoĂci, wiedzy, metod, technik i narzÚdzi realizacyjnych”
(Mingus 2009: 21).
Jest to wiÚc nauka o skutecznym osiÈganiu zakïadanych celów przy
pomocy racjonalnego uĝycia zasobów (ludzkich, finansowych, materialnych
itp. i relacji miÚdzy nimi) w zakïadanym czasie. Podmiotem zarzÈdzania
projektami jest niewÈtpliwie projekt, który moĝe dotyczyÊ unikalnych przedsiÚwziÚÊ realizowanych w róĝnych branĝach, sektorach, w róĝnym czasie,
zakresie, za pomocÈ róĝnych Ărodków czy zespoïów, w okreĂlonej strukturze organizacyjnej, instytucjonalnej itd. Na rozwój tej dziedziny naukowej
najwiÚkszy jednak wpïyw miaïy projekty informatyczne – ze wzglÚdu na
ich wielkoĂÊ, zïoĝonoĂÊ, innowacyjnoĂÊ, ryzyko, wysokie koszty realizacji
i zwiÈzanÈ z tym koniecznoĂÊ zarzÈdzania nie tylko wymienionymi elementami, ale równieĝ relacjami pomiÚdzy nimi. ZarzÈdzanie projektami
informatycznymi jest pojÚciem najszerszym, obejmujÈcym wszystkie aspekty
vol. 10, nr 3 (38), 2012
25
Witold Chmielarz
tworzenia, wdroĝenia i wykorzystania systemów informacyjnych wspomagajÈcych zarzÈdzanie, zarówno od strony praktycznej, jak i teoretycznej.
Inĝynieria systemów informatycznych koncentruje siÚ na technologicznych
aspektach tych procesów. Analiza i projektowanie systemów informatycznych – zïoĝony proces organizacyjny – skupiony jest na pierwszych, gïównie informacyjnych, ale kto wie, czy nie najwaĝniejszych fazach cyklu ĝycia
systemu informatycznego. Cykl ĝycia systemu informatycznego jest tu, jak
siÚ wydaje, kategoriÈ kluczowÈ, wystÚpujÈcÈ we wszystkich rozpatrywanych
obszarach metodycznych.
Cykl ĝycia systemu informatycznego jest w nich traktowany jako sekwencja etapów (faz) czynnoĂci wzorowanych na ĝyciu organizmów, którego
ostatecznym celem jest budowa, wdroĝenie, modyfikacje i wycofanie (lub
zastÈpienie) systemu informatycznego, poczÈwszy od pierwszego pomysïu na
ten temat (narodziny) po jego likwidacjÚ (ĂmierÊ). Idea cyklu ĝycia (projektu,
systemu, procesów inĝynierii) jest w tych wszystkich koncepcjach toĝsama,
róĝnice wystÚpujÈ w liczbie i nazewnictwie etapów (faz), ich kolejnoĂci
logicznej lub zrównolegleniu i nastÚpstwie oraz relacjach z otoczeniem,
szczególnie z uĝytkownikiem finalnym. Róĝnice te nasiliïy siÚ w ostatnim
dziesiÚcioleciu, wraz z momentem rozpoczÚcia szerokiego stosowania tzw.
metodyk lekkich (zwinnych – agile). Identyfikacja tych róĝnic wraz z wynikajÈcymi z nich konsekwencjami jest gïównym celem niniejszego artykuïu.
2. Ogólna charakterystyka
metod ciÚĝkich (tradycyjnych)
projektowania systemów informatycznych
W cyklu ĝycia systemu informatycznego wyróĝnia siÚ przewaĝnie poszczególne etapy (fazy), z których czÚĂÊ moĝe wystÚpowaÊ sekwencyjnie lub równolegle, jednokrotnie bÈdě wielokrotnie. W tworzeniu modeli cyklu ĝycia
projektu wyróĝnia siÚ metodyki:
– ciÚĝkie (klasyczne, tradycyjne), takie jak kaskadowa (liniowa), przyrostowa, ewolucyjna, baz danych, prototypowa, spiralna;
– lekkie (nowoczesne, zwinne – agile), takie jak XP (eXtreme Programming),
Scrum, Feature Driven Development (FDD), Dynamic System Development Method (DSDM) czy Adaptive Software Development (ASD)1.
W kanonicznej (podstawowej, funkcjonujÈcej jako punkt odniesienia)
wersji projektowania systemów informatycznych cykl ĝycia skïada siÚ zbnastÚpujÈcych etapów2:
– inicjacji, wstÚpnego rozpoznania systemu (wykonalnoĂci, strategia rozwoju organizacji, identyfikacja systemu, analiza moĝliwoĂci informatyzacji, postawienie problemu) – polegajÈcego na: identyfikacji celu, problemów, stanu obecnego i perspektyw (w tym ryzyka wykonalnoĂci) rozwoju
systemu informacyjnego lub jego zmian;
26
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
– analizy informacyjnej systemu – na którÈ skïada siÚ identyfikacja otoczenia, ïÈcznoĂci z otoczeniem, podsystemów, skïadowych systemu oraz
obecnych i przyszïych warunków jego dziaïania;
– projektowania (technicznego) systemu – koncentrujÈcego siÚ na uszczegóïowieniu zaïoĝeñ analitycznych, stworzeniu modelu logicznego i fizycznego przyszïego systemu lub ewentualnych zmian w funkcjonowaniu
obecnego systemu;
– oprogramowania systemu (kodowania, implementacji) – polegajÈcego na
oprogramowaniu modelu fizycznego, konstrukcji programu lub zestawu
wspóïpracujÈcych ze sobÈ programów (systemu informatycznego);
– testowania – czyli sprawdzenia pod wzglÚdem semantycznym, technicznym i merytorycznym prawidïowoĂci funkcjonowania systemu;
– wdroĝenia (zastosowania, aplikacji) – tj. uruchomienia (instalacji) ibzainstalowania systemu u uĝytkownika koñcowego, zaïadowania systemu parametrami niezbÚdnymi do jego funkcjonowania, podïÈczenia do aktualnych ěródeï danych, ostatecznego szkolenia uĝytkownika koñcowego;
– eksploatacji (realizacji) – sprowadzajÈcej siÚ do uruchomienia uĝytkowego, monitoringu, oceny i modyfikacji systemu;
– wycofania (zakoñczenia dziaïalnoĂci) systemu – po badaniu opïacalnoĂci
opracowania procedury przejĂcia na nowy system informatyczny zachowujÈcy maksymalnie moĝliwÈ iloĂÊ pozytywnych cech starego systemu.
Etapy i fazy modelu kanonicznego wystÚpujÈ w róĝnych postaciach,
wariantach i rozwiniÚciach zarówno w metodach tradycyjnych, jak i nowoczesnych. Podstawowa równica pomiÚdzy nimi polega – zgodnie z jednym
podejĂciem (Chmielarz 2010: 359–402) – w zasadzie na tym, ĝe:
– w metodach tradycyjnych realizowane sÈ kolejne etapy cyklu ĝycia, wbtym
planowanie funkcjonalnoĂci (zakresu) wraz z niezbÚdnymi dla nich zasobami (materiaïowymi, ludzkimi, informacyjnymi) oraz przypisanym im
budĝetem;
– w metodach nowoczesnych nastÚpuje koncentracja na funkcjonalnoĂciach,
w trakcie realizacji których na bieĝÈco ustalane sÈ (na ogóï w porozumieniu z uĝytkownikiem) zasoby i budĝet niezbÚdne do ich realizacji.
Inni autorzy twierdzÈ (Mannaro 2008), ĝe róĝnice te wyraĝajÈ siÚ wbpodejĂciu przez metodyki tradycyjne i nowoczesne do problematyki zarzÈdzania
zmianÈ. W metodyce tradycyjnej wyraĝa siÚ ono (na ogóï) przyjÚciem ukrytego
zaïoĝenia, ĝe moĝliwe jest osiÈgniÚcia zaïoĝonego celu w trakcie jednego
podejĂcia, którego parametry sÈ ustalane a priori na poczÈtku cyklu. Dlatego
metodyka ta jest najlepsza w tych projektach, które sÈ stabilne, tzn. takie,
w których nie sÈ przewidywane zmiany wymagañ czy technologii w trakcie realizacji projektu. Alternatywnie, nowoczesne metodyki sÈ najbardziej
odpowiednie dla projektów, w których przewiduje siÚ wiele zmian podczas
realizacji. Nie skupiajÈ siÚ one na rozpoznaniu wymagañ i planowaniu dziaïañ,
gïownie na poczÈtku projektu dla caïego jego przebiegu, ale na rozpoznaniu
wymagañ i potrzebnych zasobów w trakcie realizacji zadañ szczegóïowych.
vol. 10, nr 3 (38), 2012
27
Witold Chmielarz
Niemniej jednak kanon postaci cyklu ĝycia projektowania systemów
informatycznych wywodzi siÚ z historycznego rozwoju metod zarzÈdzania
projektem informatycznym (szkóï strukturalnych, operacyjnych, obiektowych
i spoïecznych) z jednej strony i rozwoju technologii systemów z drugiej.
Byïy to procesy dïugotrwaïe, dynamiczne i radykalne – dlatego w teorii
lepiej i bardziej szczegóïowo sÈ zaprezentowane i opisane tradycyjne metody
projektowania.
Najbardziej znanym, najczÚĂciej uĝywanym i najbardziej charakterystycznym z modeli postÚpowania w metodach tradycyjnych byï model kaskadowy
(rysunek 1). Przyjmowano w nim nastÚpujÈce zaïoĝenia:
– na poczÈtku kaĝdego projektu istnieje stabilny zestaw potrzeb i wymagañ
informacyjnych uĝytkownika i celów, do których on dÈĝy;
– potrzeby nie zmieniajÈ siÚ w trakcie ĝycia systemu;
– proces budowy systemu odbywa siÚ stopniowo, dopiero po skoñczeniu
jednego etapu zaczynany jest nastÚpny;
– kaĝdy kolejny etap oznacza uszczegóïowienie i przybliĝenie do rzeczywistoĂci;
– powoduje to powrót do poprzednich etapów w momencie, gdy zostanie
wykryty bïÈd i powstanie koniecznoĂÊ jego korekty.
Niestety w rzeczywistoĂci juĝ zaïoĝenie pierwsze na ogóï siÚ nie sprawdza (uĝytkownicy nie majÈ sprecyzowanych na wstÚpie potrzeb), moĝe wiÚc
szybko nastÈpiÊ rozminiÚcie siÚ z potrzebami uĝytkownika. Ponadto jest
to bardzo droga kombinacja, poniewaĝ w przypadku realizacji przez firmÚ
informatycznÈ tylko jednego projektu w danym czasie oznacza koniecznoĂÊ
utrzymywania ekipy realizacyjnej czÚĂciowo bezrobotnej podczas realizacji
nastÚpnych etapów. Ponadto w rzeczywistoĂci czÚsto wystÚpuje nakïadanie
siÚ poszczególnych etapów na siebie. W tej sytuacji istniejÈ liczne modyfikacje tego podejĂcia.
Model kaskadowy nie jest jedynym, a tylko najprostszym modelem realizacji cyklu ĝycia projektu. Nie uwzglÚdnia wielu problemów, np. zarzÈdzania ryzykiem. Jego zaletÈ, dziÚki której jest lubiany i akceptowany przez
uĝytkowników, jest prostota rozwiÈzañ i fakt, ĝe staï siÚ podstawÈ innych
metodyk, np. ewolucyjnej czy przyrostowej.
Zaïoĝenia modelu ewolucyjnego byïy nastÚpujÈce:
– caïy system jest dzielony na moduïy;
– kaĝdy z nich odbywa przejĂcie przez kolejne fazy cyklu budowy systemu;
– na koñcu dziaïañ projektowych przystÚpuje siÚ do specjalnego etapu
polegajÈcego na integracji caïego systemu i przeprowadzeniu testów;
– w systemie podzielonym na czÚĂci, których realizacja jest przesuniÚta
wb czasie, ïatwiej nadÈĝaÊ za zmieniajÈcym siÚ celem dziaïania;
– poniewaĝ kaĝdy moduï stanowi poczÈtkowo organicznie odrÚbnÈ czÚĂÊ,
naleĝy zwróciÊ uwagÚ na niebezpieczeñstwo zwiÈzane z koniecznoĂciÈ
integracji moduïów w caïoĂÊ (bardzo czÚsto staje siÚ to gïównÈ przyczynÈ
niepowodzeñ realizacji projektu).
28
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
Wycofanie
Proces weryfikacji systemu
Eksploatacja
Postępy prac
Wdrożenie
Testy
Oprogramowanie
Projekt
Analiza
Rozpoznanie
Czas
Rys. 1. Schemat ideowy modelu kaskadowego. ½ródïo: opracowanie wïasne.
Jest to rozwiÈzanie tañsze w realizacji od poprzedniego, poniewaĝ moĝe
– po przesuniÚciu realizacji poszczególnych moduïów w czasie – byÊ obsïugiwane przez mniejszÈ liczbÚ personelu. Kiedy analitycy koñczÈ pracÚ nad
jednym moduïem, przechodzÈ do nastÚpnego, a ich miejsce zajmujÈ programiĂci. Model ewolucyjny niestety nie zawsze speïniaï pokïadane wb nim
nadzieje. Poszczególne podsystemy – dla duĝych projektów budowane przez
róĝne zespoïy – nawet pomimo tworzenia specjalnych procedur integracyjnych, nie zawsze w peïni dawaïy siÚ zintegrowaÊ ze wzglÚdu np. na róĝnÈ
wizualizacjÚ mechanizmów funkcjonowania. Brakowaïo w nich wyraěnie
spójnych zaïoĝeñ dla caïego systemu informatycznego. Dlatego wïaĂnie
model kaskadowy ewoluowaï dalej – do stworzenia modelu przyrostowego.
Model przyrostowy charakteryzowaï siÚ nastÚpujÈcymi zaïoĝeniami.
– przeprowadzane jest rozpoznanie i analiza dla caïoĂci systemu, dziÚki
której powstaje caïoĂciowa koncepcja wstÚpna systemu, poparta ogólnÈ
analizÈ caïego systemu;
– nastÚpnie system podzielony na moduïy realizacyjne jest projektowany,
programowany i testowany kolejno dla kaĝdego z nich przez dziedzinowe
zespoïy robocze wykonujÈce projekty techniczne dla kaĝdego moduïu
ib je testujÈce;
– spójnoĂÊ systemu zapewniajÈ pierwotne zaïoĝenia systemu oraz wspólne
koñcowe etapy instalacji i wdroĝenia, w których przeprowadzana jest teĝ
peïna integracja systemu.
Jest to procedura, podobnie jak poprzednia, najlepiej sprawdzajÈca siÚ
przy ograniczonych Ărodkach, którymi dysponuje zespóï realizujÈcy system.
Kaĝdy z podsystemów moĝe byÊ realizowany oddzielnie, caïy zespóï pracuje
jedynie na poczÈtku, podczas tworzenia caïoĂciowej koncepcji rozwiÈzania
systemu, oraz na koñcu, w trakcie integracji poszczególnych podsystemów
vol. 10, nr 3 (38), 2012
29
Witold Chmielarz
wbjednÈ organicznÈ caïoĂÊ. Procedura przyrostowa jest lepsza od ewolucyjnej,
poniewaĝ mechanizmy integracyjne dziaïajÈ zarówno na poczÈtku, jak i na
koñcu procesu tworzenia systemu. Na poczÈtku cyklu, oprócz rozpoznania
ibanalizy, tworzone sÈ takĝe wspólne normatywy i zasady wykonania projektu
kaĝdego moduïu. Uïatwia to póěniejszÈ integracjÚ na etapach koñcowych.
W cyklu ewolucyjnym oraz przyrostowym moĝna teĝ w ograniczony sposób
reagowaÊ na zmiany wymagañ uĝytkownika.
Zupeïnie odrÚbnÈ systematykÚ zakïada model tworzenia struktury baz
danych (Freya). W cyklu ĝycia opartego na tworzeniu struktury bazy danych
wyróĝnia siÚ na ogóï nastÚpujÈce fazy:
– rozpoznania i analizy – gdzie nastÚpuje rozpoznanie i zebranie potrzeb
informacyjnych uĝytkowników;
– projektu technicznego, skïadajÈcego siÚ z dwóch etapów, dotyczÈcych
tworzenia projektu logicznego, czyli opisu modelu danych i przyszïych
procesów w systemie, oraz projektu fizycznego, czyli projektu struktury
bazy danych (zbiorów i relacji pomiÚdzy nimi), wzorców dokumentów,
technologii przetwarzania, specyfikacji wewnÚtrznych itp.;
– oprogramowania i testowania – polegajÈcego na stworzeniu bazy danych
i oprogramowanie zastosowañ (aplikacji) opartych na danych zawartych
w bazie danych oraz testowaniu oprogramowania;
– wdroĝenia – zainstalowania oprogramowania w okreĂlonej platformie
ibkonfiguracji sprzÚtowej i wprowadzenia parametrów okreĂlonych przez
uĝytkownika w celu kastomizacji i przygotowania systemu do eksploatacji;
– eksploatacji uĝytkowej i kontroli – polegajÈcej na roboczym uĝytkowaniu systemu oraz zapewnieniu poprawnoĂci z ustalonymi normatywami
i wymogami uĝytkownika;
– potencjalnych modyfikacji i adaptacji – czyli udoskonalenia funkcjonowania w wyniku pojawienia siÚ nowych potrzeb; w razie potrzeby powrót
do etapów poczÈtkowych.
Zasadnicza idea tego cyklu ĝycia polega na stworzeniu na poczÈtku
projektu struktury bazy danych systemu i oprogramowania bazy danych, co
umoĝliwia rejestracjÚ podstawowych faktów z ĝycia organizacji, a nastÚpnie
obudowanie bazy danych oprogramowaniem aplikacyjnym, które wykorzystuje dla róĝnych aplikacji te same dane zawarte w bazie danych do obsïugi
sprzedaĝy, dostaw, kontaktów z kontrahentami itp. W ten sposób powstawaïo i jest wykorzystywanych do dziĂ wiele zïoĝonych systemów opartych
na bazie danych. Jest to jednak metoda, gdzie uĝytkownik koñcowy rezultaty dziaïania projektanta i programisty oglÈda dopiero po uruchomieniu
bazy danych oraz pierwszych aplikacji. Dopiero wtedy moĝe teĝ sprawdziÊ
ich zgodnoĂÊ z zaïoĝeniami ustalanymi z zespoïem projektowym. Znacznie
szybciej uwidacznia siÚ to podczas zastosowania modelu prototypowego.
IstotÈ modelu prototypowego jest oprogramowanie na poczÈtku dziaïañ
projektowych – schematu dziaïania systemu, najlepiej razem z przyszïym
uĝytkownikiem. Cel takiego postÚpowania jest nastÚpujÈcy:
30
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
– redukcja czasu oczekiwania na rezultaty programowe i wykazanie siÚ
wobec uĝytkownika koñcowego uchwytnymi (dla niego) efektami realizacyjnymi;
– szybkie „sprzÚĝenie” uĝytkownika z zespoïem projektowym;
– ograniczenie liczby bïÚdów oraz iteracyjnych (potencjalnych) rozmów
zb uĝytkownikiem, np. na temat wizualizacji systemu;
– wiÚksze zaangaĝowanie uĝytkownika w analizÚ i projekt.
Model ten skïada siÚ z nastÚpujÈcych etapów:
– rozpoznania i analizy potrzeb uĝytkownika;
– projektu technicznego wraz z generacjÈ oprogramowania – w trakcie tego
etapu powstaje prototyp, który nastÚpnie jest sukcesywnie poprawiany
w interakcji z uĝytkownikiem;
– po testach kolejnych wersji prototypu i jego udoskonaleniach oraz instalacji system jest przeksztaïcany w wersjÚ ostatecznÈ, która przekazywana
jest do eksploatacji i – w miarÚ potrzeb – modyfikowana z uĝyciem
narzÚdzia, za pomocÈ którego zostaïa stworzona.
Sprawna realizacji systemu prototypowego wymaga zastosowania dobrego
oprogramowania klasy CASE (Computer Aided System Engineering), co
niestety powoduje, ĝe jego bezpoĂrednie i peïne zastosowanie bywa ograniczone poprzez wïasnoĂci tego narzÚdzia. A dodatkowo zwiÚksza koszty
projektu. Dlatego, pomimo niewÈtpliwych zalet tego podejĂcia, wielu projektantów i programistów woli stosowaÊ jedno z podejĂÊ klasycznych.
Najbardziej rozwiniÚtÈ formÈ tradycyjnego modelu cyklu ĝycia jest natomiast model spiralny. Fazy realizacji modelu spiralnego sÈ nastÚpujÈce:
– ustalenie celów dziaïania – dotyczy definicji konkretnego celu systemu
oraz uzasadniania koncepcji i ustalania planów jego realizacji; budowa
modelu rozpoczyna siÚ od inicjacji i definiowania projektu (ustalenia
wstÚpnych wymagañ), a nastÚpnie polega na analizie wstÚpnej ryzyka
realizacji projektu; na tej podstawie buduje siÚ pierwszy prototyp i tworzy
konceptualny plan (harmonogram) caïoĂci projektu;
– rozpoznanie i redukcja zagroĝeñ – po kolejnej fazie analizy ryzyka
pierwszego prototypu (identyfikacja najwaĝniejszych zagroĝeñ, ěródeï
ibsposobów zapobiegania zagroĝeniom) oraz zbadania ewentualnych alternatyw budowany jest nastÚpny prototyp projektu i tworzy siÚ wymagania
dotyczÈce ograniczeñ i zasobów projektu;
– tworzenie i zatwierdzanie – w tej fazie nastÚpuje proces rozwoju kolejnej
czÚĂci produktu, oparty na najbardziej odpowiednim modelu, wybranym
na podstawie oceny zagroĝeñ; kolejno powstaje plan realizacji projektu
i odbywa siÚ kolejny etap zakoñczony planem caïoĂci projektu;
– ocena i planowanie – to faza, w której recenzowany jest postÚp prac oraz
planowana jest kolejna bÈdě ostateczna faza projektu; ostatni obieg cyklu
przynosi projekt szczegóïowy, testy i realizacjÚ projektu oraz jego zamkniecie.
Model ten róĝni siÚ od pozostaïych wielokrotnym powtarzaniem poszczególnych faz podstawowego modelu cyklu ĝycia oraz – po kaĝdym „podcyklu”
vol. 10, nr 3 (38), 2012
31
Witold Chmielarz
– nastÚpuje dalsze uszczegóïowienie modelu oraz analiza ryzyka zakoñczonej
sukcesem wykonalnoĂci caïego systemu w danym momencie rozwoju. Jest
to najbardziej skomplikowany i najdroĝszy w realizacji model cyklu ĝycia
systemu informatycznego, stosowany do rozwiÈzywania najbardziej skomplikowanych i trudnych problemów tworzenia systemów, np. militarnych.
Tak jak inne modele klasyczne oparte na prototypowaniu i analizie ryzyka
najbardziej zbliĝony jest do podejĂcia nowoczesnego.
Grupa metodyk tradycyjnych istnieje od dawna. Reĝim, który nakïadajÈ
na rozwój projektu, dyscyplinuje w pewnym sensie sposób postÚpowania
wbtrakcie realizacji projektu. Nie daje to jednak gwarancji, ĝe projekt zakoñczy siÚ sukcesem. Metody te sÈ tak bardzo „sztywne” i ustrukturyzowane,
ĝe przestrzeganie wszystkich kroków, formuï i procedur znaczÈco spowalnia caïy proces rozwoju projektu. CharakteryzujÈ siÚ one nastÚpujÈcymi
cechami:
– Przewidywalne i powtarzalne podeĂcie do procesu rozwoju projektu. Wbklasycznych metodykach zakïada siÚ zwiÚkszajÈcÈ siÚ szczegóïowoĂÊ w miarÚ
realizacji poszczególnych faz i etapów rozwoju projektu i obejmowanie caïego okresu od poczÈtku do koñca projektu. Do analiz przeprowadzanych na bardzo niskim stopniu abstrakcji stosuje siÚ na ogóï
deterministyczne techniki szczegóïowe. Wynik uzyskany za ich pomocÈ
jest prawdziwy dopóki przynajmniej jedno z zaïoĝeñ poczÈtkowych nie
zostanie zmienione. Zakïada siÚ wiÚc deterministyczny, niezmieniany,
nieadaptowany i maïo elastyczny harmonogram, budĝet i zasoby oraz
budowany na tej podstawie peïen podziaï zadañ dla kaĝdego zespoïu
tworzÈcego produkt lub usïugÚ.
– Obszerna dokumentacja. Tradycyjne podeĂcie do realizacji projektu
zakïada, ĝe dokumentacja jest tworzona po kaĝdej fazie, kaĝdym etapie cyklu ĝycia projektu. W najbardziej konwencjonalnej formie modelu
kaskadowego przyjmuje siÚ, ĝe zakres oraz wymagania dotyczÈce uĝytkownika sÈ zbierane i ustalane w pierwszej fazie cyklu, a nastÚpnie na
ich podstawie tworzony jest produkt lub realizowana usïuga. Nie zmienia
siÚ tych zaïoĝeñ do koñca cyklu ĝycia projektu; czÚĂÊ zebranych i przeksztaïconych wbzalecenia wykonawcze informacji i dokumentów wymaga
przez to zmian w trakcie realizacji projektu.
– Zorientowanie na proces. Celem klasycznych metodyk jest w zasadzie okreĂlenie procesu czy procesów, które bÚdÈ uniwersalne i powtarzalne, czyli
bÚdÈ funkcjonowaïy w prawidïowy sposób i bÚdÈ przydatne dla kaĝdego,
kto bÚdzie ich uĝywaï, w kaĝdej sytuacji, w której wydadzÈ siÚ przydatne.
Kaĝdy proces skïadajÈcy siÚ z zadañ/czynnoĂci powinien byÊ wykonywany
wedïug okreĂlonych z góry procedur przez okreĂlonÈ, przypisanÈ do niego
i odpowiedzialnÈ za niego grupÚ pracowników/wykonawcÚ.
– Zorientowanie na narzÚdzia i techniki wspomagajÈce realizacjÚ. Do wykonania kaĝdego okreĂlonego w projekcie zadania powinny byÊ dostarczone
odpowiednie narzÚdzia wspomagajÈce zarzÈdzania.
32
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
3. PrzeglÈd lekkich (nowoczesnych) metod
projektowania systemów informatycznych
Na drugim biegunie znajdujÈ siÚ metody lekkie (zwinne – agile) projektowania. Ich zasadniczym celem jest maksymalne zwiÚkszenie wartoĂci
produktu w porównaniu z jego aktualnym stanem, przy zaïoĝonych kosztach i w okreĂlonym czasie. W ManifeĂcie rozwoju zwinnego oprogramowania
(Beck i in. 2010) zwraca siÚ uwagÚ na koniecznoĂÊ cenienia sobie bardziej
ludzi ibinterakcji pomiÚdzy nimi niĝ procesów i narzÚdzi, dziaïajÈcy rezultat
projektu ponad obszernÈ dokumentacjÚ, wspóïpracÚ z klientem ponad formalne ustalenia oraz reagowanie na zmiany ponad podÈĝanie za planem.
Odpowiada to postulatom wymienionych dotychczas zmian, które wynikajÈ
z ewolucji poglÈdów na same projekty i zarzÈdzanie nimi. Gïównym czynnikiem róĝniÈcym metody zwinne od tradycyjnych jest uznanie ludzi jako podstawowego czynnika sukcesu projektu, który poïÈczony jest z intensywnym
naciskiem na skutecznoĂÊ i uwzglÚdnienie zmian (Kendall i Kendall 1999).
Jest teĝ to swoista odpowiedě na wyzwania biznesowe powstaïe zb wyniku
uksztaïtowania siÚ szybko zmieniajÈcych siÚ globalnych rynków.
Poniĝej przestawione sÈ zaïoĝenia metodyk zwinnych, które traktowaÊ
moĝna równieĝ jako gïówne róĝnice pomiÚdzy tradycyjnymi metodykami
zarzÈdzania projektami (Awad 2005; Koszlajda 2010):
– Zorientowanie na interesariuszy projektu. Jest to wedïug tych metodyk
najwaĝniejszy czynnik zwiÈzany z rozwojem projektu (co zgadza siÚ
zb obserwacjami m.in. Standish Group) – najwaĝniejszym zadaniem dla
kierowników zespoïów „zwinnych” projektów jest to, ĝeby kïaĂÊ wiÚkszy
nacisk na ludzi wraz z ich umiejÚtnoĂciami, takimi jak: ambicje, zdolnoĂci, oraz na wzajemnÈ komunikacjÚ (Highsmith i Cockburn 2004). Jeĝeli
ludzie zaangaĝowani w projekt nie sÈ, wtedy ĝaden proces nie naprawi
ich nieadekwatnoĂci.
– AdaptacyjnoĂÊ (nieosiÈgalna idée fixe metod tradycyjnych). W tym podejĂciu kïadzie siÚ nacisk na zarzÈdzanie zmianÈ. Sprzyja to przekazaniu
uĝytkownikowi wïasnej wiedzy wiÚkszej niĝ minimalna zakïadana projektem (Sully 1993). ZarzÈdzanie zmianÈ zakïada ciÈgïÈ reakcjÚ na ciÈgïe
zmiany zachodzÈce w projekcie. Najtrudniejsze do oceny i reakcji sÈ
zewnÚtrzne zmiany Ărodowiskowe. Poniewaĝ nie jest moĝliwa ich eliminacja, naleĝy dÈĝyÊ do minimalizacji kosztów z nimi zwiÈzanych.
– ZgodnoĂÊ z rzeczywistoĂciÈ. Zwraca siÚ bardziej uwagÚ na zgodnoĂÊ
otrzymanych rezultatów z uzyskanymi wynikami projektu niĝ na zgodnoĂÊ zb wynikami poczÈtkowo zakïadanymi (zgodnoĂÊ nie z planem, ale
z zaïoĝeniami biznesowymi).
– ElastycznoĂÊ planowania. Podstawowym problemem planowania projektu jest brak moĝliwoĂci przewidzenia implikacji rozwoju planów
przedsiÚwziÚÊ innowacyjnych (wszystkie projekty powinny naleĝeÊ do
tej kategorii), poniewaĝ Ărodowisko, w którym powstajÈ, jest wysoce
vol. 10, nr 3 (38), 2012
33
Witold Chmielarz
–
–
–
–
–
34
dynamiczne. W „zwinnych” projektach wykonawcy muszÈ zastanowiÊ
siÚ, jak mogÈ uniknÈÊ nieodwracalnoĂci swoich decyzji wymuszonych
przyzwyczajeniem do praktyki szczegóïowego projektowania tradycyjnego, które prowadzi do daleko posuniÚtej szczegóïowoĂci. Zamiast
próbowaÊ podjÈÊ wïaĂciwe decyzje na poczÈtku kaĝdego cyklu (projektowanie tradycyjne), lepiej je podjÈÊ w taki sposób, ĝeby w nastÚpnych
etapach moĝna byïo je odwróciÊ.
Oparcie siÚ na procesach empirycznych. W metodach tradycyjnych procesy
wystÚpujÈ jako deterministyczne i liniowe, w metodach „zwinnych” jako
proces empiryczny (probabilistyczny, ěle lub sïabo ustrukturalizowany)
bÈdě nieliniowy. Proces deterministyczny to taki, w którym od rozpoczÚcia do zakoñczenia moĝna za kaĝdym razem spodziewaÊ siÚ takich
samych wyników. Projektów, poprzez cechÚ wyjÈtkowoĂci, jednorazowoĂci
itp., nie moĝna zdefiniowaÊ jako procesów deterministycznych, poniewaĝ
wbczasie ich realizacji moĝe siÚ rozwijaÊ i produkt, i zespóï projektowy.
Jest bardzo maïo prawdopodobne, aby jakikolwiek zestaw predefiniowanych kroków doprowadziï do poĝÈdanego, przewidywalnego wyniku,
poniewaĝ zmieniajÈ siÚ wymagania technologiczne oraz ludzie wewnÈtrz
zespoïu projektowego.
Wykorzystanie podejĂcia zdecentralizowanego. Zdecentralizowany styl
zarzÈdzania moĝe znaczÈco wpïynÈÊ na projekt, poniewaĝ moĝe on
zaoszczÚdziÊ wiÚcej czasu niĝ podeĂcie autokratyczne. W metodykach
lekkich deleguje siÚ czÚĂÊ zadañ zwiÈzanych z podejmowaniem decyzji
do wszystkich czïonków zespoïu.
Prostota. W projektowaniu prowadzonym metodykami lekkimi zawsze
wybierana jest najprostsza droga prowadzÈca do celu. Zakïada siÚ ïatwe
zmiany modelowe, które dostosowywane sÈ do bieĝÈcych potrzeb i mogÈ
nastÚpowaÊ w róĝnych terminach. Nie wytwarza siÚ wiÚkszej funkcjonalnoĂci niĝ ta, która jest w danym momencie konieczna, ani dokumentacji
próbujÈcej przewidzieÊ przyszïoĂÊ projektu. To zmniejsza koncentracjÚ na
znalezienie informacji potrzebnych do tych predykcji (Gibson i Hughes
1994).
Oparcie siÚ na wspóïpracy z odbiorcÈ (uĝytkownikiem) i wspóïpracy
wewnÚtrznej. Klient projektu powinien ĂciĂle wspóïpracowaÊ z zespoïem projektowym, zapewniajÈc mu wszelkie potrzebne informacje, oraz
zgïaszaÊ bieĝÈce uwagi i komentarze do projektu. Ze wzglÚdu na decentralizacjÚ zespóï wykonawczy w metodykach „zwinnych” powinien siÚ
wb sposób ciÈgïy komunikowaÊ ze sobÈ.
Funkcjonowanie poprzez maïe, samoorganizujÈce siÚ zespoïy. W zespoïach
takich obowiÈzki i zadania przekazywane sÈ do zespoïu jako caïoĂci, a zespóï, rozdzielajÈc je, zapewnia najlepszy sposób ich realizacji.
W maïych zespoïach najlepiej sprawdza siÚ idea ciÈgïej komunikacji.
Struktura procesu i konkretne praktyki tworzÈ minimalne, elastyczne
ramy strukturalne dla zespoïów samoorganizujÈcych. Odpowiednie
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
ich wykorzystanie znacznie zmniejsza ryzyko zwiÈzane z czynnikiem
ludzkim.
Jako przykïad metodyki projektowania lekkiego przedstawiono metodykÚ
Scrum. Jest to iteracyjna metodyka oparta na zarzÈdzaniu zmianÈ, koncentrujÈca siÚ na ciÈgïych, twardych negocjacjach pomiÚdzy graczami: uĝytkownikiem maksymalnie moĝliwego elastycznego systemu informatycznego
abzespoïem projektowym. Nazwa nawiÈzuje do sytuacji wystÚpujÈcej podczas
gry w rugby. Termin scrum (mïyn) oznacza w niej rzut wolny, w którym
spleceni ze sobÈ gracze przeciwnych druĝyn przepychajÈ siÚ (negocjujÈ)
nad piïkÈ (celem) (Jaszkiewicz 1997). Scrum jest jednoczeĂnie metodykÈ
prototypowo-przyrostowÈ – wartoĂÊ dodana projektu powstaje w wyniku
zastosowania w kolejnych iteracjach faz cyklu ĝycia systemu okreĂlonych
narzÚdzi (przeciwdziaïajÈcych potencjalnemu ryzyku realizacyjnemu), wynikajÈcych z wypracowanych dobrych praktyk dla maïych i Ărednich, ale za
to zïoĝonych projektów (Rising i Janoff 2000: 26–32).
Podstawowe uĝywane w metodzie Scrum praktyki projektowania moĝna
sprowadziÊ do nastÚpujÈcych:
– tworzenie rejestru zamówieñ (product backlog) – czyli listy wszystkich
wymagañ uĝytkownika: funkcji i ustalonych z realizatorem zmian wraz
z priorytetami, czekajÈcych na realizacjÚ (odpowiedzialny uĝytkownik
koñcowy – wïaĂciciel produktu, product owner);
– cykl pracy – przebieg (sprint) – etap pracy zespoïu projektowego (od jednego do szeĂciu tygodni, z zaleceniem regularnoĂci i jednolitoĂci dïugoĂci
trwania kaĝdej iteracji, np. miesiÈc); w kaĝdym cyklu jest dostarczana
uĝytkownikowi do przetestowania i oceny nastÚpna dziaïajÈca wersja
prototypu produktu;
– planowanie cyklu pracy – przebiegu (sprint planning meeting) – skïada
siÚ z dwóch czÚĂci: analizy i projektu realizacji; w pierwszej wraz ze
wszystkimi uĝytkownikami zespóï projektowy ustala kompletny (w danym
momencie) zbiór celów i funkcji systemu, w drugiej zaĂ kierownik projektu (scrum master) z zespoïem uzgadnia najlepszy sposób realizacji
produktu podczas danego przebiegu;
– tworzenie rejestru zamówieñ dotyczÈcego konkretnego przebiegu (sprint
backlog) – listy nowych lub zmienionych funkcjonalnoĂci przypisanej do
kolejnego przebiegu; w momencie jej realizacji powstaje nowa wersja
prototypu;
– weryfikacja postÚpu prac (daily scrum meeting) – odbywa siÚ w trakcie
obowiÈzkowych codziennych spotkañ zespoïu projektowego; polega na
identyfikacji niezbÚdnych zmian i okreĂlenia warunków ich realizacji
przez zespóï (na zasadach samorealizacji).
Cykl ĝycia w metodzie Scrum (rysunek 2) przebiega wedïug nastÚpujÈcego schematu:
– rozpoznanie ogólnych wymagañ i wstÚpna analiza informacyjna caïoĂci
systemu;
vol. 10, nr 3 (38), 2012
35
Witold Chmielarz
–
–
–
–
rozpoznanie i analiza dla kolejnego, bieĝÈcego przebiegu;
planowanie przebiegu (analiza i projekt techniczny);
bieĝÈca weryfikacja zaïoĝeñ w trakcie codziennych spotkañ;
realizacja systemu i generacja oprogramowania kolejnego prototypu –
konstruowanie i zastosowanie;
– testowanie systemu po kolejnym przebiegu;
– eksploatacja i potencjalne przyszïe modyfikacje systemu.
Rozpoznanie ogólnych wymagań użytkownika
(Product Backlog)
Rozpoznanie wymagań użytkownika
dla kolejnego przebiegu (Sprint Backlog)
Analiza informacyjna danego przebiegu
Bieżąca
weryfikacja
kolejnego
prototypu
(Daily Scrum
Meeting)
Projekt techniczny
i jego ewentualna modyfikacja
– jeśli potrzebna po bieżącej weryfikacji
Planowanie przebiegu (Sprint Planning Meeting)
Realizacja systemu i generacja oprogramowania
kolejnego prototypu – konstruowanie, zastosowanie
(Sprint Product)
Testowanie systemu po kolejnym przebiegu
przez użytkownika, weryfikacja – jeśli potrzebna
Eksploatacja i potencjalne przyszłe modyfikacje systemu
Rys. 2. Cykl ĝycia systemu informatycznego w metodyce Scrum. ½ródïo: opracowanie
wïasne na podstawie K. Schwaber i M. Beedle 2001. Agile Software Development with
Scrum, Prentice Hall; K. Schwaber 2005. Sprawne zarzÈdzanie projektami metodÈ Scrum,
Warszawa: Promise.
Przed kaĝdym przebiegiem odbywa siÚ spotkanie zespoïu realizacyjnego
z uĝytkownikami, identyfikujÈce priorytetowe zadania (okreĂlenie zakresu,
zawartoĂci i intencji uĝytkownika) oraz konwertujÈce je w funkcjonalnoĂci
przyszïego systemu. Na tej podstawie tworzony jest plan wykonania oprogramowania w bieĝÈcej iteracji (priorytety, podziaï obowiÈzków, szczegóïowe
dziaïania). Natomiast na poczÈtku kaĝdego dnia przebiegu (w niektórych
interpretacjach tej metodyki – na zakoñczenie dnia) w trakcie spotkania
zamkniÚtego zespoïu projektowego odbywa siÚ bieĝÈca weryfikacja realizacji
36
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
zadañ (stan wykonania, problemy ogólne i szczegóïowe realizacji oraz jednostkowe sposoby ich rozwiÈzania). Ma na celu koordynacje i synchronizacjÚ
dziennej pracy czïonków zespoïu. Po kaĝdej iteracji odbywa siÚ natomiast
spotkanie z uĝytkownikiem w celu prezentacji produktu kolejnej iteracji
ib okreĂlenia, czy realizuje on kierunek zmian przez niego oczekiwany. Ma
ono pomóc klientowi w okreĂleniu, czy i co w nastÚpnej kolejnoĂci powinno
byÊ wykonywane. Na podstawie wniosków z tego spotkania produkt zostaje
przekazany do testowania i uĝytkowania lub, w kolejnej iteracji, do dalszych
modyfikacji.
4. Kryteria wyboru pomiÚdzy metodykami
tradycyjnymi i nowoczesnymi
Przeprowadzona powyĝej analiza wykazaïa, ĝe istnieje wiele metodyk
zarzÈdzania projektami i nie ma jednej wïaĂciwej dla wszystkich przypadków metodyki uniwersalnej. Metodyki sÈ tylko pewnym zbiorem wzorców,
zasad oraz formuï, które pomagajÈ w unikniÚciu bïÚdów, lecz zupeïnie ich
nie usuwajÈ. Pomimo to konsekwentnie wdroĝona metodyka daje poczucie kontroli nad przedsiÚwziÚciem, utrzymywania peïnego zaangaĝowania
wszystkich zainteresowanych stron oraz uzasadnia poczucie bezpieczeñstwa
realizacji strategii biznesu sponsora.
W zwiÈzku z powyĝszym kaĝdy projekt informatyczny wymaga zdefiniowania metodyki, wedïug której bÚdzie prowadzony. W najbardziej ogólnym
sposób – opierajÈc siÚ na wczeĂniej zdefiniowanych cechach charakterystycznych metodyk tradycyjnych i nowoczesnych – moĝemy stwierdziÊ, ĝe
wybór ten okreĂla szereg czynników zwiÈzanych z konkretnym projektem
(jego wielkoĂciÈ, branĝÈ, w której jest realizowany, czynnikiem ludzkim
wb projekcie i dodatkowymi wymogami realizacyjnymi itd.).
Niemniej jednak wstÚpnÈ listÚ kryteriów pomocniczych wyboru moĝna
oszacowaÊ na podstawie takich zmiennych, jak:
– Rodzaj i harmonogram finansowania prac zawarty w umowie z klientem.
Jeĝeli zakïada siÚ wykïadniczy, to powinny to byÊ metodyki zwinne.
Wbtych metodykach przyjmuje siÚ, ĝe czynnikami waĝniejszymi niĝ negocjowanie kontraktów sÈ zaufanie i wspóïpraca partnerów biznesowych
(przynajmniej deklaratywnie). W trakcie podpisywania umowy i wstÚpnego ustalania harmonogramu albo przyjmuje siÚ realizacjÚ budĝetu od
poczÈtku korzystnÈ dla klienta (powoli rosnÈcÈ na poczÈtku projektu,
wykïadniczo wraz z przekazywaniem uzgodnionych, przyjmowanych przez
uĝytkownika produktów), albo na kontraktach o niewielkim stopniu
ryzyka dla realizatora projektu (np. umowy z refundowanym kosztem
wedïug cen staïych). Jeĝeli natomiast zakïada siÚ logarytmicznÈ funkcjÚ
realizacji budĝetu (wysokÈ w stadiach poczÈtkowych, stabilizujÈcÈ siÚ
wbpóěniejszych fazach projektu), to – zwïaszcza dla firm o ugruntowanej
pozycji na rynku – opïaca siÚ przyjÈÊ jednÈ z metodyk klasycznych.
vol. 10, nr 3 (38), 2012
37
Witold Chmielarz
– Typ budĝetu. Nierównomiernie rozïoĝony w czasie budĝet projektu, wymuszajÈcy róĝnÈ intensywnoĂÊ prac oraz wysoki stopieñ niepewnoĂci, wskazuje na efektywniejsze uĝycie metodyki zwinnej. ZaĂ budĝet finansujÈcy
projekt w sposób równomierny i staïy w czasie sugeruje wykorzystanie
metodyki klasycznej.
– Charakter ustaleñ harmonogramu. Narzucone w harmonogramie sztywne
zaïoĝenia czasowe w stosunku do zaplanowanych zadañ przemawiajÈ na
korzyĂÊ zastosowania metodyk klasycznych. Przybliĝone lub relatywne
terminy realizacji sugerujÈ uĝycie metod zwinnych.
– IloĂÊ i poziom wymaganej dokumentacji oraz poziom jakoĂci oprogramowania. Speïnienie zïoĝonych wymagañ zwiÈzanych z formalnymi standardami dokumentacji, licencjami czy certyfikacji wskazuje na koniecznoĂÊ
zastosowania klasycznej metodyki zarzÈdzania projektem. Natomiast projekt, w którym nacisk kïadziony jest na jakoĂÊ oprogramowania ib moĝliwoĂci jego rozwoju, jest zgodny z filozofiÈ metodyk zwinnych.
– PodejĂcie do ryzyka projektowego – niskie ryzyko projektowe obsïugujÈ
lepiej metodyki zwinne. Wysokie ryzyko w projekcie wymusza stosowanie
metodyk klasycznych, w których zakïada siÚ tworzenie planów minimalizacji ryzyka lub sytuacji awaryjnych.
– Komunikacja z klientem. Metodyki zwinne zakïadajÈ ciÈgïÈ oraz bezpoĂredniÈ komunikacjÚ z klientem. Zmniejszane sÈ wiÚc wszelkie czynniki
zwiÈzane z niezrozumieniem realizowanych zadañ. W metodykach klasycznych preferuje siÚ rzadszy kontakt z klientem, co prowadzi bardzo
czÚsto do nieporozumieñ w momencie prezentacji i przekazania zrealizowanego systemu.
– Struktura organizacyjna konieczna do realizacji projektu. PrzedsiÚbiorstwa
o strukturze hierarchicznej lub pokrewnych, zawierajÈce w swoich strukturach ĂciĂle wyspecjalizowane jednostki, bÚdÈ preferowaÊ metodyki klasyczne. PrzedsiÚbiorstwa o strukturze np. macierzowej, projektowej lub
innej, w której mogÈ sobie pozwoliÊ na delegowanie zadañ projektowych
do mniejszych zespoïów, w których nie ma ĂciĂle zdefiniowanej hierarchii
organizacyjnej, powinny zdecydowaÊ siÚ na wybór metodyki klasycznej.
– Sektor/branĝa realizacji projektu zwiÈzana czÚsto ze strukturami organizacyjnymi teĝ znaczÈco wpïywa na realizacjÚ projektu. Branĝe, które
na wejĂciu majÈ niewielkÈ liczbÚ surowców i materiaïów, a na wyjĂciu
gotowych produktów, lepiej nadajÈ siÚ do uĝycia w trakcie projektowania
systemu metod klasycznych.
– WielkoĂÊ projektu. CzÚĂÊ Ărodowisk programistycznych zwiÈzanych z wdroĝeniami wielkich systemów uwaĝa, ĝe metody klasyczne lepiej nadajÈ siÚ
do realizacji tego typu projektów. W metodykach zwinnych (a zwïaszcza
omawianej Scrum) trudno przy wielkich projektach, nawet powtarzalnych,
skoordynowaÊ dziaïania wielu maïych grup realizujÈcych projekt.
– Rodzaj systemu, dla którego projekt jest realizowany. Systemy eksperckie
lub oparte na bazie wiedzy wymagajÈ bardzo czÚsto duĝej wiedzy obreali38
Problemy ZarzÈdzania
Kryteria wyboru metod zarzÈdzania projektami informatycznymi
zowanym zagadnieniu. JeĂli sÈ to systemy z zaïoĝenia konstruowane jako
samouczÈce, zaleca siÚ stosowanie metodyk nowoczesnych, w przeciwnym
przypadku – dla systemów opartych na ustalonych wzorcach postÚpowania – metodyk klasycznych.
– Czynniki psychologiczne, np. doĂwiadczenie zespoïu realizacyjnego wbstosowaniu metodyk zwinnych lub klasycznych, zaufanie organizacji, w której projekt jest realizowany do zespoïu projektowego, wysoki stopieñ
wykorzystania w zespoïach mieszanych specjalistów ze strony przyszïego
uĝytkownika itp.
Powyĝsza lista czynników nie jest ani kompletna, ani wystarczajÈca. Bardzo trudno jest bowiem ex ante oceniÊ, która ze znanych metodyk wbprzedstawionym ukïadzie jest najlepsza dla realizowanego projektu. Tak wiÚc coraz
wiÚcej organizacji utrzymujÈcych siÚ z realizacji projektów jest zainteresowanych zarzÈdzaniem przez projekt, polegajÈcym w praktyce (upraszczajÈc
sytuacjÚ) gïównie na równolegïym prowadzeniu jak najwiÚkszej liczby projektów. Umoĝliwia to nie tylko porównanie ich cech charakterystycznych
(harmonogramów, kosztów, zasobów) realizowanych dla róĝnej wielkoĂci
firm, w wielu branĝach, w wielu lokalizacjach, ale równieĝ skutecznoĂci
metody prowadzenia projektów, aĝ do zaproponowania wïasnej. Pozwala
to równieĝ przecieĝ na wielowymiarowÈ ocenÚ (w tym porównawczÈ, efektywnoĂci itd.) prowadzonych projektów i dostarcza kierownikom projektów
wzorców dobrych praktyk zarzÈdzania oraz ocenÚ efektywnoĂci poszczególnych jednostek organizacyjnych prowadzÈcych projekty.
Analizy wykonania projektów dostarczajÈ teĝ przesïanek do wspóïdzielenia
zasobów projektów (w tym technologii, know-how itp.), rozliczenia czasu
ibkompetencji wykonawców oraz wyceny generowanych w projekcie produktów
lub usïug. ZarzÈdzanie przez projekty jest stylem zarzÈdzania doskonalÈcym
przedsiÚbiorczoĂÊ i bÚdÈcym swoistym „zïotym Ărodkiem” pomiÚdzy rzeczywistymi potrzebami firmy zleceniodawcy (okreĂlonej przez jej specyfikÚ) a wiedzÈ
(teoretycznÈ i praktycznÈ) i metodami zarzÈdzania projektami (Stabryïa 2006).
Ta pragmatyka podejĂcia umoĝliwia tworzenie wzorców postÚpowania podczas
realizacji poszczególnych rodzajów projektów, co uïatwia tworzenie strategii
nie tylko organizacji utrzymujÈcych siÚ z tworzenia i wdraĝania projektów
(ibcoraz czÚĂciej – nie tylko informatycznych) oraz niewÈtpliwie w ostatecznym
rozrachunku wybór metodyk zarzÈdzania projektem.
Informacje o autorze
Prof. dr hab. Witold Chmielarz – Katedra Systemów Informacyjnych ZarzÈdzania,
Wydziaï ZarzÈdzania Uniwersytetu Warszawskiego. E-mail: [email protected].
Przypisy
1
WiÚcej na ten temat np. w: Chmielarz 2010: 359–402.
2
Patrz teĝ: Chmielarz i Klincewicz 2010: 238–252.
vol. 10, nr 3 (38), 2012
39
Witold Chmielarz
Bibliografia
Awad, M.A. 2005. A Comparison between Agile and Traditional Software Development
Methodologies, The University of Western Australia, http://www.scribd.com/doc/55475190/A-ion-Between-Agile-and-Traditional-SW-Development-Methodologies, odczyt:
marzec 2012.
Beck, K. i in. 2010. Manifesto for Agile Software Development, Agile Alliance, 2001,
Retrieved 14 June 2010, http://www.pmbriefcase.com/methodologies/50-softwaredevelopment/55-agile-software, odczyt: kwiecieñ 2012.
Chmielarz, W. 2010. Projektowanie systemów informatycznych, w: J. Zawiïa-Nieděwiecki,
K. Rostek i A. GÈsiorkiewicz (red.) Informatyka gospodarcza, t. 1, s. 359–402. Warszawa: C.H. Beck.
Chmielarz, W. i K. Klincewicz 2010. ZarzÈdzanie w kontekĂcie zmian, w: J. Bogdanienko
(red.) Organizacja i zarzÈdzanie w zarysie, s. 238–252. Warszawa: Wydawnictwo
Naukowe WZ UW, Dom Wydawniczy Elipsa.
Gibson, M. i G. Hughes 1994. Systems Analysis and Design. A Comprehensive Methodology with CASE, Boyd & Fraser.
Highsmith, J. i A. Cockburn 2004. Agile Software Development: The Business of Innovation. IEEE Computer, nr 6 (36), http://www.jimhighsmith.com/articles/IEEEArticle1Final.pdf, odczyt: kwiecieñ 2012, DOI: 10.1109/2.947100.
Jaszkiewicz, A. 1997. Inĝynieria oprogramowania, Gliwice: Helion.
Kendall, K. i J. Kendall 1999. Systems Analysis and Design, Upper Saddle River: Prentice
Hall.
Koszlajda, A. 2010. ZarzÈdzanie projektami IT. Przewodnik po metodykach, Gliwice: Helion.
Mannaro, K. 2008. Adopting Agile Methodologies in Distributed Software Development,
Wydziaï Inĝynierii Elektrycznej i Elektroniki Uniwersytetu Cagliari, http://www.diee.
unica.it/DRIEI/tesi/19_mannaro.pdf.
Mingus, N. 2009. Zarzadzanie projektami, Gliwice: Helion.
Project Management Institute 2004. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition.
Rising, L. i N.S. Janoff 2000. The Scrum Software Development Process for Small Teams.
IEEE Software, nr 17, s. 26–32, DOI: 10.1109/52.854065.
Schwaber, K. 2005. Sprawne zarzÈdzanie projektami metodÈ Scrum, Warszawa: Promise.
Schwaber, K. i M. Beedle 2001. Agile Software Development with Scrum, New Jersey:
Prentice Hall.
Stabryïa, A. 2006. ZarzÈdzanie projektami ekonomicznymi i organizacyjnymi, Warszawa:
Wydawnictwo Naukowe PWN.
Sully, P. 1993. Modelling the World with Objects, New Jersey: Prentice Hall.
40
Problemy ZarzÈdzania