plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 5/2006

Antywzorce w zarządzaniu

projektami informatycznymi

rtykuł o zarządzaniu projektami informa-

tycznymi w czasopiśmie dla deweloperów?

Czyżby i już tutaj sięgały macki wszechmoc-

nych menadżerów? Otóż nie, artykuł ten jest adre-

sowany do Ciebie – dewelopera, biorącego udział

w projekcie informatycznym.

Na co dzień żyjesz w świecie pełnym wyzwań, być

może tworzysz przełomowe rozwiązanie lub utrzymu-

jesz starożytny system informatyczny. Musisz doko-

nywać cudów w piątkowy wieczór i uczyć się podczas

snu. Na biurku wśród stosów dokumentacji, gdzieś pod

kubkiem od kawy leży ponowienie ponowienia proś-

by o wykorzystanie zaległych urlopów. Realizujesz za-

danie, do którego potrzeba 1.4241 dewelopera. Brzmi

znajomo? Jeśli tak, ten artykuł jest właśnie dla Ciebie.

Postaram się wskazać najczęściej pojawiające się błę-

dy w zarządzaniu projektami. Tematyka poruszona w

artykule to antywzorce projektowe, złe praktyki rozpo-

znawane i opisywane od lat. Jeśli chcesz wiedzieć, dla-

czego tak wiele projektów kończy się niepowodzeniem,

a idolem dla większości z Nas jest Dilbert i Chuck Nor-

ris – zapraszam do lektury.

Antywzorce projektowe

Podstawowe informacje dotyczące antywzorców za-

warłem w artykule „Antywzorce projektowe” (SDJ 2/

2006), dla przypomnienia jednak – kilka podstawo-

wych faktów.

Antywzorzec to opis złej praktyki – błędu popełnia-

nego na tyle często, iż został zidentyfikowany, nazwa-

ny i udokumentowany. Podczas gdy wzorce projektowe

prezentują poprawne rozwiązania pewnych klas pro-

blemów, antywzorce wykorzystujemy w celu identyfika-

cji błędów w sztuce. Okazuje się, że człowiek jest na ty-

le skomplikowany, iż łatwiej zapamiętuje przykłady ne-

gatywne niż pozytywne – z tego też powodu antywzor-

ce są poręcznym narzędziem dydaktycznym.

Antywzorzec nie byłby przydatny, gdyby zawie-

rał tylko opis błędu. To, czego potrzebujemy i co zo-

stanie zaprezentowane również w niniejszym arty-

kule, to przykłady działań, które należy podjąć, aby

naprawić popełniony błąd. Większość antywzorców

jest efektem konkretnej postawy członków zespołu,

w którym go zidentyfikowano. Poprzednio opisane

zachowania ludzkie prowadzące do powstawania

złych praktyk to między innymi duma, lenistwo, za-

chłanność, pycha czy ignorancja.

Wzorce projektowe często kojarzone są jedynie

z konstrukcjami programistycznymi. Antywzorce projek-

towe omówione poprzednio, dotyczyły głównie zadań

związanych z tworzenia oprogramowania. Nie można

jednak zapomnieć, iż wzorce i antywzorce w projektach

informatycznych napotykamy na każdym etapie. Czy

to podczas zbierania wymagań, tworzenia architektury

systemu, kodowania, czy też w zarządzaniu projektem.

Błędy w zarządzaniu projektami

Nim przejdziemy do omówienia poszczególnych antyw-

zorców projektowych, pragnę poprosić Cię o jedno. Je-

śli zauważysz, iż w Twoim projekcie wystąpił antywzo-

rzec, porozmawiaj o tym z członkami zespołu. Zgłoś to

menadżerowi i nie poddawaj nawet jeśli nie spotkasz

się z pozytywną reakcją. Podstawowy antywzorzec to

brak świadomości istnienia antywzorców. Być może

brzmi to enigmatycznie, zauważ jednak, iż gdy potra-

fisz zidentyfikować błąd, potrafisz się przed nim ustrzec

– wszak po to właśnie opracowuje się antywzorce!

„Don't Worry, Be Happy”

Tytuł piosenki Bobby'ego McFerrin'a świetnie oddaje

stan jaki panuje w wielu projektach informatycznych.

Pośpiech, lenistwo lub brak doświadczenia w prowa-

dzeniu projektami, stwarza sytuacje, w których nikt nie

pomyślał o zastosowaniu choćby podstawowych za-

sad zarządzania procesem wytwarzania programowa-

nia. Antywzorzec ten, zwany też inaczej „nil desperan-

dum” (łac. nie ma powodu do rozpaczy) jest dość łatwo

zidentyfikować. Jeśli słyszysz lub być może sam nie-

dawno wypowiedziałeś magiczne zaklęcie „Powiedz

mi, czego chcesz, a ja to zakoduję” - masz do czynienia

Stefan Turalski

Autor pracuje na stanowisku - projektant oprogramowa-
nia w firmie Silicon & Software Systems Polska. Z za-
interesowaniem przygląda się rozwojowi technologii IT,
dawno już straciwszy nadzieję, że jest w stanie ogarnąć
tą dziedzinę wiedzy.
Kontakt z autorem stefan.turalski@gmail.com

Rysunek 1.

Elementy przykładowego procesu

wytwarzania oprogramowania

��

Antywzorce w zarządzaniu projektami informatycznymi

www.sdjournal.org

Software Developer’s Journal 5/2006

