plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 2/2008

Extreme Programming i CMMI

– kreatywność czy dyscyplina? (Cz. 3)

ojęcie balansu, czy też balansowania kojarzy
nam się przede wszystkim z próbą utrzyma-
nia równowagi, np. przez linoskoczków w cyr-

ku. Zresztą „balansem” nazywany jest również drąg,
za pomocą którego linoskoczek wspomnianą rów-
nowagę próbuje utrzymać. Niemniej jednak, pojęcie
to, posiada jeszcze głębsze, filozoficzne znaczenie
– poszukiwanie umiaru. „Umiar” stanowi syntezę sta-
rożytnej mądrości greckiej, która swój typowy wyraz
znalazła w pismach wielu poetów, filozofów (Pitago-
ras, Platon, Arystoteles), a która wielokrotnie wska-
zywała na drogę środka, niczego za dużo, słuszną
miarę jako regułę działania moralnego: regułę, któ-
ra była wzorcem helleńskiego sposobu życia, od-
czuwania.

Celem prezentowanego cyklu artykułów, jest pró-

ba wypośrodkowania, pomiędzy dwiema dość skraj-
nymi sposobami tworzenia oprogramowania – agile-
’owym i tradycyjnym. Wypośrodkowanie, nie oznacza
jednak przeciętności, co więcej, jest nawet jej przeci-
wieństwem. „Słuszny środek” znajduje się zdecydowa-
nie ponad skrajnościami i stanowi wręcz ich przezwy-
ciężenie, a więc jest pewnego rodzaju „szczytem”, któ-
ry w wielu wypadkach oznacza zwycięstwo rozumu,
nad tym, co irracjonalne.

Próba sił

Próba znalezienia równowagi pomiędzy światem me-
tod agile’owych a tradycyjnym developmentem nie jest
sprawą łatwą. Wynika to poniekąd z samej natury two-
rzenia software’u, a także z dużej różnorodności me-
tod, rozwijanych w ramach dwóch prezentowanych po-
dejść. W trzeciej, ostatniej części prezentowanego cy-
klu, „zderzone” zostaną ze sobą podstawowe wartości
i założenia metod agile’owych z tymi, które dominują w
świecie tradycyjnych sposobów tworzenia oprogramo-
wania. Praktyki Extreme Programming, zestawione zo-
staną z obszarami procesowymi modelu CMMI. Poka-
zane zostanie to, co łączy i to, co dzieli – świat swo-
bodnego, nieskrępowanego programowania, zaproszo-
ny zostanie do świata dyscypliny i rygoru procesów.
Czy zostanie przyjęty?

Różnica celów

Podstawowym  celem  projektów  agile’owych  jest
„szybkość” oraz „błyskawiczne reagowanie na zmia-
nę”.  Pierwsza  z  12  zasad  Manifestu  Agile  (htttp://
www.agilemanifesto.org),  głosi:  Naszym  najwyższym
celem jest zaspokojenie oczekiwań klienta przez szyb-
kie i ciągłe dostarczanie mu działającego software’u”.
Projekty agile’owe zazwyczaj nie przeprowadzają ana-
lizy ROI (ang. Return on Investment) po to, żeby usta-
lić najbardziej opłacalną alokację zasobów, z punktu
widzenia dostarczanego produktu. Wolą raczej szyb-
ko tworzyć software, określając na bazie doświadcze-
nia z poprzednich iteracji, co tak naprawdę „opłaca”
się (wartość biznesowa) dodać w kolejnej. Przypomi-
na to trochę znaną maksymę: Laissez faire, laissez pas-
ser! – dajcie wolność zarobkowania i handlu, która wy-
rażała podstawową zasadę gospodarki liberalnej, gło-
szącą swobodę gospodarczą jednostek, bez ingerencji
państwa. W przypadku agile’a, taka postawa jest o ty-
le godna polecenia, iż znakomicie minimalizuje wszel-
kie straty, wynikające z tzw. złych inwestycji – realizo-
wanych na podstawie błędnych założeń, analiz. Z dru-
giej jednak strony, brak analizy zysku i strat, przy oka-
zji alokacji zasobów projektowych, może mieć nega-
tywny wpływ na dalszą realizację projektu.

Kolejną cechą charakterystyczną projektów agi-

le’owych jest przyjęcie postawy reaktywnej w trakcie
prac projektowych, co wyraża jedno ze stwierdzeń Ma-
nifestu Agile – „reagowanie na zmianę, ponad trzyma-
niem się planu”. Postawa szybkiej reakcji ma bardzo
dużo zalet, zwłaszcza w dobie, kiedy wymagania ryn-
ku i technologie zmieniają się w zawrotnym tempie. Wy-
obraźmy sobie jednak hipotetyczną sytuację, kiedy tra-
fi nam się tzw. „niezdecydowany klient”, który – tak na-
prawdę – do końca nie wie, jak powinien wyglądać je-
go produkt – wówczas „reaktywne zarządzanie” może
skutkować niepotrzebnym chaosem.

Zupełnie inny jest świat celów, który przyświeca

tradycyjnym metodom tworzenia oprogramowania.
Tam liczy się stabilizacja i przewidywalność istnieją-
cych procesów w organizacji. Szczegółowe plany pro-
jektowe, rozbudowane strategie weryfikacji i walidacji,
dodatkowo wspomagają te cele. Doskonalenie proce-
sów odbywa się w oparciu o różnego rodzaju mode-
le, których znakomitym reprezentantem jest CMMI. Za-
chowanie procesów, analizowane jest za pomocą me-
tod analizy statystycznej, ich przebieg jest szczegóło-
wo śledzony i mierzony. Wszystkie odchylenia od przy-
jętych linii bazowych (ang. baseline) są mierzone i na
bieżąco korygowane, przez co zapewniona jest prze-
widywalność i powtarzalność istniejących procesów w
organizacji.

Mariusz Chrapko

Autor pracuje w Motorola Polska Electronics Sp. z o.o.
(krakowskie Centrum Oprogramowania Motoroli) na sta-
nowisku inżyniera jakości. Od strony zawodowej inte-
resuje się problematyką doskonalenia procesu tworze-
nia oprogramowania w oparciu o model CMMI®, a także
praktykami Agile Software Development. Prywatnie lubi
jazz i filozofię. W wolnych chwilach fotografuje.
Kontakt z autorem: mariusz.chrapko@gmail.com

Extreme Programming i CMMI

www.sdjournal.org

Software Developer’s Journal 2/2008

W odróżnieniu od projektów agile’owych, tradycyjne meto-

dy tworzenia oprogramowania charakteryzuje postawa proak-
tywna. Miary i analizy działań projektowych, pozwalają wycho-
dzić naprzeciw wszelkim potencjalnym niezgodnościom. Jest to
znakomita sytuacja dla bardzo stabilnego środowiska. Nakłady
na działania proaktywne oraz szczegółowe planowanie przed
rozpoczęciem projektu, niewątpliwie sprzyja stabilizacji i prze-
widywalności procesów wytwórczych. Sytuacja jednak kompli-
kuje się, kiedy mamy do czynienia z niestabilnym środowiskiem
projektowym, o wysokim współczynniku nieprzewidywalności i
zmiany. Wówczas próba stabilizacji i utrzymania przewidywalno-
ści może wymuszać dodatkowe koszty.

