Inżynieria
oprogramowania
Antywzorce w zarządzaniu
projektami informatycznymi
Stefan Turalski
rtykuł o zarządzaniu projektami informa-
tycznymi w czasopiśmie dla deweloperów? Wymagania klienta
ACzyżby i już tutaj sięgały macki wszechmoc-
nych menadżerów? Otóż nie, artykuł ten jest adre-
Architektura
sowany do Ciebie  dewelopera, biorącego udział
w projekcie informatycznym.
Na co dzień żyjesz w świecie pełnym wyzwań, być
Projekt
może tworzysz przełomowe rozwiązanie lub utrzymu-
jesz starożytny system informatyczny. Musisz doko-
Kodowanie
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ś-
Testowanie
by o wykorzystanie zaległych urlopów. Realizujesz za-
danie, do którego potrzeba 1.4241 dewelopera. Brzmi
Rysunek 1. Elementy przykładowego procesu
znajomo? Jeśli tak, ten artykuł jest właśnie dla Ciebie.
wytwarzania oprogramowania
Postaram się wskazać najczęściej pojawiające się błę-
dy w zarządzaniu projektami. Tematyka poruszona w zachowania ludzkie prowadzące do powstawania
artykule to antywzorce projektowe, złe praktyki rozpo- złych praktyk to między innymi duma, lenistwo, za-
znawane i opisywane od lat. Jeśli chcesz wiedzieć, dla- chłanność, pycha czy ignorancja.
czego tak wiele projektów kończy się niepowodzeniem, Wzorce projektowe często kojarzone są jedynie
a idolem dla większości z Nas jest Dilbert i Chuck Nor- z konstrukcjami programistycznymi. Antywzorce projek-
ris  zapraszam do lektury. towe omówione poprzednio, dotyczyły głównie zadań
związanych z tworzenia oprogramowania. Nie można
Antywzorce projektowe jednak zapomnieć, iż wzorce i antywzorce w projektach
Podstawowe informacje dotyczące antywzorców za- informatycznych napotykamy na każdym etapie. Czy
warłem w artykule  Antywzorce projektowe (SDJ 2/ to podczas zbierania wymagań, tworzenia architektury
2006), dla przypomnienia jednak  kilka podstawo- systemu, kodowania, czy też w zarządzaniu projektem.
wych faktów.
Antywzorzec to opis złej praktyki  błędu popełnia- Błędy w zarządzaniu projektami
nego na tyle często, iż został zidentyfikowany, nazwa- Nim przejdziemy do omówienia poszczególnych antyw-
ny i udokumentowany. Podczas gdy wzorce projektowe zorców projektowych, pragnę poprosić Cię o jedno. Je-
prezentują poprawne rozwiązania pewnych klas pro- śli zauważysz, iż w Twoim projekcie wystąpił antywzo-
blemów, antywzorce wykorzystujemy w celu identyfika- rzec, porozmawiaj o tym z członkami zespołu. Zgłoś to
cji błędów w sztuce. Okazuje się, że człowiek jest na ty- menadżerowi i nie poddawaj nawet jeśli nie spotkasz
le skomplikowany, iż łatwiej zapamiętuje przykłady ne- się z pozytywną reakcją. Podstawowy antywzorzec to
gatywne niż pozytywne  z tego też powodu antywzor- brak świadomości istnienia antywzorców. Być może
ce są poręcznym narzędziem dydaktycznym. brzmi to enigmatycznie, zauważ jednak, iż gdy potra-
Antywzorzec nie byłby przydatny, gdyby zawie- fisz zidentyfikować błąd, potrafisz się przed nim ustrzec
rał tylko opis błędu. To, czego potrzebujemy i co zo-  wszak po to właśnie opracowuje się antywzorce!
stanie zaprezentowane również w niniejszym arty-
kule, to przykłady działań, które należy podjąć, aby  Don't Worry, Be Happy
naprawić popełniony błąd. Większość antywzorców Tytuł piosenki Bobby'ego McFerrin'a świetnie oddaje
jest efektem konkretnej postawy członków zespołu, stan jaki panuje w wielu projektach informatycznych.
w którym go zidentyfikowano. Poprzednio opisane 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-
Autor pracuje na stanowisku - projektant oprogramowa-
sad zarządzania procesem wytwarzania programowa-
nia w firmie Silicon & Software Systems Polska. Z za-
nia. Antywzorzec ten, zwany też inaczej  nil desperan-
interesowaniem przygląda się rozwojowi technologii IT,
dum (łac. nie ma powodu do rozpaczy) jest dość łatwo
dawno już straciwszy nadzieję, że jest w stanie ogarnąć
zidentyfikować. Jeśli słyszysz lub być może sam nie-
tą dziedzinę wiedzy.
Kontakt z autorem [e-mail] dawno wypowiedziałeś magiczne zaklęcie  Powiedz
mi, czego chcesz, a ja to zakoduję - masz do czynienia
46
www.sdjournal.org
Software Developer s Journal 5/2006
Antywzorce w zarządzaniu projektami informatycznymi
z tym antywzorcem. Myślisz, że nie potrzebujesz projektu syste- Można zaryzykować stwierdzenie, że jeśli podejmiemy się
mu? Nie ma potrzeby kłopotać klienta i spotykać się w celu prze- zarządzania projektem i zatrudnimy menadżera, niemal w 100%
dyskutowania wymagań? Piszesz doskonały kod, który nie po- pewne jest, iż podejmie on, choć jedną nieracjonalną decyzję.
trzebuje testów? Proszę powiedz, że na żadne pytanie nie odpo- Nie ma ludzi nieomylnych i kontrola samego procesu zarządza-
wiedziałeś twierdząco. nia też jest konieczna. W przeciwnym przypadku otrzymamy
Niestety, brak świadomości istnienia procesu wytwarzania projekt, który stanie się typowym z
ródłem antywzorców w zarzą-
oprogramowania prowadzi do przekroczenia kosztów budowy dzaniu. Akcje zapobiegawcze w tym przypadku sprowadzają się
rozwiązania informatycznego, zerwania kontraktu, czy też stwo- praktycznie do podnoszenia kwalifikacji menadżerów. Wraz ze
rzenia nikomu nie potrzebnego systemu. zbieraniem doświadczenia, osoby kierujące projektem zdają so-
Przykładem może być tu projekt dotyczący stworzenia Intra- bie sprawę z najczęściej popełnianych błędów i potrafią ich uni-
netu w pewnej firmie. Projekt został zaplanowany na 2 tygodnie, kać. Z punktu widzenia programisty warto zaznaczyć, iż to wła-
deweloperzy, aby lepiej współpracować pojechali kodować do śnie Nas często pyta się o oszacowanie czasu projektu  jeśli
siedziby klienta. Po 2 miesiącach stworzono zalążek systemu, zrobimy to z
le, lub przeoczymy pewne zadania, z pewnością za-
który pracownicy klienta przeklinali, bo chociaż był piękny, to pra- płacimy za to w przyszłości.
cował bardzo wolno. Nikt nie przewidział, że zespół klienta to po-
nad 2 tysiące pracowników, znacznie obciążających serwer Intra- Marsz ku klęsce
netu. Co więcej, mimo, że deweloperzy twierdzili, iż spełnili wy- W znanej większości menadżerów książce Edwarda Yourdon'a
magania klienta, ten nie chciał zapłacić uzgodnionej kwoty. Ja-  Death March , autor opisał i zdefiniował grupę projektów z góry
ko powód podał brak 75% wymaganej funkcjonalności. Czy tylko skazaną na niepowodzenie. Podana definicja zakłada, iż projekt
zbiegiem okoliczności było to, że pozostałe 25% zostało wykona- skazany na klęskę to taki, w którym brakuje ponad 50% zasobów.
ne perfekcyjnie i pracowało na potrzeby działu HR, z którym są- Z pewnością powierzono Ci nie raz zadanie, które powinno wy-
siadował pokój programistów? Na całe szczęście tego typu sytu- konać kliku programistów To przykład braku prawidłowego osza-
acje zdarzają się dość rzadko. cowania kadry potrzebnej do realizacji projektu. Analogicznie,
Większość menadżerów ma już świadomość istnienia pro- o 50% za niski budżet lub zadeklarowany czas trwania projektu
cesu zarządzania projektem informatycznym, a i dla dewelo- krótszy od porównywalnych projektów o 50%, prowadzi do fiaska
perów znajomy jest Rysunek 1. danego przedsięwzięcia. Podobne założenie dotyczy także celów
Jeśli jednak nie wiesz, czym jest proces wytwarzania opro- projektu, które często nie tylko trochę, ale nawet o ponad 50%
gramowania, ten artykuł Ci nie pomoże. Temat ten stanowczo mają przewyższać standardowo opracowywane rozwiązania.
wymaga zgłębienia i jest zbyt rozległy, aby poruszyć go na tych Doświadczenie uczy, iż niemal każdy projekt informatyczny
kilku stronach. Nie muszę chyba mówić, że to będzie także Two- to marsz ku klęsce, według definicji Yourdon'a. Nie należy, więc
ja wina, jeśli np. nie przetestowane rozwiązanie zostanie (w naj- od razu załamywać rąk. To co potrafi dobry menadżer projektu,
lepszym przypadku) zwrócone do kosztownych poprawek. Je- to identyfikacja tych zasobów, które są krytyczne i stwarzają ry-
śli więc posiadasz odpowiednie doświadczenie, nie zgadzaj się zyko w projekcie. Następnie z wykorzystaniem dostępnych środ-
na łamanie podstawowych zasad i dobrych praktyk wytwarza- ków, ryzyko to można próbować minimalizować.
nia oprogramowania. Podstawowy antywzorzec rozwiązuje się Przykładem może być mała firma programistyczna, która
bardzo prosto  należy wprowadzić proces zarządzania projek- choć posiada bardzo niewielkie środki zobowiązała się stwo-
tem. Niestety bez pracy nie ma kołaczy lub jak mawiają Anglosa- rzyć złożony system o bardzo specjalistycznej funkcjonalności
si  No pain, no gain . (nie trzeba chyba wspominać, iż o dziedzinie problemu, któ-
ry miał wspierać system, w zespole programistów nikt nic nie
Nieracjonalne zarządzanie wiedział). Jedyne, co przemawia na jej korzyść to czas projek-
Załóżmy, że dysponujemy kierownictwem zespołu rozumieją- tu, który jest dość luz
no określony.
cym, że planowanie jest potrzebne. Konieczne jest upewnie- W takim przypadku, sprawny menadżer może zapropono-
nie się, że menadżerowie nie popełniają podstawowych błędów wać klientowi dostarczanie kolejnych modułów, jako wyników ko-
w planowaniu. Śledzenie projektu na każdym z etapów prac jest lejnych etapów projektu. Firma miast narażać się na kredyt, bę-
niewątpliwie potrzebne, jednak nikt nie potrafi poprawnie osza- dzie miała stałe z
ródło dochodów, mały zespół łatwiej przetestu-
cować zadań zależnych od specyfikacji wymagań klienta, które je, zaprojektuje, wykona i wdroży niewielkie moduły. Korzyść zaś
jeszcze nie zostały dostarczone. z przyrostowego wytwarzania oprogramowania, to w tym przy-
Błędy w zarządzaniu projektem zdarzają się zawsze, mogą padku możliwość szybkiej reakcji na potrzeby klienta, który prze-
przyjąć rozmiar antywzorców opisanych poniżej, takich jak Marsz cież niekoniecznie musi posiadać całą oczekiwaną funkcjonal-
ku klęsce, czy Zamrożenie w fazie analizy. Najczęściej powodu- ność od razu. Najważniejsze w przypadku zidentyfikowania
ją je tzw.  Trudni ludzie , których obecność w projekcie jest tak- antywzorca  marsz ku klęsce jest odpowiednie zidentyfiko-
że jednym z antywzorców. Nie potrafiąc lub nie znając specyfi- wanie przyczyny marszu. Gdy nic innego już nie pomaga, pro-
ki projektu podejmują błędne decyzje. Nowy menadżer w projek- ponuję uciekać. Marsz trwa często do kilku lat, w zależności
cie, który realizuje pewne zadania niespełna od roku, może błęd- od zasobów organizacji. Niestety kadra kierownicza, która nie
nie alokować ludzi. Brak mocy decyzyjnej może powodować, iż potrafi odpowiednio zareagować i zapobiec skutkom marszu,
przez kilka pierwszych miesięcy tworzy się dokumenty zamiast przyczyni się tylko do klęski projektu.
rozpocząć kodowanie. Na efekty nie trzeba długo czekać. Sys-
temy, które powstawały w przeciągu kliku tygodni nie są odpo-  Mushroom management
wiednio przetestowane, najczęściej dlatego, iż menadżer nie za- W kolejnej kultowej już niemal książce  The Soul Of A New
łożył tego typu zadania. Machine Tracy Kidder opisuje projekt informatyczny, w któ-
Software Developer s Journal 5/2006 www.sdjournal.org
47
Inżynieria
oprogramowania
rym udział biorą młodzi deweloperzy oddzieleni od oczekiwań bez kompleksowej wiedzy o dziedzinie problemu. Możemy mieć
klientów. Hodowla grzybów, jak potocznie można przetłuma- do czynienia ze szczególnie mocnym przywiązaniem do pewnej
czyć anglojęzyczną nazwę antywzorca, to sytuacja niestety technologii, pochodzącej z poprzedniego projektu menadżera, a
nazbyt częsta w projektach. nie adekwatnej do potrzeb aktualnego projektu. Zachowania te-
Kierownictwo projektu, architekci, specjaliści analizujący go typu blokują postęp prac projektowych lub jak sugeruje na-
wymagania klientów, tworzą dokumentację oraz modele opi- zwa antywzorca  zamrażają je.
sujące przyszły system. Sami programiści, czyli autorzy roz- Nawet w sytuacji, gdy projekt wyszedł poza fazę analizy, za-
wiązania nie są dopuszczani do rozmów z klientem. Skutkiem zwyczaj długą i dostarczającą bardzo dokładnej wiedzy, anty-
tego dostarczone rozwiązanie często nie dostarcza oczekiwa- zwozrzec ten może ujawnić się ponownie. Czasem podczas pro-
nej przez klienta funkcjonalności. jektowania, implementacji lub testowania, okazuje się że analiza
Często programiści padają także ofiarą dość swobodne- nie przewidywała pewnych sytuacji lub po prostu jest sprzeczna
go traktowania dokumentacji projektowej przez samego klien- z rzeczywistymi wymaganiami klienta. Menadżerowie, którzy już
ta. Osobiście byłem świadkiem projektów, w których klient od- poświęcili zasoby projektu na wykonanie analizy, najczęściej bę-
rzucił przedstawione mu rozwiązanie, mimo iż wcześniej zaak- dą bronili już istniejących założeń. A przecież proces wytwarza-
ceptował przygotowaną dokumentację. Bardzo prostą akcją za- nia oprogramowania zakłada zmiany. Jeśli więc pojawi się ko-
pobiegawczą jest opracowanie prototypu systemu. Przy możli- nieczność ich wprowadzenia, należy odpowiednio na nie zare-
wościach oferowanych przez nowoczesne środowiska i techno- agować, szacując wpływ zmiany na już istniejący system. Pod
logie, przygotowanie tego typu przykładowego rozwiązania, nie żadnym pozorem nie można stwierdzić, iż raz wykonana analiza
pochłania dużych zasobów, a jest nieocenione w trakcie rozmów jest już dziełem ostatecznym.
z klientem. Aby uniknąć sytuacji, gdy programista pisze program Jeśli jako programista zauważasz tego typu błędy w za-
dla siebie, a nie dla użytkownika, należy go oswoić z problemem. rządzaniu projektem, zwróć proszę uwagę kierownictwu. Do-
Mimo, iż nasze środowisko jest postrzegane przez pryzmat ste- brze wykonana analiza to analiza, którą można zmieniać.
reotypów, programista nie może być izolowany od klienta i od je- Panujące obecnie podejście obiektowe do projektowania
go potrzeb. Jeśli odpowiednio wcześnie nie zasygnalizujesz, że programowania z definicji jest przygotowane na rozszerzanie.
brakuje Ci jasnej wizji systemu, nie mówiąc już o szczegółach re- Coraz popularniejsze podejście architektur zorientowanych
alizacji poszczególnych procesów  sam przyczynisz się do po- na usługi (ang. Service Oriented Architecture) również zakła-
rażki tego projektu. da, iż rozwiązanie  kompletny system informatyczny, zosta-
nie oparte o zestaw usług podatnych na zmiany (z tego to po-
Zamrożenie w fazie analizy wodu usługa najczęściej prezentuje jedynie interfejs, ukrywa-
Brak fazy analizy w projekcie informatycznym jest niemal niewy- jąc szczegóły implementacyjne).
obrażalny. Wszak, zarówno klient jak i zespół budujący rozwią- Nie należy więc dążyć do zamknięcia fazy analizy i jej za-
zanie informatyczne musi uzgodnić zakres funkcjonalności two- mrożenia. Wręcz przeciwnie, w dobrze zarządzanym projek-
rzonego systemu. I choć nieczęsto można mówić o doskonale cie, faza analizy istnieje w tle. Każda zmiana wynikająca czy
przeprowadzonej analizie, istnieją projekty, w których za cel po- to z zmiany wymagań klienta, czy to z dostrzeżonych niespój-
stawiono sobie stworzenie idealnego zbioru wymagań funkcjo- ności lub luk w analizie, powoduje powrót do już poczynionych
nalnych oraz projektu systemu. Projekty, w których faza analizy założeń i ich rewalidację.
przeciąga się, są szczególnie niebezpieczne, gdyż najprawdopo- Podsumowując, faza analizy jest niewątpliwie kluczowa i bar-
dobniej nigdy nie przejdą w fazę implementacji systemu. Szcze- dzo ważne jest prawidłowe jej przeprowadzenie. Należy, jednak
gólnie dobrze znają ten antywzorzec osoby, które miały okazję pamiętać, aby nie przesłoniła nam ona celu, jakim jest stworze-
pracować w projektach wielokrotnie rozpoczynanych całkiem od nie rozwiązania informatycznego. A podczas prowadzenia prac
nowa. Przyczyną może być tu zmiana kierownictwa lub główne- projektowych należy zapewnić dobre zarządzanie zmianami
go celu projektu. wpływającymi na już poczynione założenia.
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- Plan
sadą, iż jeśli raz dokonaliśmy analizy systemu nigdy już nie wró- Każdy kto pamięta czasy poprzedniego ustroju (PRL u),
cimy do tej fazy. Doświadczenie uczy, że dobrze przeprowadzo- z pewnością wie czym jest PLAN. Kto zaś nie pamięta, wy-
na analiza, to nie ta, która dostarcza kompleksowej wiedzy o bu- starczy, że rzuci okiem na kroniki filmowe z poprzedniej epoki.
dowanym rozwiązaniu, w tym o najmniejszych jego szczegółach. Plan na kilka lat, pomagał zarządzać całym krajem. Scentrali-
Dobra analiza to taka, która pozwala na łatwe wprowadzanie zowane centrum dowodzenia, najpierw plan taki tworzyło, na-
zmian, które z pewnością pojawią się w przyszłości. stępnie go egzekwowało, tzn. wymagało jego wykonania. Re-
Jak widzimy na Rysunku 1. projekt informatyczny można
traktować zgodnie z modelem wodospadowym, w którym kolej-
Bibliografia
ne fazy następują po sobie. Doświadczony menadżer wie jed-
nak, że budowanie systemu informatycznego to proces przyro-
l
AntiPatterns: Refactoring Software, Architectures, and Projects
stowy. Po wykonaniu pracy, np. w fazie implementacji lub testo-
in Crisis
wania, być może będziemy musieli powrócić do faz początko-
l
William J. Brown, Raphael C. Malveau, Hays W. McCormick
wych w celu weryfikacji pierwotnych założeń.
III, Thomas J. Mowbray  AntiPatterns in Project Management
l
Menadżerowie mogą nalegać na dostarczanie im kompletnej William J. Brown, Hays W. McCormick III, Scott W. Thomas
l
http://c2.com/cgi/wiki?AntiPattern
analizy systemu przed podjęciem prac projektowych. Być może
kierownictwo projektu boi się podjąć decyzję o realizacji systemu
48
www.sdjournal.org
Software Developer s Journal 5/2006
Antywzorce w zarządzaniu projektami informatycznymi
alna realizacja była najczęściej nierealna, a raportowane po- a zespołem wykonującym powierzone zadanie. Również we-
stępy i wyniki istniały jedynie na papierze. wnątrz zespołu, pomiędzy osobami pełniącymi różne role, do-
Sytuaja podobna ma niestety miejsce w wielu projektach kumentacja umożliwia zapisanie podjętych decyzji, ich uza-
informatycznych. Z własnego doświadczenia mogę przywołać sadnienie oraz stanowi punkt odniesienia w przyszłych dys-
taką oto historię. kusjach.
Menadżer projektu, niekoniecznie dysponujacy wiedzą in- W sytuacji, gdy tworzenie dokumentów przybiera formę
formatyczną zbudował zręby planu. Podlegli mu kierownicy ze- głównego celu projektu, mamy do czynienia z antywzor-
społów zdefiniowali grupy zdań, wreszcie programiści wyodręb- cem. Programiści powoli zapominają jak wygląda kod, pro-
nili pojedyńcze zadania. Oczywiście dzieło takie było nie do za- jektanci są coraz bardziej sfrustrowani wprowadzaniem ko-
akceptowania przez zarząd firmy wykonującej projekt. Plan prze- lejnych poprawek do pieczołowicie wersjonowanych doku-
kraczał terminy, zakładał szkolenia oraz powiększenie zespołu. mentów. Jedynie menadżerowie cieszą się, że coś się dzie-
Zasiedliśmy więc do planowania raz jeszcze. Tym razem kosz- je w projekcie, że są efekty. Klient, zaś od czasu do czasu
ty się zgadzały, a kilka zadań sprytnie ukryliśmy tak, że projekt występuje z zapytaniem, jak postępują prace Jednak szyb-
został zaakceptowany. Gdy po prawie dwóch tygodniach wystar- ko milknie przywalony setkami stron oraz prośbami o ko-
towaliśmy, okazało się, że w planie nie przewidziano połowy za- mentarze. Jedyny plus istnienia tego typu projektów to sys-
dań. Natomiast metodę oszacowania czasu wykonania pozosta- tem hyperlinków, na którym opiera się Internet. Gdyby nie
łych zdań z powodzeniem można byłoby wykorzystać w syste- tomy dokumentacji i konieczność szybkiego odwoływania
mach gier losowych. się pomiędzy stronami, zapewne nigdy nieprędko wymyślo-
Plan w projekcie jest tylko narzędziem, pomagającym no by tego typu rozwiązanie.
oszacować koszt i czas. Za pomocą spisanych zadań, ułożo- Gdy czujesz, że już tak dalej nie możesz, że przeno-
nych w piękny wykres Gantta, nie oszczędzimy pieniędzy ani szenie dokumentów do nowego szablonu już Cię nie cie-
tez nie wstrzymamy czasu. Jeśli menadżer projektu naciska szy, a funkcje popularnych pakietów biurowych znasz le-
na wykonanie planu, kiedy widzisz, że zdania uległy zmianie, piej niż język programowania, którym zarabiasz na życie
musisz to zasygnalizować.  czas powiedzieć dość! Zaproponuj kierownikowi, iż za-
Głównym zadaniem menadżera w projekcie jest zapewnienie miast kolejnego dokumentu  do 20 stron stworzysz pro-
dobrej komunikacji między osobami zespołu i zarządzanie pla- totyp. Jeśli jesteś projektantem, może zaproponujesz do-
nem projektu. To ta osoba jest odpowiedzialna za aktualizowanie świadczenie architektoniczne. Nie musisz przecież znać
danych i śledzenie postępów w projekcie. Jeśli nie otrzyma sy- szczegółów działania wszystkich warstw aplikacji, zawsze
gnału o zmieniających się wymaganiach klienta, lub o przeciąga- można stworzyć moduły symulujące działanie jeszcze nie
jacym się czasie wykonania szczególnie skomplikowanego zda- zaprojektowanych elementów.
nia, nie jest w stanie prawdłowo zareagować, w tym międy inny- Przede wszystkim nie pozwól, aby wycięto więcej drzew
mi oszacować ryzyka powodzenia projektu. Jeśli więc menadżer tylko na potrzeby kolejnego dokumentu, którego nikt nie prze-
projektu igoruje zgłaszane problemy z wykonaniem planu, jego czyta. Jeśli wiesz, że dokumentacja, którą przyszło Ci pisać,
kompetencje należy postawić pod znakiem zapytania. nie zostanie przeczytana zgłoś to kierownikowi projektu. An-
Odważę się stwierdzić, że nie istnieje projekt w którym nie tywzorzec ten naprawdę łatwo rozwiązać, a wspomniane two-
było problemów z oszacowaniem prawdłowego czasu i wysił- rzenie prototypowych implementacji naprawdę bardzo po-
ku jaki będzie potrzebny do stworzenia systemu informatycz- może zarówno w prowadzeniu projektu jak i w rozmowach
nego. Zawsze należy być otwartym na zmiany w planie pro- z klientem.
jektu, odpowiednio zarządzać terminami, kierować się tym, że Oczywiście są sytuacje, w których wykonanie dokumen-
dostarczony ma być system informatyczny (lub jego kompo- tacji jest konieczne. Większość projektów dotyczących admi-
nenty) a nie doskonale zrealizowany plan. nistracji publicznej musi zapewniać łatwość zmiany firmy do-
Nawiązując do wstępu tej seksji, wszyscy wiemy jak za- starczającej rozwiązanie, stąd wszelkie dokumenty projek-
kończył się projekt PRL. Obecnie coraz więcej projektów towe są pieczołowicie przygotowywane i analizowane. Lecz
wykorzystuje narzędzia służące do zarządzania czasem nawet i w tym przypadku, nikt nie podejmuje się sporządza-
oraz planowania, nie jest jednak ważne to czy się te narzę- nia interpretacji np. ustaw, które wpływają na realizację zadań
dzia wykorzystuje, ale jak się to robi. Plan w projekcie jest w programie. Jeśli np. Twój zespół buduje światowej klasy kom-
narzędziem, które ma pomóc w realizacji celu, nie jest ce- ponent do zarządzania hodowlą słoni afrykańskich, musisz do-
lem samym w sobie  należy o tym pamiętać eliminując ten kładnie opisać API. Należy oprócz kodu dostarczyć przykłady,
antywzorzec. 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
Projekt  drukarnia najprawdopodobniej zna temat dużo lepiej niż Ty.
W każdym projekcie nadchodzi moment tworzenia dokumenta- Budując rozwiązanie informatyczne zawsze patrz na cel,
cji. Zbieramy wymagania użytkowników, projektujemy rozwiąza- który masz osiągnąć, dokumentacja jest tylko jednym z narzę-
nie, proponujemy interfejs użytkownika. Tworzymy coraz więcej dzi, które ma Ci w tym pomóc.
dokumentów, czytanych bądz
też nie przez kierownictwo i klien-
tów. Jednak, gdy programiści, testerzy, projektanci skupiają się Marudy
tylko na tworzeniu dokumentacji, projekt zmienia się w efektow- Jak już zapewne zauważyliście niemal wszystkie akapity do-
ną fabrykę makulatury. tyczą zachowań ludzi biorących udział w projektach. Jednym
Pewien poziom dokumentacji jest jak najbardziej koniecz- z bardzo powszechnych zachowań jest narzekanie na realizo-
ny w celu zapewnienia sprawnej komunikacji między klientem wany projekt. Brak entuzjazmu, nadziei na sukces jest bardzo
Software Developer s Journal 5/2006 www.sdjournal.org
49
Inżynieria
oprogramowania
częsty, szczególnie wśród programistów, którzy mieli za sobą W szczególnie niebezpiecznych przypadkach mamy do
kilka projektów. Nawet ciekawy projekt, wykonany w techno- czynienia nawet z sabotażystami. Osoby takie potrafią rozsie-
logii, której się dopiero uczymy, z bogatym sponsorem, czy- wać plotki np. o redukcji zatrudnienia, powodując, iż członko-
li marzenie każdego programisty, może stać się koszmarem, wie projektu zmieniają miejsce pracy. Tego typu zachowanie
gdy wciąż powtarzamy sobie, że to się nie uda. Mówimy  mia- na całe szczęście jest dość sporadyczne i ma na celu głównie
ło być tak pięknie, a wyszło jak zawsze  jednak czy mamy nieuczciwą eliminację konkurencji.
podstawy, aby tak mówić już przy pierwszym niepowodzeniu? Nie życzę też nikomu pracować z osobami broniącymi
Z pewnością nie  utrzymanie dobrych morali i zarządzanie swojej pozycji w firmie. Istnieją projekty widma, które tak na-
zasobem w postaci Ciebie  programisty, to obowiązek kierowni- prawdę nie mają celu. Prowadzone jest fikcyjne raportowanie,
ka projektu. Czy będzie to piątkowe wyjście na miasto, czy zaję- klient otrzymuje sprzeczne komunikaty, efekty ciężkiej pracy
cia z budowania zespołu (ang. team-building), a może pizza za- programistów są pieczołowicie testowane, po czym nigdy nikt
mówiona na koszt firmy w tą szczególnie ciężką noc przed odda- ich nie wykorzystuje. Cel  ochrona kadry zarządzającej, po-
niem produktu  wszystko ma na celu jedno, podtrzymanie du- siadającej poparcie kierownictwa firmy.
cha zespołu. W przywołanej już książce  The soul in the New Temat problemu trudnych osobowości z pewnością można
Machine , autor słusznie zauważa, że to ludzie są najważniejsi rozwijać. Każdy z Nas ma też zapewne w sobie, choć część
w projekcie. Dobrze przeszkoleni, zadowoleni z wykonywanych cech tego typu osób. Tylko odpowiednie kontrolowanie wła-
zadań, pracujący w zgranym zespole, są wydajni. snych emocji i skupienie się na celu projektu może przynieść
Zespół marud, rzadko odnosi sukces i choć pracują ty- powodzenie przedsięwzięcia.
le samo czasu, używając tych samych technologii, wykonu- Muszę jednak zmartwić tych, którzy szukają podpowiedzi,
je znacznie gorszą pracę. Czujesz, że już powinien być piątek jak rozwiązać problem  trudnych współpracowników. Stosowa-
i siedzisz w pracy za karę, idz
do menadżera  jest przecież nych rozwiązań jest naprawdę wiele, jednak tego typu osoby są
także po to, aby zmienić ten stan rzeczy. Jeśli Twój przełożo- odporne na wszelką krytykę i sugestie. Spotkałem się z sytuacją,
ny jeszcze nie wie, że zadowolony pracownik to dobry pra- gdy dla pewnego menadżera stworzono specjalny odrębny dział,
cownik, być może czas mu to uświadomić. Tylko w taki spo- w nim miał stanowisko z bardzo ważną i ledwo mieszczącą się
sób można naprawić, antywzorzec  marudy . na wizytówce nazwą. W przypadku sprawnie zarządzanych or-
ganizacji, trudne osobowości konfrontuje się ze sobą, np. powie-
Trudni ludzie rzając im prowadzenie wspólnego projektu. W niektórych przy-
Często w projekcie trafiają się osoby, które ogólnie moż- padkach wystarczy szczera rozmowa, w innych odseparowanie
na określić jako trudne. Czy to zwolennik jednej konkret- problemu, którym zajmuje się trudna osoba  tak, aby nie parali-
nej technologii, który podważa sensowność rozwiązań pro- żowała ona prac całego zespołu.
ponowanych przez inne osoby. Może to być osoba egocen- Gdy jednak tego typu metody nie odnoszą skutków, pozo-
tryczna, która w każdym działaniu musi widzieć personalną staje polecić naszą czarną owcę agencji rekrutacyjnej. Pozby-
korzyść. Zdarzają się także programiści introwertycy, któ- cie się z zespołu tego typu osoby, która najczęściej szczęśli-
rzy cierpią po każdym zgłoszeniu błędu do modułu, który wa jest, gdy otwierają się przed nią drzwi do kariery, jest naj-
był ich dziełem. lepszym rozwiązaniem problemu.
Trudne osoby są wszędzie, mogą nimi też być osoby kie-
rujące projektem. Zazwyczaj osoba taka wprowadza niezdro- Wiedza plemienna
wą atmosferę w zespole, doprowadzając do podwyższania Z pewnością znasz projekty, które mimo braku formalnej fazy
i tak już dużego stężenia stresu towarzyszącego projektom in- projektowania odniosły sukces. Stworzenie portalu internetowe-
formatycznym. go w przeciągu tygodnia przez zespół sprawnych programistów,
Każdy zna sytuacje, gdy prowadzenie projektu utrudnia- z wykorzystaniem praktyk XP jest jak najbardziej możliwe. Ktoś
ły nadplanowe inspekcje kodu, nadzorowanie każdej minuty rozszerza tego typu system o moduł integrujący z jednym z
ró-
pracy pracowników. Dostęp do zasobów sieciowych ograni- dłem danych, ktoś inny zapewnia mechanizmy synchronizacji ze
czony do kilku podstawowych stron, zablokowane narzę- starszym, ale wciąż używanym systemem firmy. System się roz-
dzia do komunikacji interpersonalnej (ang. Instant Messa- rasta, początkowo prowadzony mały projekt, wymyka się spod
ging), tego typu ograniczenia swobody pracowników, wpro- kontroli, ale że wszyscy pracują w zgranym zespole, nikt nie wi-
wadzają niekorzystna atmosferę pracy.  Trudni ludzie na dzi potrzeby dokumentowania zmian, czy też tworzenia projek-
stanowiskach kierowniczych najczęściej nie zauważają pro- tu lub choć ogólnej architektury. Pewnego dnia do projektu przy-
blemu dziwiąc się tylko iż zespół staje się coraz mniej efek- chodzi nowa osoba  i okazuje się, iż nie znając zastanych me-
tywny, ma kłopoty z wymianą wiedzy, a z czasem z podsta- chanizmów nie jest w stanie rozpocząć pracy. Nikt, sam przecież
wową komunikacją. obciążony poprawianiem wciąż wychwytywanych błędów, nie
Zachowań tego typu osób nie sposób uniknąć, chcąc bu- ma czasu, aby pomóc świeżemu członkowi zespołu.
dować własną karierę lub promują z uporem narzędzia, które Napotykamy kolejny antywzorzec w zarządzaniu projekta-
poznali w poprzednich projektach, a nie są adekwatne do pro- mi. To co z początku było atrakcyjne, czyli szybkie budowanie
blemu. Wszak nawet prosty system F-K może być polem do rozwiązania informatycznego oraz rozszerzanie jego możliwo-
popisu i można go zrealizować z wykorzystaniem rozproszo- ści bez obciążenia dokumentacją, mści się, gdy należy doko-
nej bazy XML. Z drugiej strony, może natrafiłeś na osobę, któ- nać zmian w systemie, lub wprowadzić do prac nową osobę.
ra odkąd nauczyła się posługiwać narzędziami CASE w celu Trudno jest, bowiem wskazać wszystkie zależności pomiędzy
budowania diagramów ERD, nie może się przełamać i wyko- istniejącymi komponentami nie posługując się przy tym doku-
rzystać możliwości UML a. mentacją architektoniczną...
50
www.sdjournal.org
Software Developer s Journal 5/2006
Antywzorce w zarządzaniu projektami informatycznymi
Wiedza, którą posiadają najczęściej tylko osoby bezpo- dów w komunikacji. Nie ma gorszej sytuacji od tej, gdy jed-
średnio zaangażowane w projekt, musi być przenoszona do na ze stron myśli, iż jest w pełni zrozumiana tylko dlatego,
postaci formalnej. Samo spisanie i udokumentowanie proce- iż widzi nieśmiałe potrząsanie głową (na której widać ozna-
sów zachodzących w aplikacji powoduje najczęściej popra- ki rwania włosów).
wienie kilku do kilkuset błędów. Nie mówiąc już o zaletach
związanych z ułatwionym rozszerzaniem systemu oraz jego Podsumowanie
konserwacją. Powyżej przeprowadzone rozważania nie wyczerpują oczy-
Warto zauważyć, że nowy członek zespołu projektowe- wiście tematu. Problem błędów w zarządzaniu projektami,
go może obawiać się o swój wizerunek i przez długi czas nie wykrycia antywzorców i wskazania prawidłowych rozwią-
przyzna się, że nie rozumie jak system działa. Co więcej oso- zań to niewyczerpany materiał na wiele książek. Punkt wi-
ba, którą oddelegowano do wprowadzenia nowego programi- dzenia uczestnika projektu  programisty, architekta, teste-
sty w zadanie może posługiwać się nieznaną mu terminolo- ra  jest szczególnie ważny. Musimy zdać sobie sprawę z te-
gią lub opisywać wykorzystywanie technologii dotąd niezna- go, że większość ludzi niemal naturalnie wychwytuje działa-
nej programiście? nia błędne i tylko lenistwo, duma, czasem brak asertywno-
Mamy tu do czynienia z kolejnym antywzorcem. Nowy ści powoduje, iż tkwimy w potrzasku. Skutkiem tego pracuje-
członek zespołu nawet, jeśli dotąd programował jedynie my w projekcie, w którym rozpoznajemy Antywzorzec. Stresu-
w C++ wykorzystując bibliotekę Qt do generowania GUI, je to Nas, demotywuje, w efekcie zniechęca do pracy. W nie-
będzie nadzwyczaj często przytakiwał osobie tłumaczą- długim okresie to my możemy stać się powodem powstawa-
cej zaawansowane wykorzystanie Windows.Forms i plat- nia kolejnych problemów, a cały projekt będzie coraz bliżej
formy .NET. klęski niż sukcesu.
Jeśli jesteś w tej sytuacji, powiedz, że czegoś nie rozu- Pamiętając o tym oraz o tych kliku wskazówkach, któ-
miesz. Skorzystasz z wiedzy zespołu, a zespół zyska no- re starałem się przekazać w tym tekście, proszę o odrobi-
wego kolegę  przecież każdy lubi poczuć, iż jego dzieło nę zaangażowania. Nie twierdzę, że zebrane tu uwagi wy-
lub wiedza, są przydatne. czerpują temat. Poruszają go jednak choćby pobieżnie, do-
Nie pozwól, aby wiedza czy to merytorycznie dotyczą- starczając Ci podstawowej wiedzy do identyfikacji antyw-
ca projektu, czy ogólnie dostępna, ale Ci nie znana by- zorców.
ła zamknięta wewnątrz plemienia. Starszyzna projekto- Jeśli więc wiesz, jak możesz poprawić nie tylko swój kod,
wa ma obowiązek podzielić się wiedzą, aby uniknąć błę- ale i otoczenie, czemu tego jeszcze nie zrobiłeś? n
Księgozbiór
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óz
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 A
ą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ądz
, co bądz
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/