z tym antywzorcem. Myślisz, że nie potrzebujesz projektu syste-

mu? Nie ma potrzeby kłopotać klienta i spotykać się w celu prze-

dyskutowania wymagań? Piszesz doskonały kod, który nie po-

trzebuje testów? Proszę powiedz, że na żadne pytanie nie odpo-

wiedziałeś twierdząco.

Niestety, brak świadomości istnienia procesu wytwarzania

oprogramowania prowadzi do przekroczenia kosztów budowy

rozwiązania informatycznego, zerwania kontraktu, czy też stwo-

rzenia nikomu nie potrzebnego systemu.

Przykładem może być tu projekt dotyczący stworzenia Intra-

netu w pewnej firmie. Projekt został zaplanowany na 2 tygodnie,

deweloperzy, aby lepiej współpracować pojechali kodować do

siedziby klienta. Po 2 miesiącach stworzono zalążek systemu,

który pracownicy klienta przeklinali, bo chociaż był piękny, to pra-

cował bardzo wolno. Nikt nie przewidział, że zespół klienta to po-

nad 2 tysiące pracowników, znacznie obciążających serwer Intra-

netu. Co więcej, mimo, że deweloperzy twierdzili, iż spełnili wy-

magania klienta, ten nie chciał zapłacić uzgodnionej kwoty. Ja-

ko powód podał brak 75% wymaganej funkcjonalności. Czy tylko

zbiegiem okoliczności było to, że pozostałe 25% zostało wykona-

ne perfekcyjnie i pracowało na potrzeby działu HR, z którym są-

siadował pokój programistów? Na całe szczęście tego typu sytu-

acje zdarzają się dość rzadko.

Większość menadżerów ma już świadomość istnienia pro-

cesu zarządzania projektem informatycznym, a i dla dewelo-

perów znajomy jest Rysunek 1.

Jeśli jednak nie wiesz, czym jest proces wytwarzania opro-

gramowania, ten artykuł Ci nie pomoże. Temat ten stanowczo

wymaga zgłębienia i jest zbyt rozległy, aby poruszyć go na tych

kilku stronach. Nie muszę chyba mówić, że to będzie także Two-

ja wina, jeśli np. nie przetestowane rozwiązanie zostanie (w naj-

lepszym przypadku) zwrócone do kosztownych poprawek. Je-

śli więc posiadasz odpowiednie doświadczenie, nie zgadzaj się

na łamanie podstawowych zasad i dobrych praktyk wytwarza-

nia oprogramowania. Podstawowy antywzorzec rozwiązuje się

bardzo prosto – należy wprowadzić proces zarządzania projek-

tem. Niestety bez pracy nie ma kołaczy lub jak mawiają Anglosa-

si „No pain, no gain”.

Nieracjonalne zarządzanie

Załóżmy, że dysponujemy kierownictwem zespołu rozumieją-

cym, że planowanie jest potrzebne. Konieczne jest upewnie-

nie się, że menadżerowie nie popełniają podstawowych błędów

w planowaniu. Śledzenie projektu na każdym z etapów prac jest

niewątpliwie potrzebne, jednak nikt nie potrafi poprawnie osza-

cować zadań zależnych od specyfikacji wymagań klienta, które

jeszcze nie zostały dostarczone.

Błędy w zarządzaniu projektem zdarzają się zawsze, mogą

przyjąć rozmiar antywzorców opisanych poniżej, takich jak Marsz

ku klęsce, czy Zamrożenie w fazie analizy. Najczęściej powodu-

ją je tzw. „Trudni ludzie”, których obecność w projekcie jest tak-

że jednym z antywzorców. Nie potrafiąc lub nie znając specyfi-

ki projektu podejmują błędne decyzje. Nowy menadżer w projek-

cie, który realizuje pewne zadania niespełna od roku, może błęd-

nie alokować ludzi. Brak mocy decyzyjnej może powodować, iż

przez kilka pierwszych miesięcy tworzy się dokumenty zamiast

rozpocząć kodowanie. Na efekty nie trzeba długo czekać. Sys-

temy, które powstawały w przeciągu kliku tygodni nie są odpo-

wiednio przetestowane, najczęściej dlatego, iż menadżer nie za-

łożył tego typu zadania.

Można zaryzykować stwierdzenie, że jeśli podejmiemy się

zarządzania projektem i zatrudnimy menadżera, niemal w 100%

pewne jest, iż podejmie on, choć jedną nieracjonalną decyzję.

Nie ma ludzi nieomylnych i kontrola samego procesu zarządza-

nia też jest konieczna. W przeciwnym przypadku otrzymamy

projekt, który stanie się typowym źródłem antywzorców w zarzą-

dzaniu. Akcje zapobiegawcze w tym przypadku sprowadzają się

praktycznie do podnoszenia kwalifikacji menadżerów. Wraz ze

zbieraniem doświadczenia, osoby kierujące projektem zdają so-

bie sprawę z najczęściej popełnianych błędów i potrafią ich uni-

kać. Z punktu widzenia programisty warto zaznaczyć, iż to wła-

śnie Nas często pyta się o oszacowanie czasu projektu – jeśli

zrobimy to źle, lub przeoczymy pewne zadania, z pewnością za-

płacimy za to w przyszłości.

Marsz ku klęsce

W znanej większości menadżerów książce Edwarda Yourdon'a

„Death March”, autor opisał i zdefiniował grupę projektów z góry

skazaną na niepowodzenie. Podana definicja zakłada, iż projekt