Rozmiar projektów

Projekty agile’owe znakomicie sprawdzają się w małych i śred-
nich zespołach, pracujących zazwyczaj nad małymi aplikacja-
mi. Wspominał o tym Kent Beck, jeden z twórców metody Extre-
me Programming: „Wielkość projektu nie pozostaje bez znacze-
nia. Najprawdopodobniej nie jest możliwe stosowanie podejścia
XP w projektach liczących stu developerów, nawet pięćdziesię-
ciu, czy czterdziestu. Dwudziestu również dziesięć to wartość
optymalna” (K. Beck, Extreme Programming, Boston: Addison-
Wesley, 1999). Panuje powszechna zgoda, iż wymiana informa-
cji oraz efektywne zarządzanie projektem agile’owym ma sens,
kiedy liczy on nie więcej niż 40 programistów. Oczywiście zda-
rzają się przypadki projektów, liczących nawet do 250 osób. Ta-
kim przykładem może być 250 osobowy projekt prowadzony w
Singapurze, który zajmował się stworzeniem aplikacji bankowej.
Jednak menedżer tego projektu, po jego zakończeniu stwierdził,
iż nie podjąłby się takiego przedsięwzięcia po raz drugi (J. Hi-
ghsmith, Agile Software Development Ecosystems, Boston: Addi-
son-Wesley, 2002). Stosowanie metod agile’owych, w tego typu
projektach, po prostu nie ma sensu. Jednak do dzisiaj najwięk-
szy projekt, który używał metody SCRUM, liczył aż 800 deve-
loperów. Projekt ten prowadziła firma IDX, zajmująca się usłu-
gami z zakresu udzielania informacji medycznej (J. Highsmith,
Agile Software Development Ecosystems, Boston: Addison-We-
sley, 2002).

Doświadczenie pokazuje, iż prowadzenie projektów agile’o-

wych w dużych, bardzo złożonych projektach, ma sens o tyle,
o ile development wspomagany jest elementami tradycyjnych
metod tworzenia oprogramowania, takimi jak: plany projekto-
we, specyfikacja wymagań etc. Wymaga tego poniekąd bar-
dzo złożona, wielowymiarowa rzeczywistość interakcji zacho-
dzących pomiędzy poszczególnymi komponentami prowadzo-
nych przedsięwzięć.

Tradycyjne metody tworzenia oprogramowania doskonale

sprawdzają się właśnie przy okazji realizacji kompleksowych
projektów informatycznych. Szczegółowe plany projektowe, do-
kumentacja, zarządzanie procesami sprzyjają lepszej komunika-
cji i koordynacji prac poszczególnych zespołów. Podstawowym
zagrożeniem takiej postawy jest oczywiście zbytnia biurokraty-
zacja życia, dlatego szczególnie ważny jest tutaj zdrowy rozsą-
dek oraz wspomniana na początku – zasada złotego środka. W
przeciwnym wypadku, może mieć to bardzo negatywne skutki
dla całej organizacji.

Środowisko

Metody agile’owe najlepiej sprawdzają się w bardzo „burzliwym”,
szybko zmieniającym się środowisku projektowym, gdzie wy-

magania „ujawniają” się niejako w trakcie samej realizacji pro-
jektu. Oczywiście ma to swoje dobre strony. Bardzo często ma-
my przecież do czynienia z projektami (zwłaszcza w dużych fir-
mach), które powstają we współpracy z kilkoma zespołami, roz-
mieszczonymi w różnych lokalizacjach na świecie. Wówczas
bardzo często wymagania tworzone są przez oddzielny, spe-
cjalnie dedykowany do tej pracy zespół, zajmujący się tylko i
wyłącznie tą dziedziną. Stąd zdarza się, iż wymagania nie są do-
starczane na czas, co – rzecz zrozumiała – często frustruje ze-
społy developerskie. Wówczas iteracyjne, a co za tym idzie, in-
krementalne dostarczanie wymagań może okazać się świetnym
rozwiązaniem, oczywiście przy właściwym procesie zarządza-
nia zmianą wymagań.

Metody typu „plan-driven” (wiedzione planem) z kolei naj-

lepiej sprawdzają się w sytuacjach, gdy proces zbierania i
analizy wymagań zamyka się przed oficjalnym rozpoczęciem
prac nad designem systemu. Stąd też w tym przypadku wszel-
ki brak stabilności wymagań wpływa negatywnie na cały póź-
niejszy development. Statystycznie rzecz biorąc, metody plan-
driven, dopuszczają zmiany wymagań w granicach 1% w ska-
li miesiąca. W przeciwnym wypadku firma zmuszona jest pła-
cić niezwykle duże koszty, wynikające z konieczności utrzy-
mania, wcześniej zdefiniowanych, procesów związanych z za-
pewnieniem jakości i spójności zbieranych wymagań, a także
ich testowalnością.

Relacje z klientem

Agile Software Development kładzie duży nacisk na bliską
współpracę z klientem. Klient jest wręcz równoprawnym człon-
kiem zespołu projektowego. W praktyce, perspektywa klienta,
reprezentowana jest przez różnego rodzaju analityków bizne-
sowych, którzy posiadają bardzo dobrą znajomość wymagań
końcowych użytkowników systemu. Można powiedzieć, iż sta-
nowią pewnego rodzaju medium pomiędzy zespołem develo-
perów, a klientem końcowym. Dlatego sukces projektów agi-
le’owych zależy w dużym stopniu od charakteru tej współpra-
cy – na ile przedstawiciel klienta będzie w stanie odzwiercie-
dlić jego rzeczywiste potrzeby. Zawsze przecież może gdzieś
wkraść się błąd, dwuznaczność, niezrozumienie. Dlatego też,
sukces tych projektów, w dużym stopniu zależy od właści-
wych relacji z klientem.

Trochę inaczej sytuacja wygląda w przypadku tradycyj-

nych metod tworzenia oprogramowania. Tutaj, punkt nacisku
położony jest na właściwe sformułowanie kontraktu, pomiędzy
klientem i developerami/firmą. Na tym właściwie kończy się ta
współpraca (oczywiście, wykluczają sytuacje nadzwyczajne).
Metody plan-driven niezwykle pieczołowicie konstruują umo-
wy z klientem. Muszą zaangażować wszelkie zdolności „wizjo-
nerskie”, żeby niejako na papierze przewidzieć wszelkie poten-
cjalne problemy oraz ich możliwe rozwiązania, zanim faktycznie
wystąpią w trakcie realizacji projektu. Ponieważ klient nie jest
członkiem zespołu projektowego i nie może zmieniać wymagań
w trakcie realizacji projektu, kontrakt powinien zawierać tak du-
żo szczegółów, jak to tylko możliwe. Pozytywną stroną tego po-
dejścia jest fakt, iż developerzy przez cały okres trwania pro-
jektu dokładnie wiedzą, co mają robić; także klient wie, czego
może się spodziewać po zakończeniu projektu. Z drugiej jed-
nak strony, prace nad precyzyjnym sporządzeniem kontraktu,
chęć uwzględnienia wszystkich niezbędnych detali, mogą po-
wodować niepotrzebne opóźnienia na samym starcie; co wię-

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 2/2008

cej, zmiany w trakcie realizacji przedsięwzięcia, czynią wręcz
niemożliwymi.

Podstawa budowania zaufania w relacjach z klientem, w

obu podejściach, oparta jest na różnych zasadach. W projek-
tach agile’owych, zaufanie budowane jest w oparciu o dostar-
czanie klientowi fragmentów działającego software’u. Co ja-
kiś czas klient dostaje mały fragment swojego produktu, testu-
je go – widzi, że developerzy faktycznie pracują. W przypadku
tradycyjnych metod, zaufanie budowane jest w oparciu o doj-
rzałość procesów wytwórczych danej organizacji. Z kolei, bar-
dzo często gwarantem dojrzałości procesów jest legitymowa-
nie się przez firmę implementacją określonych celów i praktyk,
obecnych w modelach dojrzałości procesów, takich jak CMMI.
Klient decyduje się na podpisanie kontraktu z firmą, której pro-
cesy znajdują się na określonym poziomie dojrzałości, bo wie,
że stanowi to określoną, solidną podstawę budowania zaufa-
nia. Podejście to niesie ze sobą jednak duże pokłady ryzyka.
Zaufanie oparte na certyfikatach i ludziach, posiada zawsze
wiele ograniczeń.

Planowanie i kontrola

Cytowany już Kent Beck, powiedział kiedyś, że metodę XP
można scharakteryzować jako „planning-driven”, co należa-
łoby przetłumaczyć jako „wiedzioną planowaniem”. Planowa-
nie w projektach agile’owych zajmuje około 20% ich czasu i
jest wynikiem zaangażowania się całego zespołu oraz dziele-
nia się tzw. „wiedzą ukrytą (ang. tacit knowledge). Jest to wie-
dza, z której istnienia wprawdzie zdajemy sobie sprawę i któ-
rą wykorzystujemy w codziennym działaniu, ale nie potrafimy
jej do końca określić, a przez to wszelkie próby jej sformali-
zowania są niezwykle trudne. Więcej szczegółów na ten temat
można znaleźć w książce autora pojęcia „wiedzy ukrytej” Mi-
chaela Polanyi, The Tacit Dimension, Routledge & Kegan Paul
Ltd, London 1967.

Wiedza ukryta, jest tym rodzajem wiedzy, który doskona-

le sprawdza się w małych zespołach agile’owych, które bar-
dzo efektywnie mogą dzielić się tym rodzajem wiedzy, która nie
jest przecież wiedzą udokumentowaną. Niestety, wraz ze wzro-
stem organizacji ten sposób przekazywania wiedzy staje się co-
raz bardziej nieefektywny. Dlatego metody plan-driven tak duży
nacisk kładą na dokumentowanie planów projektowych, w du-
żej mierze, w celu usprawnienia komunikacji projektowej. Trady-
cyjne metody tworzenia oprogramowania mają ściśle zdefinio-
wany proces planowania prac projektowych (tworzenie harmo-
nogramu, określenie punktów milowych, szacowanie wielkości
prac, kosztów etc.) oraz prac związanych z rozwijanym produk-
tem (wymagania, opis architektury systemu, design, implemen-
tacja, testy). Poszczególne plany, których przygotowanie zwią-
zane jest z konkretną fazą prac projektowych – łączą się, two-
rząc integralną całość.

Komunikacja w projekcie

Komunikacja w projektach agile’owych w dużej mierze opar-
ta jest na dzieleniu się, wspomnianą wcześniej, wiedzą „ukry-
tą”. Wiedza ta, rozwijana jest w takich praktykach agile’owych
jak: zabawa w planowanie (ang. planning game), programowa-
nie w parach, czy retrospekcje. Wiedza ukryta odsłania się w
codziennej pracy projektowej. Programiści, pracując nad kon-
kretnymi zadaniami, w ramach konkretnej iteracji, wymienia-
ją swoje doświadczenia, wzajemnie obdarowywują się swo-

ją wiedzą, która nie wymaga złożonej dokumentacji. Niemniej
jednak, pokładanie całego zaufania firmy w założenie, iż wie-
dza ukryta jest konsystentna we wszystkich zespołach pro-
jektowych – należy traktować jako wysoce ryzykowne. Ryzy-
ko zwiększa się jeszcze bardziej, gdy mamy do czynienia z du-
żą rotacją w tych zespołach, co jest przecież rzeczą dość czę-
stą w organizacjach.

Im większa organizacja, tym sposób przekazywania wie-

dzy ukrytej staje się coraz bardziej nieefektywny. Należy tu-
taj rozważyć, jak bardzo zwiększa się liczba relacji zależno-
ści pomiędzy poszczególnymi pracownikami. Dlatego meto-
dy plan-driven, tak wielką wagę przykładają do wiedzy „jaw-
nej”, formalnej – a więc jasno sprecyzowanej i usystematyzo-
wanej, którą można udokumentować. Jednak i tutaj pojawiają
się przeszkody. Informacje znajdują się w wielu miejscach i w
różnych formach, nie zawsze jest też oczywiste, gdzie daną in-
formację można znaleźć.

Należy jednak pamiętać, iż ścisły rozdział wiedzy „jawnej”

od „ukrytej”, w żadnym z omawianych podejść, nie ma charakte-
ru absolutnego. Kod źródłowy czy przypadki testowe, które po-
wstają w projektach agile’wych jak najbardziej kwalifikują się do
uznania ich jako wiedzę „jawną”. Podobnie, w przypadku metod
plan-driven, komunikacja interpersonalna, indywidualna wymia-
ny doświadczeń – wspierają rozumienie dokumentacji proceso-
wej. Metody agile’owe dokumentują niezbędne minimum (user
stories, plan projektu).

Tradycyjne metody tworzenia oprogramowania cierpią z