skazany na klęskę to taki, w którym brakuje ponad 50% zasobów.

Z pewnością powierzono Ci nie raz zadanie, które powinno wy-

konać kliku programistów To przykład braku prawidłowego osza-

cowania kadry potrzebnej do realizacji projektu. Analogicznie,

o 50% za niski budżet lub zadeklarowany czas trwania projektu

krótszy od porównywalnych projektów o 50%, prowadzi do fiaska

danego przedsięwzięcia. Podobne założenie dotyczy także celów

projektu, które często nie tylko trochę, ale nawet o ponad 50%

mają przewyższać standardowo opracowywane rozwiązania.

Doświadczenie uczy, iż niemal każdy projekt informatyczny

to marsz ku klęsce, według definicji Yourdon'a. Nie należy, więc

od razu załamywać rąk. To co potrafi dobry menadżer projektu,

to identyfikacja tych zasobów, które są krytyczne i stwarzają ry-

zyko w projekcie. Następnie z wykorzystaniem dostępnych środ-

ków, ryzyko to można próbować minimalizować.

Przykładem może być mała firma programistyczna, która

choć posiada bardzo niewielkie środki zobowiązała się stwo-

rzyć złożony system o bardzo specjalistycznej funkcjonalności

(nie trzeba chyba wspominać, iż o dziedzinie problemu, któ-

ry miał wspierać system, w zespole programistów nikt nic nie

wiedział). Jedyne, co przemawia na jej korzyść to czas projek-

tu, który jest dość luźno określony.

W takim przypadku, sprawny menadżer może zapropono-

wać klientowi dostarczanie kolejnych modułów, jako wyników ko-

lejnych etapów projektu. Firma miast narażać się na kredyt, bę-

dzie miała stałe źródło dochodów, mały zespół łatwiej przetestu-

je, zaprojektuje, wykona i wdroży niewielkie moduły. Korzyść zaś

z przyrostowego wytwarzania oprogramowania, to w tym przy-

padku możliwość szybkiej reakcji na potrzeby klienta, który prze-

cież niekoniecznie musi posiadać całą oczekiwaną funkcjonal-

ność od razu. Najważniejsze w przypadku zidentyfikowania

antywzorca „marsz ku klęsce” jest odpowiednie zidentyfiko-

wanie przyczyny marszu. Gdy nic innego już nie pomaga, pro-

ponuję uciekać. Marsz trwa często do kilku lat, w zależności

od zasobów organizacji. Niestety kadra kierownicza, która nie

potrafi odpowiednio zareagować i zapobiec skutkom marszu,

przyczyni się tylko do klęski projektu.

„Mushroom management”

W kolejnej kultowej już niemal książce „The Soul Of A New
Machine” Tracy Kidder opisuje projekt informatyczny, w któ-

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 5/2006

rym udział biorą młodzi deweloperzy oddzieleni od oczekiwań

klientów. Hodowla grzybów, jak potocznie można przetłuma-

czyć anglojęzyczną nazwę antywzorca, to sytuacja niestety

nazbyt częsta w projektach.

Kierownictwo projektu, architekci, specjaliści analizujący

wymagania klientów, tworzą dokumentację oraz modele opi-

sujące przyszły system. Sami programiści, czyli autorzy roz-

wiązania nie są dopuszczani do rozmów z klientem. Skutkiem

tego dostarczone rozwiązanie często nie dostarcza oczekiwa-

nej przez klienta funkcjonalności.

Często programiści padają także ofiarą dość swobodne-

go traktowania dokumentacji projektowej przez samego klien-

ta. Osobiście byłem świadkiem projektów, w których klient od-

rzucił przedstawione mu rozwiązanie, mimo iż wcześniej zaak-

ceptował przygotowaną dokumentację. Bardzo prostą akcją za-

pobiegawczą jest opracowanie prototypu systemu. Przy możli-

wościach oferowanych przez nowoczesne środowiska i techno-

logie, przygotowanie tego typu przykładowego rozwiązania, nie

pochłania dużych zasobów, a jest nieocenione w trakcie rozmów

z klientem. Aby uniknąć sytuacji, gdy programista pisze program

dla siebie, a nie dla użytkownika, należy go oswoić z problemem.

Mimo, iż nasze środowisko jest postrzegane przez pryzmat ste-

reotypów, programista nie może być izolowany od klienta i od je-

go potrzeb. Jeśli odpowiednio wcześnie nie zasygnalizujesz, że

brakuje Ci jasnej wizji systemu, nie mówiąc już o szczegółach re-

alizacji poszczególnych procesów – sam przyczynisz się do po-

rażki tego projektu.

Zamrożenie w fazie analizy

Brak fazy analizy w projekcie informatycznym jest niemal niewy-

obrażalny. Wszak, zarówno klient jak i zespół budujący rozwią-

zanie informatyczne musi uzgodnić zakres funkcjonalności two-

rzonego systemu. I choć nieczęsto można mówić o doskonale

przeprowadzonej analizie, istnieją projekty, w których za cel po-

stawiono sobie stworzenie idealnego zbioru wymagań funkcjo-

nalnych oraz projektu systemu. Projekty, w których faza analizy

przeciąga się, są szczególnie niebezpieczne, gdyż najprawdopo-

dobniej nigdy nie przejdą w fazę implementacji systemu. Szcze-

gólnie dobrze znają ten antywzorzec osoby, które miały okazję

pracować w projektach wielokrotnie rozpoczynanych całkiem od

nowa. Przyczyną może być tu zmiana kierownictwa lub główne-

go celu projektu.

Faza analizy służy do nakreślenia wizji przyszłego systemu,

w możliwe dokładny sposób. Nie należy jednak kierować się za-

sadą, iż jeśli raz dokonaliśmy analizy systemu nigdy już nie wró-

cimy do tej fazy. Doświadczenie uczy, że dobrze przeprowadzo-

na analiza, to nie ta, która dostarcza kompleksowej wiedzy o bu-

dowanym rozwiązaniu, w tym o najmniejszych jego szczegółach.

Dobra analiza to taka, która pozwala na łatwe wprowadzanie

zmian, które z pewnością pojawią się w przyszłości.

Jak widzimy na Rysunku 1. projekt informatyczny można

traktować zgodnie z modelem wodospadowym, w którym kolej-

ne fazy następują po sobie. Doświadczony menadżer wie jed-

nak, że budowanie systemu informatycznego to proces przyro-

stowy. Po wykonaniu pracy, np. w fazie implementacji lub testo-

wania, być może będziemy musieli powrócić do faz początko-

wych w celu weryfikacji pierwotnych założeń.

Menadżerowie mogą nalegać na dostarczanie im kompletnej

analizy systemu przed podjęciem prac projektowych. Być może

kierownictwo projektu boi się podjąć decyzję o realizacji systemu

bez kompleksowej wiedzy o dziedzinie problemu. Możemy mieć

do czynienia ze szczególnie mocnym przywiązaniem do pewnej

technologii, pochodzącej z poprzedniego projektu menadżera, a

nie adekwatnej do potrzeb aktualnego projektu. Zachowania te-

go typu blokują postęp prac projektowych lub jak sugeruje na-

zwa antywzorca – zamrażają je.

Nawet w sytuacji, gdy projekt wyszedł poza fazę analizy, za-

zwyczaj długą i dostarczającą bardzo dokładnej wiedzy, anty-

zwozrzec ten może ujawnić się ponownie. Czasem podczas pro-

jektowania, implementacji lub testowania, okazuje się że analiza

nie przewidywała pewnych sytuacji lub po prostu jest sprzeczna

z rzeczywistymi wymaganiami klienta. Menadżerowie, którzy już

poświęcili zasoby projektu na wykonanie analizy, najczęściej bę-

dą bronili już istniejących założeń. A przecież proces wytwarza-

nia oprogramowania zakłada zmiany. Jeśli więc pojawi się ko-

nieczność ich wprowadzenia, należy odpowiednio na nie zare-

agować, szacując wpływ zmiany na już istniejący system. Pod

żadnym pozorem nie można stwierdzić, iż raz wykonana analiza

jest już dziełem ostatecznym.

Jeśli jako programista zauważasz tego typu błędy w za-

rządzaniu projektem, zwróć proszę uwagę kierownictwu. Do-

brze wykonana analiza to analiza, którą można zmieniać.

Panujące obecnie podejście obiektowe do projektowania

programowania z definicji jest przygotowane na rozszerzanie.

Coraz popularniejsze podejście architektur zorientowanych

na usługi (ang. Service Oriented Architecture) również zakła-

da, iż rozwiązanie – kompletny system informatyczny, zosta-

nie oparte o zestaw usług podatnych na zmiany (z tego to po-

wodu usługa najczęściej prezentuje jedynie interfejs, ukrywa-

jąc szczegóły implementacyjne).

Nie należy więc dążyć do zamknięcia fazy analizy i jej za-

mrożenia. Wręcz przeciwnie, w dobrze zarządzanym projek-

cie, faza analizy istnieje w tle. Każda zmiana wynikająca czy

to z zmiany wymagań klienta, czy to z dostrzeżonych niespój-

ności lub luk w analizie, powoduje powrót do już poczynionych

założeń i ich rewalidację.

Podsumowując, faza analizy jest niewątpliwie kluczowa i bar-

dzo ważne jest prawidłowe jej przeprowadzenie. Należy, jednak

pamiętać, aby nie przesłoniła nam ona celu, jakim jest stworze-

nie rozwiązania informatycznego. A podczas prowadzenia prac

projektowych należy zapewnić dobre zarządzanie zmianami

wpływającymi na już poczynione założenia.

Plan

Każdy kto pamięta czasy poprzedniego ustroju (PRL’u),

z pewnością wie czym jest PLAN. Kto zaś nie pamięta, wy-

starczy, że rzuci okiem na kroniki filmowe z poprzedniej epoki.

Plan na kilka lat, pomagał zarządzać całym krajem. Scentrali-

zowane centrum dowodzenia, najpierw plan taki tworzyło, na-

stępnie go egzekwowało, tzn. wymagało jego wykonania. Re-

Bibliografia

AntiPatterns: Refactoring Software, Architectures, and Projects

in Crisis

William J. Brown, Raphael C. Malveau, Hays W. McCormick

III, Thomas J. Mowbray „AntiPatterns in Project Management”

William J. Brown, Hays W. McCormick III, Scott W. Thomas

http://c2.com/cgi/wiki?AntiPattern

Antywzorce w zarządzaniu projektami informatycznymi

www.sdjournal.org

Software Developer’s Journal 5/2006

alna realizacja była najczęściej nierealna, a raportowane po-

stępy i wyniki istniały jedynie na papierze.

Sytuaja podobna ma niestety miejsce w wielu projektach