kolei bardzo często na syndrom, nazwijmy to „niepewnego de-
velopera”. Oto bowiem, z jednej strony, dość duży nacisk kła-
dą na szczegółową dokumentację wszystkich procesów, za-
chodzących na poziomie organizacji i poszczególnych pro-
jektów, z drugiej zaś – dają ludziom bardzo cenne narzędzie
w postaci „tailoringu” – a więc przykrywania istniejących pro-
cesów do zindywidualizowanych potrzeb konkretnego projek-
tu. Narzędzie to świetnie wykorzystywane jest przez tzw. „de-
veloperów ekspertów”, których wiedza i doświadczenie są na
tyle duże, iż bez problemu potrafią dopasować istniejący gor-
set wymagań procesowych, do własnych potrzeb, które skądi-
nąd zawsze posiadają rozsądne uzasadnienie biznesowe. Nie-
stety, w wielu projektach, bardzo często, zwłaszcza wśród me-
nedżerów, pojawiają się osoby, które mimo swoich ogromnych
kompetencji oraz ogromnego doświadczenia/ekspertyzy, wo-
lą spełnić wymagania wszystkich istniejących procesów w or-
ganizacji, po to tylko, ażeby się za nimi schować, przyjmując
w ten sposób postawę asekuracyjną na wypadek, gdyby pro-
jekt zakończył się niepowodzeniem. Takie podejście, skutkuje
najczęściej ogromną frustracją ze strony pozostałych człon-
ków zespołu projektowego i mnożeniem ton nikomu niepo-
trzebnej dokumentacji.

Wymagania, design i testy

Wśród dyskusji na temat różnic pomiędzy agilem, a tradycyj-
nymi metodami tworzenia software’u, najczęściej wskazuje się
na aspekty techniczne. Po pierwsze – sposób zbierania wyma-
gań. Jak już zostało wcześniej powiedziane, w projektach agile-
’owych sposób zbierania i tworzenia wymagań ma charakter bar-
dzo nieformalny. Słowem-kluczem jest tutaj pojęcie „kart klien-
ta” (ang. user stories), a więc bardzo lakonicznych opisów po-
szczególnych funkcjonalności systemu (najczęściej zapisanych
na małych karteczkach), powstałych w wyniku współpracy klient

Extreme Programming i CMMI

www.sdjournal.org

Software Developer’s Journal 2/2008

– developer. To, które wymagania zostanie zaimplementowane
w każdej kolejnej iteracji, w dużej mierze decyduje klient. Deve-
loperzy określają jedynie, na ile dana karta może zostać zaim-
plementowana. Zawsze jednak, jest to przedmiotem negocjacji,
w które każdorazowo zaangażowane są obie strony: kliencka i
developerska.

Świat tradycyjnych metod tworzenia oprogramowania, pod

względem zbierania i dostarczania wymagań, funkcjonuje zu-
pełnie inaczej. Tutaj wszystko ma charakter wysoce sformalizo-
wany. Wymagania są wersjonowane, a ich zmiany skrupulatnie
śledzone. Służą temu różnego rodzaju narzędzia, które pozwa-
lają należycie nimi zarządzać, przez cały czas trwania projek-
tu. Wspomnę tutaj chociażby o takich komercyjnych systemach
jak RequisitePro firmy Rational, CaliberRM firmy TBI, czy DO-
ORS firmy Telelogic.

Mówiąc o różnicach technicznych, warto również wspomnieć

o kwestiach związanych z tworzeniem designu systemu. Świat
metod agile’owych zaleca maksymalną prostotę – pojawia się
praktyka określana mianem simple design, która zaleca budo-
wanie systemu możliwie jak najmniej skomplikowanego, co zna-
komicie oddaje powiedzenie, określane w skrócie „YAGNI” (You
aren’t going need it) – developerzy powinni implementować tylko
to, co wyrażają aktualne potrzeby klienta, nie zaś to, co ich zda-
niem, może być klientowi potrzebne. Oczywiście przekłada się
to na tworzenie designu systemu. Przemawiają za tym dwa argu-
menty. Pierwszy, zakłada mniejszy koszt związany z reworkiem
wszelkich zmian w trakcie trwania developmentu (ciągła refak-
toryzacja wymagań, kodu, przypadków testowych). Drugim ar-
gumentem, przemawiającym za stosowaniem tej praktyki, jest
tempo prac developerskich zorientowanych wokół poszczegól-
nych iteracji. Nasz system zmienia się tak szybko, że jakiekol-
wiek próby „przygotowania” go do przyjęcia w przyszłości in-
nych funkcjonalności mogłoby okazać się zabójcze dla całego
przedsięwzięcia.

Zupełnie inaczej sytuacja wygląda w metodach plan-dri-

ven. Pomijając fakt, iż fazy architektury i designu są szczegóło-
wo dokumentowane, to jednak chyba najważniejszą rzeczą, jest
ogromny wysiłek, wkładany w to, aby system był przygotowany
do przyjęcia wszelkich możliwych zmian w przyszłości. Dobrym
przykładem jest tutaj firma Hewlett-Packard, która na skutek mo-
dułów software’owych, nadających się do powtórnego użycia,
była w stanie skrócić czas trwania developmentu z 48 miesię-
cy do 12, w ciągu 5 lat. Więcej szczegółów na ten temat można
znaleźć w raporcie technicznym laboratorium HP – Malan R., K.
Wentzel, kwiecień 1993, Economics of Reuse Revisited, HP Labs
Technical Report HPL-93-31).

Jeśli chodzi o podejście do kwestii testowania, obie metody

również reprezentują odmienne stanowiska. W tradycyjnych po-
dejściach, związanych najczęściej z kaskadowym cyklem życia
projektu, faza testowania następuje po fazie implementacji, co
powoduje, iż ewentualne defekty w kodzie, wykrywane są sto-
sunkowo późno. Świat metod agile’owych adresuje ten problem
stosując praktykę tzw. „programowania sterowanego testami”
(ang. test driven development), która polega na tym, że najpierw
piszemy test, a potem kod, który ten test spełnia. Ma to wiele
zalet, między innymi, znacząco zwiększa stopień pokrycia kodu
(ang. test coverage) oraz sprawia, iż powstające moduły są sto-
sunkowo mało skomplikowane (piszemy kod, który jest niezbęd-
ny do osiągnięcia danej funkcjonalności), a także umożliwia peł-
ną automatyzację testów.

Metody plan-driven zapobiegają późnemu znajdowaniu błę-

dów w kodzie, poprzez jego ciągłe inspektowanie. Jest to prak-
tyka, mająca na celu wykrycie jak największej ilości błędów, a
także ich naprawę, jeszcze w trakcie fazy kodowania. Polega na
przeglądzie kodu przez niewielkie grupy programistów (zwykle
4-5 osób) zanim kod zostanie objęty kontrolą wersji i przetesto-
wany. W tradycyjnych metodach tworzenia oprogramowania, in-
spekcje zazwyczaj są stosowane w odniesieniu do wszystkich
artefaktów projektowych, takich jak: wymagania, design, plany/
strategie testowania, przypadki testowe, a także do dokumen-
tów procesowych. Pełnią rolę tzw. „bram jakości” (ang. quali-
ty gates). Projekt nie może opuścić jednej fazy i przejść do na-
stępnej, bez uprzedniego przeinspektowania wszystkich jej ar-
tefaktów. A więc, nie możemy opuścić fazy designu i przejść
do fazy kodowania, bez uprzedniego przeglądu projektu nasze-
go systemu. Podobnie w przypadku fazy kodowania – nie mo-
żemy rozpocząć testów, bez uprzednich przeglądów kodu. Ta-
kie podejście umożliwia bardzo wczesne wychwytywanie błę-
dów w procesie developmentu software’u. Więcej na temat pro-
cesu inspekcji w artykule: M. Chrapko, Inspekcje kodu jako sku-
teczna metoda weryfikacji kodu, Software Developer’s Journal,
nr 3/2007 (147).

Czynnik ludzki

Dotykamy obszaru, który jest bodajże najbardziej newralgiczny
z punktu widzenia tematu niniejszej publikacji. „Lekkie” metody-
ki, o czym była mowa wcześniej, stosunkowo duży nacisk kładą
na ciągłą obecność i aktywne zaangażowanie klienta, bądź je-
go reprezentanta (analityk biznesowy), w prace zespołu projek-
towego. Owo zaangażowanie sprawia, iż z jednej strony uczest-
niczy on w planowaniu i priorytetyzowaniu prac projektowych,
przygotowuje testy akceptacyjne, opowiada na wszystkie pyta-
nia programistów, związane z tworzonym produktem – z dru-
giej zaś, bardzo często zdarza się, że firmy oddelegowują tzw.
„zbędnych” pracowników do pracy właśnie w projektach agile-
’owych, nie mając przy tym świadomości, jak bardzo duże nie-
sie to ryzyko.

Rysunek 1.

Znaczenie czynnika ludzkiego w metodach agile i

plan-driven. Źródło: J. Highsmith, Agile Software Development
Ecosystems, Boston: Addison-Wesley, 2002

��

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 2/2008

Metody plan-driven angażują klienta jedynie na początku prac
projektowych – w momencie zbierania i definiowania wymagań
oraz w momencie przygotowywania i zawierania kontraktu. Jed-
nak, w odróżnieniu od metod agile’owych, nie jest to obecność
permanentna.
Obie metody wymagają jednak zaangażowania, właściwych i
kompetentnych osób. W projektach agile’owych, oprócz okre-
ślonych umiejętności technicznych, niezbędne są pewne pre-
dyspozycje „miękkie”, a więc zdolność do komunikacji, pracy
w grupie, twórczego rozwiązywania problemów, co wynika ze
specyfiki obecnych w nich praktyk. Nie sposób programować
w parach, nie posiadając zdolności pracy w grupie czy komu-
nikacji. Oczywiście w tradycyjnych metodach tworzenia opro-
gramowania cechy te są równie ważne, jednak nie krytyczne. W
tradycyjnych metodykach, powodzenie projektów nie zależy od
posiadania określonych cech interpersonalnych developerów.
Dobrze zdefiniowany i zarządzany proces, jego powtarzalność
i przewidywalność są gwarantem sukcesu projektów. Oczywi-
ście nie jest też tak, iż w projektach tych pracują roboty, które
w cieniu swoich kubików, w odizolowaniu od świata, tworzą ma-
łe fragmenty kodu.

Kultura organizacji

Dotykamy tutaj elementu, którego rola jest krytyczna w poszu-
kiwaniu równowagi pomiędzy omawianymi podejściami. Kultura
projektów agile’owych opiera się na wolności – swobodzie w de-
finiowaniu i organizacji pracy. Jest to kultura swobodnego, nie-
skrępowanego działania. W projektach agile’owych każda oso-
ba dokładnie wie, co należy do jej obowiązków.

W tradycyjnych metodach, programiści czują się najlepiej,

kiedy ich role i zakres obowiązków zostały jasno i czytelnie zde-
finiowane (polityki, procesy, procedury). W ten sposób, każdy
dokładnie wie, jakie są względem niego oczekiwania oraz za wy-
tworzenie, jakiego fragmentu produktu jest on odpowiedzialny.
Kultura organizacji jest tym elementem, który najbardziej opie-
ra się wprowadzaniu zmian. Oczywiście nie są one wykluczone,
niemniej jednak wymagają dużo cierpliwości i czasu.

XP i CMMI

Metoda XP oraz Model CMMI to pozornie dwa różne światy, któ-
rym przyświeca wspólny cel – produkcja dobrego oprogramo-
wania, spełniającego wymagania stawiane przez klienta. Model
CMMI jest doskonałym narzędziem oceny i doskonalenia proce-
sów wytwórczych w organizacji. Składa się z 22 obszarów pro-
cesowych (ang. Proces Areas), które tworzą dobre praktyki z
zakresu inżynierii oprogramowania. Należy pamiętać, iż model
CMMI nie jest w żadnym wypadku tworem intelektualnym, stwo-
rzonym przez środowisko akademickie, choć oczywiście posia-
da ono niezaprzeczalny wkład w jego rozwijanie. Jest to jednak
model, o którego powstaniu zadecydowała przede wszystkim
praktyka – Departament Obrony Stanów Zjednoczonych (ang.
United States Department of Defense) chciał mieć narzędzie do
oceny swoich kontraktorów, chciał współpracować z firmami,
którym można zaufać. Dlatego powstał model, posiadający po-
dwójne zastosowanie, z jednej strony stanowi on doskonałe na-
rzędzie oceny poziomu dojrzałości procesów wytwórczych da-
nej organizacji, z drugiej zaś, definiuje ścieżkę ich rozwoju/do-
skonalenia, gdyby tego wymagały. Model w obecnej postaci (od
momentu powstania w 1987 roku pojawiło się kilka jego wer-
sji) składa się z dwóch reprezentacji: stałej (ang. staged) oraz

ciągłej (ang. continuous). Przypominają one trochę dwa odręb-
ne widoki (ang. view) w bazie danych, są czymś w rodzaju wir-
tualnej tabeli. Pozwalają firmie na 22 obszary procesowe spo-
glądać z dwóch odmiennych perspektyw/reprezentacji. Z jed-
nej strony, akcentują tylko te procesy wytwórcze, które wyma-
gają poprawy i dostarczają niezbędnych środków do ich rozwo-
ju (reprezentacja ciągła); z drugiej zaś, umożliwiają organiza-
cję, stopniowe, krok po kroku, doskonalenie procesów, dostar-
czając jej gotowej, kilku stopniowej ścieżki rozwoju (reprezen-
tacja stała). Takie podejście, umożliwia pracę nad poprawą pro-
cesów wytwórczych, zarówno tym organizacjom, które posia-
dają dobrą znajomość swoich procesów, jak i firmom, które do-
piero zaczynają swoją przygodę z ich poprawą, startując bar-
dzo często od zera.

Model CMMI pełni więc rolę swoistego drogowskazu na