informatycznych. Z własnego doświadczenia mogę przywołać

taką oto historię.

Menadżer projektu, niekoniecznie dysponujacy wiedzą in-

formatyczną zbudował zręby planu. Podlegli mu kierownicy ze-

społów zdefiniowali grupy zdań, wreszcie programiści wyodręb-

nili pojedyńcze zadania. Oczywiście dzieło takie było nie do za-

akceptowania przez zarząd firmy wykonującej projekt. Plan prze-

kraczał terminy, zakładał szkolenia oraz powiększenie zespołu.

Zasiedliśmy więc do planowania raz jeszcze. Tym razem kosz-

ty się zgadzały, a kilka zadań sprytnie ukryliśmy tak, że projekt

został zaakceptowany. Gdy po prawie dwóch tygodniach wystar-

towaliśmy, okazało się, że w planie nie przewidziano połowy za-

dań. Natomiast metodę oszacowania czasu wykonania pozosta-

łych zdań z powodzeniem można byłoby wykorzystać w syste-

mach gier losowych.

Plan w projekcie jest tylko narzędziem, pomagającym

oszacować koszt i czas. Za pomocą spisanych zadań, ułożo-

nych w piękny wykres Gantta, nie oszczędzimy pieniędzy ani

tez nie wstrzymamy czasu. Jeśli menadżer projektu naciska

na wykonanie planu, kiedy widzisz, że zdania uległy zmianie,

musisz to zasygnalizować.

Głównym zadaniem menadżera w projekcie jest zapewnienie

dobrej komunikacji między osobami zespołu i zarządzanie pla-

nem projektu. To ta osoba jest odpowiedzialna za aktualizowanie

danych i śledzenie postępów w projekcie. Jeśli nie otrzyma sy-

gnału o zmieniających się wymaganiach klienta, lub o przeciąga-

jacym się czasie wykonania szczególnie skomplikowanego zda-

nia, nie jest w stanie prawdłowo zareagować, w tym międy inny-

mi oszacować ryzyka powodzenia projektu. Jeśli więc menadżer

projektu igoruje zgłaszane problemy z wykonaniem planu, jego

kompetencje należy postawić pod znakiem zapytania.

Odważę się stwierdzić, że nie istnieje projekt w którym nie

było problemów z oszacowaniem prawdłowego czasu i wysił-

ku jaki będzie potrzebny do stworzenia systemu informatycz-

nego. Zawsze należy być otwartym na zmiany w planie pro-

jektu, odpowiednio zarządzać terminami, kierować się tym, że

dostarczony ma być system informatyczny (lub jego kompo-

nenty) a nie doskonale zrealizowany plan.

Nawiązując do wstępu tej seksji, wszyscy wiemy jak za-

kończył się projekt PRL. Obecnie coraz więcej projektów

wykorzystuje narzędzia służące do zarządzania czasem

oraz planowania, nie jest jednak ważne to czy się te narzę-

dzia wykorzystuje, ale jak się to robi. Plan w projekcie jest

narzędziem, które ma pomóc w realizacji celu, nie jest ce-

lem samym w sobie – należy o tym pamiętać eliminując ten

antywzorzec.

Projekt – drukarnia

W każdym projekcie nadchodzi moment tworzenia dokumenta-

cji. Zbieramy wymagania użytkowników, projektujemy rozwiąza-

nie, proponujemy interfejs użytkownika. Tworzymy coraz więcej

dokumentów, czytanych bądź też nie przez kierownictwo i klien-

tów. Jednak, gdy programiści, testerzy, projektanci skupiają się

tylko na tworzeniu dokumentacji, projekt zmienia się w efektow-

ną fabrykę makulatury.

Pewien poziom dokumentacji jest jak najbardziej koniecz-

ny w celu zapewnienia sprawnej komunikacji między klientem

a zespołem wykonującym powierzone zadanie. Również we-

wnątrz zespołu, pomiędzy osobami pełniącymi różne role, do-

kumentacja umożliwia zapisanie podjętych decyzji, ich uza-

sadnienie oraz stanowi punkt odniesienia w przyszłych dys-

kusjach.

W sytuacji, gdy tworzenie dokumentów przybiera formę

głównego celu projektu, mamy do czynienia z antywzor-

cem. Programiści powoli zapominają jak wygląda kod, pro-

jektanci są coraz bardziej sfrustrowani wprowadzaniem ko-

lejnych poprawek do pieczołowicie wersjonowanych doku-

mentów. Jedynie menadżerowie cieszą się, że coś się dzie-

je w projekcie, że są efekty. Klient, zaś od czasu do czasu

występuje z zapytaniem, jak postępują prace Jednak szyb-

ko milknie przywalony setkami stron oraz prośbami o ko-

mentarze. Jedyny plus istnienia tego typu projektów to sys-

tem hyperlinków, na którym opiera się Internet. Gdyby nie

tomy dokumentacji i konieczność szybkiego odwoływania

się pomiędzy stronami, zapewne nigdy nieprędko wymyślo-

no by tego typu rozwiązanie.

Gdy czujesz, że już tak dalej nie możesz, że przeno-

szenie dokumentów do nowego szablonu już Cię nie cie-

szy, a funkcje popularnych pakietów biurowych znasz le-

piej niż język programowania, którym zarabiasz na życie

– czas powiedzieć dość! Zaproponuj kierownikowi, iż za-

miast kolejnego dokumentu „do 20 stron” stworzysz pro-