drodze doskonalenia procesów tworzenia oprogramowania w
organizacji – mówi „co robić” (praktyki i cele), aby jej proces
był faktycznie dojrzały. Metoda XP natomiast, stanowi kon-
kretną propozycją implementacji niektórych praktyk, obec-
nych w modelu CMMI. Tutaj odsłania się możliwość synergii
omawianych podejść. Kiedy zestawimy praktyki Extreme Pro-
gramming z obszarami procesowymi modelu CMMI, nie od-
kryjemy sprzeczności – w niektórych przypadkach możemy
mówić co najwyżej o sytuacji, kiedy pewne obszary proceso-
we pozostają neutralne względem praktyk Extreme Program-
ming (ich ewentualna implementacja na gruncie XP nie stano-
wiłaby więc sprzeczności); bądź skrajnie możliwe (prawdopo-
dobieństwo ich wprowadzenie jest bardzo niskie, choć oczy-
wiście nie wykluczone). Można, więc całkiem zasadnie stwier-
dzić, iż relacja zakresu obszarów procesowych modelu CMMI
względem konkretnych praktyk metody XP jest relacją – zbio-
ru względem jego podzbioru. Wszystkie praktyki Extreme Pro-
gramming stanowią „ucieleśnienie” większości praktyk obec-
nych w modelu CMMI.

Dla potrzeb tej publikacji, praktyki metody XP zostaną ze-

stawione z obszarami procesowymi modelu CMMI w czterech
kategoriach reprezentacji ciągłej: Zarządzanie projektem (ang.
Project Management), Inżynieria (ang. Engineering), Wsparcie
(ang. Support) oraz Zarządzanie procesem (ang. Process Ma-
nagement).

Rysunek 2.

Reprezentacja modelu CMMI. Reprezentacja stała

��

�

��

�

��

�

��

�

��

�

��

Extreme Programming i CMMI

www.sdjournal.org

Software Developer’s Journal 2/2008

Zarządzanie projektem

W obszarach procesowych CMMI, należących do tej katego-
rii, znalazły się:

• planowanie projektu (ang. Project Planning) – szacowanie

projektu (wielkość, koszty, czasu trwania); definiowaniu je-
go cyklu życia (kaskadowy, spiralny, przyrostowy etc.); two-
rzenia dokumentacji projektowej; sporządzanie planu;

• monitoring i kontrola (ang. Project Monitoring and Control)

– monitorowanie prac projektowych pod kątem zgodności
z przyjętym planem (śledzenie harmonogramu, wydatków,
dostępności zasobów, ryzyk); zarządzanie procesem defi-
niowania i rozwiązywania akcji korekcyjnych, powstałych na
skutek odchyleń od przyjętego planu;

• zarządzanie dostawcami (ang. Supplier Agreement Mana-

gement) – określenie jakiego typu produkty i usługi, zwią-
zane z realizacją danego projektu, będą realizowane przez
zewnętrznych bądź wewnętrznych dostawców; definiowa-
nie kryteriów wyboru dostawców; sporządzanie umów z do-
stawcami; ewaluacja dostarczanych produktów, zwłaszcza
tych, które mają znaczenie krytyczne dla powodzenia reali-
zowanego projektu; organizowanie procesu tranzycji dostar-
czanego produktu/usługi (szkolenia, konsultacje, support);

• zintegrowane zarządzanie projektem (ang. Integrated Project

Management) – zdefiniowanie procesów, które będą wyko-
rzystywane w trakcie realizacji projektu, w zależności od je-
go specyfiki, cyklu życia (np. proces estymowania, zarzą-
dzania ryzykiem, inspekcji/przeglądów, testowania etc.); pla-
nowanie projektu w oparciu o wcześniej zdefiniowane pro-
cesy; przygotowanie środowiska projektowego (narzędzia,
sprzęt, manuale, support – wszystko, co jest niezbędne do
efektywnie wykonywanej pracy w ramach projektu); integra-
cja planu projektowego z wszystkimi innymi planami, które
bezpośrednio go dotyczą (plany zapewnienia jakości, zarzą-
dzania konfiguracją, ryzykiem);

• zarządzanie ryzykiem (ang. Risk Management) – analiza i

ocena ryzyka w projekcie; identyfikacja możliwych źródeł
ryzyka; szacowanie prawdopodobieństwa jego wystąpie-
nia oraz wpływu na projekt; definiowanie poziomów ryzy-
ka; przygotowywanie planu działań zapobiegawczych;

• ilościowe zarządzanie projektem (ang. Quantitative Project

Management) – definiowanie mierzalnych celów projektu
(np. pożądany poziom kosztów jakości, kosztów złej jakości,
gęstości błędów, produktywności etc.); zbieżnych z celami
ogólno-organizacyjnymi; dokumentowanie przyjętych celów
w planach projektowych; monitorowania stopnia realizacji
założonych celów; zbieranie miar projektowych; definiowa-
nie akcji korekcyjnych w przypadkach odchyleń od przyję-
tych celów; stosowanie metod statystycznej analizy proce-
sów do śledzenia ich zachowań.

Metoda XP w pełni realizuje wymagania związane z kategorią
„Planowania projektu”. Praktyki związane z „zabawą w planowa-
nie” (ang. planning game); „krótkimi wydaniami” (ang. short rele-
ases), przekładające się na planowanie poszczególnych wydań
oraz iteracji; estymowanie wielkości projektu poprzez szacowa-
nie pracy związanej z implementacją poszczególnych kart klien-
ta (ang. user stories) – stanowią urzeczywistnienie zaleceń mode-
lu CMMI w tym zakresie. Kolejny obszar – „Monitoring i kontrola”,
jest również doskonale spełniony w metodzie XP m.in. poprzez

śledzenie tzw. „prędkości” (ang. velocity) projektu – określającej,
jak wiele kart klienta udało się zespołowi zaimplementować w ra-
mach danej iteracji. Metryka ta jest dość precyzyjnie śledzona w
metodzie Extreme Programming. Szacowana prędkość projektu,
porównywana jest z wartościami rzeczywistymi; analizowany jest
całkowity wysiłek zespołu względem danej iteracji (ang. cumula-
tive story point chart), a także ile pracy pozostało do wykonania
pod koniec trwania danej iteracji (ang. iteration burndown chart).
Również obszar „Zintegrowanego zarządzania projektem” znaj-
duje swoje odzwierciedlenie w praktykach agile’owych. XP po-
siada ściśle zdefiniowany iteracyjny cykl życia oprogramowania
– estymaty oraz plany poszczególnych wydań i iteracji, wykorzy-
stywane są do planowania kolejnych aktywności projektowych;
wraz z planowaniem projektu, tworzone jest odpowiednie środo-
wisko pracy (narzędzia, krytyczne zasoby); definiowane są pod-
stawowe metryki (np. velocity) oraz sposób, w jaki będą mierzone
i przechowywane. W procesie planowania poszczególnych itera-
cji, metody agile’owe stosują podejście określane mianem risk-dri-
ven iterative development. Oznacza to, iż przy planowaniu począt-
kowych iteracji brane są pod uwagę przede wszystkim te elemen-
ty systemu, które odznaczają się dużym poziomem ryzyka wzglę-
dem pozostałych. Mimo, że Extreme Programming nie posługuje
się zaawansowanym planem zarządzania ryzykiem, niemniej jed-
nak, risk-driven iterative development stanowi pewną jego namiast-
kę. Jeśli chodzi obszar „Zarządzania dostawcami”, metoda XP po-
zostaje względem niego raczej neutralna. Natomiast, w przypadku
„Ilościowego zarządzania procesem”, implementacja obecnych w
tym obszarze praktyk, można uznać za skrajnie możliwą.