totyp. Jeśli jesteś projektantem, może zaproponujesz do-

świadczenie architektoniczne. Nie musisz przecież znać

szczegółów działania wszystkich warstw aplikacji, zawsze

można stworzyć moduły symulujące działanie jeszcze nie

zaprojektowanych elementów.

Przede wszystkim nie pozwól, aby wycięto więcej drzew

tylko na potrzeby kolejnego dokumentu, którego nikt nie prze-

czyta. Jeśli wiesz, że dokumentacja, którą przyszło Ci pisać,

nie zostanie przeczytana zgłoś to kierownikowi projektu. An-

tywzorzec ten naprawdę łatwo rozwiązać, a wspomniane two-

rzenie prototypowych implementacji naprawdę bardzo po-

może zarówno w prowadzeniu projektu jak i w rozmowach

z klientem.

Oczywiście są sytuacje, w których wykonanie dokumen-

tacji jest konieczne. Większość projektów dotyczących admi-

nistracji publicznej musi zapewniać łatwość zmiany firmy do-

starczającej rozwiązanie, stąd wszelkie dokumenty projek-

towe są pieczołowicie przygotowywane i analizowane. Lecz

nawet i w tym przypadku, nikt nie podejmuje się sporządza-

nia interpretacji np. ustaw, które wpływają na realizację zadań

w programie. Jeśli np. Twój zespół buduje światowej klasy kom-

ponent do zarządzania hodowlą słoni afrykańskich, musisz do-

kładnie opisać API. Należy oprócz kodu dostarczyć przykłady,

ich opis słowny, może także prezentacje multimedialne. Jednak

mija się z celem np. pisanie esejów o samej hodowli słoni – klient

najprawdopodobniej zna temat dużo lepiej niż Ty.

Budując rozwiązanie informatyczne zawsze patrz na cel,

który masz osiągnąć, dokumentacja jest tylko jednym z narzę-

dzi, które ma Ci w tym pomóc.

Marudy

Jak już zapewne zauważyliście niemal wszystkie akapity do-

tyczą zachowań ludzi biorących udział w projektach. Jednym

z bardzo powszechnych zachowań jest narzekanie na realizo-

wany projekt. Brak entuzjazmu, nadziei na sukces jest bardzo

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 5/2006

częsty, szczególnie wśród programistów, którzy mieli za sobą

kilka projektów. Nawet ciekawy projekt, wykonany w techno-

logii, której się dopiero uczymy, z bogatym sponsorem, czy-

li marzenie każdego programisty, może stać się koszmarem,

gdy wciąż powtarzamy sobie, że to się nie uda. Mówimy „mia-

ło być tak pięknie, a wyszło jak zawsze” – jednak czy mamy

podstawy, aby tak mówić już przy pierwszym niepowodzeniu?

Z pewnością nie – utrzymanie dobrych morali i zarządzanie

zasobem w postaci Ciebie – programisty, to obowiązek kierowni-

ka projektu. Czy będzie to piątkowe wyjście na miasto, czy zaję-

cia z budowania zespołu (ang. team-building), a może pizza za-

mówiona na koszt firmy w tą szczególnie ciężką noc przed odda-

niem produktu – wszystko ma na celu jedno, podtrzymanie du-

cha zespołu. W przywołanej już książce „The soul in the New

Machine”, autor słusznie zauważa, że to ludzie są najważniejsi

w projekcie. Dobrze przeszkoleni, zadowoleni z wykonywanych

zadań, pracujący w zgranym zespole, są wydajni.

Zespół marud, rzadko odnosi sukces i choć pracują ty-

le samo czasu, używając tych samych technologii, wykonu-

je znacznie gorszą pracę. Czujesz, że już powinien być piątek

i siedzisz w pracy za karę, idź do menadżera – jest przecież

także po to, aby zmienić ten stan rzeczy. Jeśli Twój przełożo-

ny jeszcze nie wie, że zadowolony pracownik to dobry pra-

cownik, być może czas mu to uświadomić. Tylko w taki spo-

sób można naprawić, antywzorzec „marudy”.

Trudni ludzie

Często w projekcie trafiają się osoby, które ogólnie moż-

na określić jako trudne. Czy to zwolennik jednej konkret-

nej technologii, który podważa sensowność rozwiązań pro-

ponowanych przez inne osoby. Może to być osoba egocen-

tryczna, która w każdym działaniu musi widzieć personalną

korzyść. Zdarzają się także programiści introwertycy, któ-

rzy cierpią po każdym zgłoszeniu błędu do modułu, który

był ich dziełem.

Trudne osoby są wszędzie, mogą nimi też być osoby kie-

rujące projektem. Zazwyczaj osoba taka wprowadza niezdro-

wą atmosferę w zespole, doprowadzając do podwyższania

i tak już dużego stężenia stresu towarzyszącego projektom in-

formatycznym.

Każdy zna sytuacje, gdy prowadzenie projektu utrudnia-

ły nadplanowe inspekcje kodu, nadzorowanie każdej minuty

pracy pracowników. Dostęp do zasobów sieciowych ograni-

czony do kilku podstawowych stron, zablokowane narzę-

dzia do komunikacji interpersonalnej (ang. Instant Messa-
ging), tego typu ograniczenia swobody pracowników, wpro-

wadzają niekorzystna atmosferę pracy. „Trudni ludzie” na

stanowiskach kierowniczych najczęściej nie zauważają pro-