Inżynieria

Drugi zbiór obszarów procesowych modelu CMMI, zebranych
wokół kategorii: „Inżynierii”, również posiada wiele punktów
wspólnych z metodą XP. Znalazły się tutaj:

• zarządzanie wymaganiami (ang. Requirements Management)

– osiąganie wspólnego zrozumienia definiowanych wymagań
(klient – projekt); zarządzanie zmianami wymagań; śledze-
nie poziomu ich implementacji oraz pokrycia testami; iden-
tyfikowanie wszelkich rozbieżności pomiędzy pracą projek-
tu, a przyjętymi wymaganiami;

• rozwój wymagań (ang. Requirements Development) – zbie-

ranie wymagań od klienta; definiowanie wymagań produktu;
analiza i walidacja wymagań;

�

��

Rysunek 3.

Reprezentacja modelu CMMI. Reprezentacja ciągła

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 2/2008

• rozwiązania techniczne (ang. Technical Solution) – ewaluacja

i wybór odpowiedniego projektu systemu (w oparciu o jego
wymagania); sporządzenie szczegółowego design’u systemu
(opis architektury, projekt systemu); implementacja przyję-
tych rozwiązań;

• integracja produktu (ang. Product Integration) – integracja

komponentów produktu w integralną całość; przygotowanie
środowiska integracyjnego; definiowanie procedur integra-
cyjnych (dokumentacja, kryteria); dostarczenie produktu;

• weryfikacja (ang. Verification) – sprawdzenie produktu, pod

kątem jego zgodności z przyjętą specyfikacją; wybór pro-
duktów roboczych, które zostaną poddane procesowi we-
ryfikacji; przygotowanie środowiska umożliwiającego wery-
fikację; metody weryfikacji: inspekcje/przeglądy artefaktów
projektowych, testy; stworzenie procedur i kryteriów wery-
fikacyjnych (dokumentacja); ewaluacja uzyskanych rezulta-
tów (raporty);

• walidacja (ang. Validation) – sprawdzenie, czy to, co zostało

zdefiniowane w wymaganiach, jest zgodne z oczekiwaniami
użytkownika; przeprowadzanie testów w środowisku rzeczy-
wistym naszego klienta, bądź zbliżonym do niego; przygoto-
wanie środowiska umożliwiającego walidację (np. symulatory,
wykwalifikowani pracownicy, odpowiednie środowisko testo-
we, narzędzia); stworzenie procedur i kryteriów walidacyjnych
(dokumentacja); ewaluacja uzyskanych rezultatów (raporty).

Dwa pierwsze obszary procesowe, dotyczące zarządzania wy-
maganiami, metoda XP odzwierciedla poprzez posługiwanie się
kartami klienta w definiowaniu i zarządzaniu wymaganiami oraz
jego aktywne zaangażowanie w trakcie całego developmen-
tu. Klient jest obecny na każdym etapie cyklu życia projektu.
Uczestniczy w jego planowaniu, dokonuje priorytetyzacji funk-
cjonalności, a także odpowiada na wszystkie pytania programi-
stów. Obszar „Rozwiązania techniczne” modelu CMMI jest po-
wiązany z praktyką metafory w obrazowaniu działania systemu
(odpowiednik architektury), zasadą maksymalnej prostoty w de-
finiowaniu projektu systemu (ang. simple design), a także prak-
tyką refaktoryzacji kodu. Integracja produktu, wspierana jest
przez praktykę ciągłej integracji (ang. continuous integration),
obecną w podejściu XP. Komponenty systemu, integrowane są
z dużą częstotliwością, nawet do kilku razy dziennie. W meto-
dzie XP, szczególnie mocno reprezentowane są dwa ostatnie ob-
szary z omawianej grupy: „Walidacja” oraz „Weryfikacja”. Wyko-
nywanie testów jednostkowych, akceptacyjnych, regresyjnych,
wspomaganych przez automatyzację procesu testowania, sta-
nowią „twardy rdzeń” tej metody. Obszary te, dodatkowo wspie-
rane są przez praktykę programowania w parach (ang. pair pro-
gramming), która w niektórych przypadkach wydaje się być du-
żo silniejszym narzędziem, aniżeli inspekcje kodu – ze względu
na jej duży ładunek prewencyjny: wspólne programowanie zapo-
biega wprowadzaniu błędów do powstającego kodu, które nor-
malnie wykrywane są podczas inspekcji.

Wsparcie

Kolejny zbiór procesów, skupiony jest wokół kategorii: „Wspar-
cia”. Znajdują się tutaj:

• zarządzanie konfiguracją (ang. Configuration Management)

– identyfikacja produktów poddanych kontroli wersji; usta-
nowienie systemu zarządzania konfiguracją (procedury, na-

rzędzia); definiowanie baseline’ów; śledzenie tzw. „żądań
zmian” (ang. change request) – sugestii modyfikacji produk-
tu roboczego, bądź zgłoszenia wykrytych w nim defektów;
przyprowadzanie audytów konfiguracji;

• zapewnienie jakości procesu i produktu (ang. Process and

Product Quality Assurance) – obiektywna ewaluacja pro-
cesów w organizacji (raporty); przeprowadzanie audytów
projektowych/organizacyjnych; identyfikowanie i dokumen-
towanie niezgodności/odstępstw od zdefiniowanych pro-
cesów w firmie; dostarczanie informacji zwrotnej członkom
zespołu projektowego oraz menedżerom; właściwe adreso-
wanie niezgodności audytowych oraz akcji korekcyjnych;

• miary i analizy (ang. Measurement and Analysis) – definio-

wanie metryk projektowych/organizacyjnych; sporządzenie
procedur, określających jak zbierać metryki projektowe; wy-
korzystywanie narzędzi do zbierania metryk; analiza uzyska-
nych rezultatów; podejmowanie działań korekcyjnych;

• analiza decyzyjna (ang. Decision Analysis and Resolution) –

zdefiniowanie kryteriów stosowania procesu analizy decy-
zyjnej w organizacji; przygotowanie odpowiednich procedur
(dokumentacja); wybór metod ewaluacji możliwych rozwią-
zań; ocena ryzyka wybranych rozwiązań;

• analiza przyczyn i działania prewencyjne (ang. Causal Ana-

lysis and Resolution) – identyfikacja przyczyn wykrytych de-
fektów oraz wszelkich innych problemów, pojawiających się
w trakcie życia projektu; podejmowanie akcji prewencyj-
nych; weryfikacja poprawnego wykonania akcji.