blemu dziwiąc się tylko iż zespół staje się coraz mniej efek-

tywny, ma kłopoty z wymianą wiedzy, a z czasem z podsta-

wową komunikacją.

Zachowań tego typu osób nie sposób uniknąć, chcąc bu-

dować własną karierę lub promują z uporem narzędzia, które

poznali w poprzednich projektach, a nie są adekwatne do pro-

blemu. Wszak nawet prosty system F-K może być polem do

popisu i można go zrealizować z wykorzystaniem rozproszo-

nej bazy XML. Z drugiej strony, może natrafiłeś na osobę, któ-

ra odkąd nauczyła się posługiwać narzędziami CASE w celu

budowania diagramów ERD, nie może się przełamać i wyko-

rzystać możliwości UML’a.

W szczególnie niebezpiecznych przypadkach mamy do

czynienia nawet z sabotażystami. Osoby takie potrafią rozsie-

wać plotki np. o redukcji zatrudnienia, powodując, iż członko-

wie projektu zmieniają miejsce pracy. Tego typu zachowanie

na całe szczęście jest dość sporadyczne i ma na celu głównie

nieuczciwą eliminację konkurencji.

Nie życzę też nikomu pracować z osobami broniącymi

swojej pozycji w firmie. Istnieją projekty widma, które tak na-

prawdę nie mają celu. Prowadzone jest fikcyjne raportowanie,

klient otrzymuje sprzeczne komunikaty, efekty ciężkiej pracy

programistów są pieczołowicie testowane, po czym nigdy nikt

ich nie wykorzystuje. Cel – ochrona kadry zarządzającej, po-

siadającej poparcie kierownictwa firmy.

Temat problemu trudnych osobowości z pewnością można

rozwijać. Każdy z Nas ma też zapewne w sobie, choć część

cech tego typu osób. Tylko odpowiednie kontrolowanie wła-

snych emocji i skupienie się na celu projektu może przynieść

powodzenie przedsięwzięcia.

Muszę jednak zmartwić tych, którzy szukają podpowiedzi,

jak rozwiązać problem „trudnych” współpracowników. Stosowa-

nych rozwiązań jest naprawdę wiele, jednak tego typu osoby są

odporne na wszelką krytykę i sugestie. Spotkałem się z sytuacją,

gdy dla pewnego menadżera stworzono specjalny odrębny dział,

w nim miał stanowisko z bardzo ważną i ledwo mieszczącą się

na wizytówce nazwą. W przypadku sprawnie zarządzanych or-

ganizacji, trudne osobowości konfrontuje się ze sobą, np. powie-

rzając im prowadzenie wspólnego projektu. W niektórych przy-

padkach wystarczy szczera rozmowa, w innych odseparowanie

problemu, którym zajmuje się trudna osoba – tak, aby nie parali-

żowała ona prac całego zespołu.

Gdy jednak tego typu metody nie odnoszą skutków, pozo-

staje polecić naszą czarną owcę agencji rekrutacyjnej. Pozby-

cie się z zespołu tego typu osoby, która najczęściej szczęśli-

wa jest, gdy otwierają się przed nią drzwi do kariery, jest naj-

lepszym rozwiązaniem problemu.

Wiedza plemienna

Z pewnością znasz projekty, które mimo braku formalnej fazy

projektowania odniosły sukces. Stworzenie portalu internetowe-

go w przeciągu tygodnia przez zespół sprawnych programistów,

z wykorzystaniem praktyk XP jest jak najbardziej możliwe. Ktoś

rozszerza tego typu system o moduł integrujący z jednym źró-

dłem danych, ktoś inny zapewnia mechanizmy synchronizacji ze

starszym, ale wciąż używanym systemem firmy. System się roz-

rasta, początkowo prowadzony mały projekt, wymyka się spod

kontroli, ale że wszyscy pracują w zgranym zespole, nikt nie wi-

dzi potrzeby dokumentowania zmian, czy też tworzenia projek-

tu lub choć ogólnej architektury. Pewnego dnia do projektu przy-

chodzi nowa osoba – i okazuje się, iż nie znając zastanych me-

chanizmów nie jest w stanie rozpocząć pracy. Nikt, sam przecież

obciążony poprawianiem wciąż wychwytywanych błędów, nie

ma czasu, aby pomóc świeżemu członkowi zespołu.

Napotykamy kolejny antywzorzec w zarządzaniu projekta-

mi. To co z początku było atrakcyjne, czyli szybkie budowanie

rozwiązania informatycznego oraz rozszerzanie jego możliwo-

ści bez obciążenia dokumentacją, mści się, gdy należy doko-

nać zmian w systemie, lub wprowadzić do prac nową osobę.

Trudno jest, bowiem wskazać wszystkie zależności pomiędzy

istniejącymi komponentami nie posługując się przy tym doku-

mentacją architektoniczną...

Antywzorce w zarządzaniu projektami informatycznymi

Wiedza, którą posiadają najczęściej tylko osoby bezpo-

średnio zaangażowane w projekt, musi być przenoszona do

postaci formalnej. Samo spisanie i udokumentowanie proce-

sów zachodzących w aplikacji powoduje najczęściej popra-

wienie kilku do kilkuset błędów. Nie mówiąc już o zaletach

związanych z ułatwionym rozszerzaniem systemu oraz jego

konserwacją.

Warto zauważyć, że nowy członek zespołu projektowe-

go może obawiać się o swój wizerunek i przez długi czas nie

przyzna się, że nie rozumie jak system działa. Co więcej oso-

ba, którą oddelegowano do wprowadzenia nowego programi-

sty w zadanie może posługiwać się nieznaną mu terminolo-

gią lub opisywać wykorzystywanie technologii dotąd niezna-

nej programiście?

Mamy tu do czynienia z kolejnym antywzorcem. Nowy

członek zespołu nawet, jeśli dotąd programował jedynie

w C++ wykorzystując bibliotekę Qt do generowania GUI,

będzie nadzwyczaj często przytakiwał osobie tłumaczą-

cej zaawansowane wykorzystanie Windows.Forms i plat-

formy .NET.

Jeśli jesteś w tej sytuacji, powiedz, że czegoś nie rozu-

miesz. Skorzystasz z wiedzy zespołu, a zespół zyska no-

wego kolegę – przecież każdy lubi poczuć, iż jego dzieło

lub wiedza, są przydatne.

Nie pozwól, aby wiedza czy to merytorycznie dotyczą-

ca projektu, czy ogólnie dostępna, ale Ci nie znana by-

ła zamknięta wewnątrz plemienia. Starszyzna projekto-

wa ma obowiązek podzielić się wiedzą, aby uniknąć błę-

dów w komunikacji. Nie ma gorszej sytuacji od tej, gdy jed-

na ze stron myśli, iż jest w pełni zrozumiana tylko dlatego,

iż widzi nieśmiałe potrząsanie głową (na której widać ozna-

ki rwania włosów).

Podsumowanie

Powyżej przeprowadzone rozważania nie wyczerpują oczy-

wiście tematu. Problem błędów w zarządzaniu projektami,

wykrycia antywzorców i wskazania prawidłowych rozwią-

zań to niewyczerpany materiał na wiele książek. Punkt wi-

dzenia uczestnika projektu – programisty, architekta, teste-

ra – jest szczególnie ważny. Musimy zdać sobie sprawę z te-

go, że większość ludzi niemal naturalnie wychwytuje działa-

nia błędne i tylko lenistwo, duma, czasem brak asertywno-

ści powoduje, iż tkwimy w potrzasku. Skutkiem tego pracuje-

my w projekcie, w którym rozpoznajemy Antywzorzec. Stresu-

je to Nas, demotywuje, w efekcie zniechęca do pracy. W nie-

długim okresie to my możemy stać się powodem powstawa-

nia kolejnych problemów, a cały projekt będzie coraz bliżej

klęski niż sukcesu.

Pamiętając o tym oraz o tych kliku wskazówkach, któ-

re starałem się przekazać w tym tekście, proszę o odrobi-

nę zaangażowania. Nie twierdzę, że zebrane tu uwagi wy-

czerpują temat. Poruszają go jednak choćby pobieżnie, do-

starczając Ci podstawowej wiedzy do identyfikacji antyw-

zorców.

Jeśli więc wiesz, jak możesz poprawić nie tylko swój kod,

ale i otoczenie, czemu tego jeszcze nie zrobiłeś? n

Telefonia VoIP Multimedialne sieci IP

Autorzy: Marek Bromirsk

Wydawnictwo: BTC

ISBN: 83-60233-07-1

Ocena: 4

Gdy po raz pierwszy dostałem i zobaczyłem tę książkę zachwyciło mnie jej wydanie, gru-

ba oprawa, 250 stron tekstu ale chwile później mój zachwyt przerodził się w przerażenie.

Po przeczytaniu spisu treści, który pełen jest niezrozumiałych dla początkujących skrótów

i nazw, pomyślałem „nie przebrnę” przez tę książkę. Mile się zaskoczyłem, gdy okazało się,

że autor, wykładowca Politechniki Warszawskiej i Instytutu Łączności, opisuje wszystko

w sposób zrozumiały i interesujący z pewną dozą humoru, czyniąc lekturę bardziej przystęp-

ną. Książka ta, a jest to raczej monografia, opisuje systemy: H.323, SIP, współpracę mię-

dzy tymi systemami a także przenoszenie danych przez zapory ogniowe. Protokół H.323 zo-

stał potraktowany najdokładniej, jako podstawowy system służący do realizacji usług multimedialnych czasu rzeczywistego

w sieci pakietowej oraz IP; począwszy od modelu OSI, przez architekturę systemu a kończąc na mechanizmach sterowania

jakością oraz usługami dodatkowymi. Podobnie system SIP (Session Initiation Protocol), który jest typowym mechanizmem

sygnalizacyjnym warstwy aplikacyjnej, opis jego doskonale uzupełnia się z H.323. Dzięki rozdziałowi pt. Przenoszenie da-

nych przez zapory sieciowe zrozumiałem mechanizmy rządzące się w tego typu połączeniach a także poznałem sposoby

omijania pewnych niedogodności. Telefonia VoIP prezentuje całe „zaplecze” technologiczne wykorzystywane przez Voice

over IP. Książka jest bogato ilustrowana a także zawiera sporą ilość schematów i wykresów, które pomagają w zrozumieniu

materiału bądź, co bądź nie łatwego. Książkę mogę śmiało polecić: początkującym, którzy nie mieli bladego pojęcia o Vo-

IP, średnio i zaawansowanym, którzy wiedzą, z czym to się je a także studentom, którzy mają monogram z tego lub podob-

nego systemu.

Zrecenzował: Konrad Synoradzki

http://www.btc.pl/

Księgozbiór