W tej kategorii o komplementarności można mówić jedynie w
przypadku obszaru związanego z zarządzaniem konfiguracją
oprogramowania. W metodzie XP kontrola zmian produktów
roboczych dokonuje się za sprawą praktyki kolektywnej wła-
sności kodu (ang. collective ownership), krótkich wydań (ang.
small releases), a także ciągłej integracji (ang. continuous inte-
gration). Należy zaznaczyć, iż kolektywna własność kodu mo-
że być nieco problematyczna w przypadku dużych systemów,
które wymagają bardziej sformalizowanych kanałów komunika-
cji, by skutecznie zapobiegać ewentualnym problemom związa-
nym z zarządzaniem konfiguracją oprogramowania. Pozostałe
obszary procesowe, poza „Analizą decyzyjną”, pozostają neu-
tralne względem podejścia XP. Analiza decyzyjna, obejmująca
analizę i wspomaganie procesu podejmowania decyzji, jest ra-
czej mało prawdopodobna (skrajnie możliwa) na gruncie XP,
choć nie wykluczona.

Zarządzanie procesem

Wreszcie ostatnia grupa obszarów procesowych modelu CMMI,
skupionych wokół kategorii „Zarządzania procesem”. Znalazły
się tutaj takie obszary jak:

• koncentracja na procesie organizacyjnym (ang. Organiza-

tional Process Focus) – przeprowadzanie ocena dojrzało-
ści istniejących procesów w organizacji (zdefiniowanie za-
kresu, metod oraz kryteriów oceny); analiza zachowań pro-
cesów pod kątem możliwości ich doskonalenia; planowanie
działań związanych z poprawą procesów organizacyjnych;
wdrażanie i ewaluacja nowych procesów w organizacji;

• definicja procesu organizacyjnego (ang. Organizational

Process Definition) – definiowanie procesów w organiza-
cji; określenie ich wzajemnych relacji; definiowanie możli-

Extreme Programming i CMMI

wych cyklów życia projektów (kaskadowy, spiralny, przyro-
stowy etc.); ustanowienie kryteriów przykrawania procesów
(ang. tailoring); ustanowienie ogólnodostępnego repozyto-
rium wszystkich procesów w firmie (ang. Process Assets Li-
brary); a także miejsca przechowywania metryk;

• szkolenia organizacyjne (ang. Organizational Training) – iden-

tyfikacja i analiza potrzeb szkoleniowych na poziomie ca-
łej organizacji; przygotowanie planu szkoleń (jego regular-
na aktualizacja); wybór dostawców szkoleń (wewnętrzni, ze-
wnętrzni); umożliwienie pracownikom dostępu do materia-
łów szkoleniowych (wewnętrzne biblioteki, zakup potrzeb-
nych książek, materiały video, płyty CD, e-książki); dostar-
czenie szkoleń (szkolenia wyjazdowe, wewnętrzne organizo-
wane przez innych pracowników, e-learning); ewaluacja do-
starczanych szkoleń;

• wydajność procesu organizacyjnego (ang. Organizational

Process Performance) – śledzenie zachowań procesów w
organizacji; zbieranie i analiza metryk procesowych; spo-
rządzanie na ich podstawie tzw. linii bazowych (ang. basli-
ne), które będą wyznaczały możliwe odchylenia od standar-
dowych zachowań procesów; wykorzystywanie narzędzi sta-
tystycznej analizy procesów;

• innowacje i wdrożenia (ang. Organizational Innovation and

Deployment) – doskonalenie istniejących procesów i stoso-
wanych technologii w organizacji; zbieranie i analiza propo-
nowanych rozwiązań; uruchamianie projektów pilotażowych
wdrażających te rozwiązania; ewaluacja rezultatów.

Obszary te mają bodajże najmniej wspólnego z podejściem
Extreme Programming. Dzieje się tak, ponieważ metody agile’o-
we zorientowane są przede wszystkim na projekt i ludzi, którzy
w nim pracują. Szczegółowe definiowanie procesów i procedur
na poziomie organizacji, z punktu widzenia podejścia XP, mają
małe znaczenie. Z obszarów tych jedynie dwa pozostają czę-
ściowo komplementarne: „Szkolenia organizacyjne” oraz „Inno-
wacje i Wdrożenia”. Projekty agile’owe, podobnie jak podejścia
strukturalne, definiują potrzeby szkoleniowe, organizują ludziom
niezbędne szkolenia, czy to związane z pełnionymi rolami w

projekcie, czy też nową technologią, która jest wykorzystywana.
Podobnie rzecz się ma z drugim obszarem procesowym – „In-
nowacje i wdrożenia”. Metoda XP jest metodą otwartą na wdra-
żanie nowych, innowacyjnych rozwiązań, zarówno w aspekcie
technologii jak i samego procesu tworzenia oprogramowania –
mających wpływ na jakość dostarczanego produktu.

Podsumowanie

Dyscyplina jest nieodzownym elementem wielu przedsięwzięć,
niekoniecznie informatycznych. Muzycy, sportowcy muszą pod-
dawać się wielogodzinnym treningom, żeby osiągnąć sukces.
Jednak, czymże byłaby dyscyplina bez kreatywności? W pierw-
szej części prezentowanego cyklu, zacytowana została książka
Jim Collins Good to Great (Collins J. 2001, New York: Harper-
Collins), gdzie mowa jest o dwóch czynnikach, które decydu-
ją o sukcesie w biznesie – dyscyplinie i postawie przedsiębior-
czej (kreatywność). Jeżeli organizacja skupia się tylko i wyłącz-
nie na dyscyplinie, rezultatem może być zbytnia biurokratyzacja
i stagnacja jej procesów wytwórczych. Z kolei przyjmowanie sa-
mej postawy przedsiębiorczości, może spowodować, iż począt-
kowy entuzjazm, związany z powstaniem firmy, może nie zostać
podtrzymany w kolejnych latach jej funkcjonowania. Dobre or-
ganizacje to takie, w których wymiar dyscypliny jest tak samo
obecny jak wymiar postawy przedsiębiorczej – na zasadzie rów-
nouprawnienia.

Celem prezentowanych artykułów nie była chęć wtłocze-

nia wybranych praktyk agile’owych do świata tradycyjnych me-
tod tworzenia oprogramowania. Chodziło raczej o znalezienie
pewnego rodzaju balansu/równowagi pomiędzy dwoma, dość
odmiennymi sposobami tworzenia software’u. Wiele punktów
wspólnych, które w trakcie tej analizy się ujawniło, stanowi dość
silny impuls do wypracowania podejścia, łączącego w sobie,
z jednej strony świat „lekkich” metod, reprezentowanych przez
podejście określane mianem Extreme Programming; z drugiej –
„tradycyjnych”, których istotę oddaje model CMMI. Jest to wy-
zwanie, przed którym stanęła dzisiaj inżynieria oprogramowania
– wyzwanie, którego jednak nie sposób nie podjąć. Chodzi prze-
cież o lepszą jakość tworzonego software’u. Czyż nie? n