plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2007

Extreme Programming (XP) i CMMI

– Kreatywność, czy Dyscyplina?

yscyplina jest nieodzownym elementem wie-

lu przedsięwzięć, niekoniecznie informa-

tycznych. Sportowcy, muzycy, rzemieślnicy,

żeby osiągnąć sukces w swojej branży, muszą pod-

dawać się wielogodzinnym treningom, które dosko-

nalą ich warsztat. Mówi się, iż dyscyplina daje pew-

nego rodzaju komfort – niezastąpiony w sytuacjach

granicznych – kiedy rzeczy stają się nagle nad wy-

raz skomplikowane. Dyscyplina stanowi swoisty re-

zerwuar tego wszystkiego, co w projektach informa-

tycznych określamy mianem danych historycznych,

doświadczenia.

Kreatywność, rozumiana jako przedsiębior-

czość, zwinność – stoi po przeciwnej stronie te-

go wszystkiego, co mieści w sobie pojęcie: „dys-

cypliny”. Dyscyplina jest czymś, co pozwala ugrun-

tować nasze wszystkie dotychczasowe działa-

nia; kreatywność – wyswobadza, uwalnia od przy-

jętych struktur, ram – nadając właściwą im szla-

chetność. Sprawia, że piłkarz potrafi strzelić zupeł-

nie niepowtarzalną bramkę, a muzyk – w jemu tyl-

ko właściwy sposób – wykonać określony utwór. W

świecie inżynierii oprogramowania – kreatywność

jest czymś, co pozwala szybko reagować na zmia-

nę. Potrafi wykorzystać dane historyczne oraz do-

świadczenie poszczególnych developerów i przy-

stosować je do nowego, ciągle zmieniającego się

środowiska ich pracy (nowe technologie, zmien-

ność wymagań klienta etc.).

Jim Collins w książce pod tytułem „Good to

Great” (Collins J. 2001, New York: HarperCollins)

mówi o dwóch czynnikach, które decydują o suk-

cesie w biznesie – dyscyplinie i postawie przed-

siębiorczej (kreatywność). Jeżeli organizacja sku-

pia się tylko i wyłącznie na dyscyplinie, rezulta-

tem może być zbytnia biurokratyzacja i stagnacja

jej procesów wytwórczych. Z kolei, przyjmowanie

samej postawy przedsiębiorczości, może spowo-

dować, iż początkowy entuzjazm, związany z po-

wstaniem firmy, może nie zostać podtrzymany w

kolejnych latach jej funkcjonowania. Dobre orga-

nizacje to takie, w których wymiar dyscypliny jest

tak samo obecny jak wymiar postawy przedsię-

biorczej – na zasadzie równouprawnienia.

Środowisko, w jakim znalazła się obecnie in-

żynieria oprogramowania, zmienia się w zawrot-

nym tempie. Systemy informatyczne stają się co-

raz bardziej złożone i wszechobecne. W ślad za

tym, rośnie tempo, w jakim zmieniają się wyma-

gania klienta. Wszystko to sprawia, iż jakość i uży-

teczność wytwarzanego oprogramowania zaczy-

nają odgrywać niesłychanie ważną – krytyczną

wręcz – rolę.

Świat tradycyjnych metod wytwarzania opro-

gramowania – zorientowany na proces, jego po-

wtarzalność oraz ciągłe doskonalenie – jako spo-

sób na radzenie sobie z wszechobecną zmianą,

proponuje umiejętność przewidywania zacho-

wań procesów wytwórczych. Przykładem trady-

cyjnych podejść, określanych niekiedy mianem

strukturalnych, jest Capability Maturity Model In-
tegration (CMMI) – wcześniej znany jako Capabi-
lity Maturity Model (CMM). Został on wdrożony w

tysiącach organizacji software’owych, w których

– jak pokazują raporty systematycznie publiko-

wane przez Software Engineering Institute (SEI)

– procesy związane z tworzeniem oprogramowa-

nia stały się mniej chaotyczne i bardziej powta-

rzalne. Przeciwnicy modelu, skarżą się na du-

że koszty jego wdrożenia. Pytają: „Czy faktycz-

nie musimy poświęcać cenny czas programistów

na tworzenie zbędnej dokumentacji, podczas

gdy naszego klienta interesuje przede wszystkim

działający produkt? Czy chcemy, aż takiej biu-

rokratyzacji życia? Czy naszą firmę stać na za-

trudnienie całego sztabu ludzi, którzy zajęliby się

wdrażaniem modelu oraz kontrolą jakości proce-

sów wytwórczych?”.

Jako reakcja na tego typu podejścia wykształ-

cił się inny nurt, który – na wszechobecną zmianę

– patrzy z zupełnie innej perspektywy. Nowe podej-

ście, określane mianem „agile”, zachęca programi-

stów do porzucenia surowej dyscypliny, wynikają-

cej z konieczności ścisłego definiowania poszczegól-

nych procesów, i uznanie zmiany – jako czegoś na-

turalnego i obecnego w cyklu życia projektu. Jest to

podejście, które charakteryzuje iteracyjny cykl życia

projektu oraz bliskie zaangażowanie klienta w prace

zespołu projektowego.

Agile, jest tym wszystkim, co uosabia pojęcie kre-

atywności – spontanicznością, zwinnością (agility),

otwartością na zmianę, a także odwagą w przekra-

czaniu stereotypów. Metody agile, mimo iż należą

Mariusz Chrapko

Autor pracuje w Motorola Polska Electronics sp. z o.o.
(krakowskie  Centrum  Oprogramoawnia  Motoroli)  na
stanowisku inżyniera jakości. Od strony zawodowej in-
teresuje  się  problematyką  doskonalenia  procesu  two-
rzenia oprogramowania w oparciu o Model CMMI, a tak-
że praktykami Agile Software Development. Prywatnie
lubi  jazz  i  filozofię  (głównie  współczesną).  W  wolnych
chwilach fotografuje.
Kontakt z autorem: mariusz.chrapko@gmail.com

Extreme Programming (XP) i CMMI

www.sdjournal.org

Software Developer’s Journal 10/2007

obecnie do bodajże najbardziej popularnych tematów w dzie-

dzinie zarządzania przedsięwzięciami informatycznymi, mają

również swoich zagorzałych oponentów, szczególnie wśród

dużych organizacji, które pytają: „Czy możemy zajmować się

dużymi projektami bez kompleksowej dokumentacji? Czy mo-

żemy sobie pozwolić na akceptację każdej zmiany, po dopie-

ro co zakończonych negocjacjach z klientem (często kilkumie-

sięcznych)?”.

Publikacja stanowi próbę pogodzenia tych dwóch, pozor-

nie odmiennych stanowisk: „lekkiego” (Extreme Programming)

oraz „strukturalnego” (CMMI), które podobnie jak – zaczerp-

nięte ze starożytnej filozofii chińskiej – dwie pierwotne siły Yin

i Yang, z jednej strony są przeciwstawne, z drugiej zaś jednak

nigdy się nie wykluczają. Wszystko ma swoje przeciwieństwo,

jednak nigdy całkowite. Żadna rzecz nie jest nigdy w pełni Yin,

ani całkowicie Yang.

Extreme Programming (XP)

Nie sposób mówić o Extreme Programming, nie wspomina-

jąc Kenta Becka, który uważany jest za twórcę tej metody. W

swojej książce „Extreme Programming – Explained” [K. Beck,
1999, 2004], definiuje ją jako: „lekką, wydajną, o niskim pozio-

mie ryzyka, elastyczną, naukową, i sprawiającą przyjemność

metodę wytwarzania oprogramowania”. Jest metodą zapro-

jektowaną dla małych i średnich zespołów projektowych, sta-

nowiąc tym samym pewnego rodzaju przeciwwagę dla trady-

cyjnych podejść.

Podejście XP składa się z 3 podstawowych elementów:

wartości, zasad oraz praktyk. Wartości, stanowią „twardy

rdzeń” tej metody, stanowiąc jednocześnie podstawę dla po-

zostałych elementów, co obrazuje Rysunek 1.

Extreme Programming mówi o pięciu podstawowych war-

tościach, których nie może zabraknąć podczas realizacji pro-

jektów informatycznych:

Prostota (ang. Simplicity). Buduj system możliwie jak naj-

mniej skomplikowany. Tradycyjne metody wytwarzania opro-

gramowania, zanim przystąpią do implementacji wymagań

klienta, wcześniej – wszystko dokładnie planują (tzw. „up–
front planning” ). Można powiedzieć, iż klientowi na samym

początku, dostarczona jest pewna gotowa wizja całości. W

tego typu podejściach zmiana, w kolejnych fazach realiza-

cji projektu, jest raczej mało prawdopodobna, czasem wręcz

niemożliwa. Zupełnie innego typu sytuacja ma miejsce w me-

todzie XP, dla której tak naprawdę najważniejsze są aktualne

potrzeby klienta. Bardzo dobrze oddaje to powiedzenie, któ-

re określane jest w skrócie: „YAGNI” (You aren’t going need it)

– developerzy powinny implementować tylko to, co wyraża-

ją aktualne potrzeby klienta; nie zaś to co, ich zdaniem, może

być klientowi potrzebne.

Komunikacja (ang. Communication). Dla Extreme Pro-

gramming, komunikacja stanowi kluczową wartość. Wie-

le problemów związanych z życiem projektu wywodzi się

właśnie ze złej komunikacji. Czasem developer nie powia-

domi odpowiedniej osoby o zmianie, którą wprowadził w

projekcie systemu; czasem menedżer nie zada develope-

rowi właściwego pytania. XP wpływa na poprawę komuni-

kacji w zespole przez stosowanie określonej grupy prak-

tyk, których egzekwowanie nie jest możliwe bez właściwej

komunikacji.

Sprzężenie zwrotne (ang. Feedback). Jest to integral-

na część każdej dwustronnej komunikacji. W XP feedback

jest nam przekazywany cały czas. Możemy mówić o feed-

backu w skali „minut i dni”. Programista przygotowuje ze-

staw testów jednostkowych (unit tests), które testują logi-

kę naszego systemu. W ten sposób otrzymuje, minuta po

minucie, wiadomość o tym, co działa źle w jego systemie

i wymaga poprawy. Podobnie, szybką informację zwrotną

otrzymuje klient, który pisze kartę klienta (ang. user story)

– opisującą nową funkcjonalność, którą chciałby, żeby by-

ła dodana do jego systemu. Developer estymuje czas ja-

ki poświęci na jej implementację, przez co klient otrzymuje

szybką informację zwrotną na temat możliwości implemen-

tacji zaproponowanej przez niego zmiany. W Extreme Pro-
gramming możemy również mówić o feedback’u w skali „ty-

godni i miesięcy”. Tester wraz z klientem przygotowuje ze-

staw testów funkcjonalnych, których zadaniem jest spraw-

dzenie poprawności zaimplementowanych wymagań. W ten

sposób otrzymują konkretną informację na temat aktualne-

go stanu ich systemu.

Odwaga (ang. Courage). Pozostaje w ściślej zależ-

ności z pozostałymi wartościami: prostotą, komunikacją

oraz sprzężeniem zwrotnym. Odwaga w XP, to umiejęt-

ność pro-aktywnego rozwiązywania problemów – śmia-

łość działania, oparta na solidnych podstawach, w posta-

ci zautomatyzowanej uprzęży testowej (automatem – test
harness).

Respekt (ang. Respect). Wartość, która scala pozosta-

łe wartości. Respekt – to poważanie i szacunek, którym po-

winni się wzajemnie obdarowywać członkowie zespołu pro-

jektowego. Bez tej wartości, metoda Extreme Programming

pozostaje tylko czczą ideą. Wartości XP stanowią pewne-

go rodzaju układ odniesienia dla pracy zespołów projekto-

wych. Zbiór ten, nie jest zbiorem domkniętym. Organizacja,

zespół, a nawet poszczególni developerzy mogą go dowol-

nie rozbudowywać.

Oprócz wartości, metoda XP wskazuje również na okre-

ślony zbiór zasad, które stanowią pewnego rodzaju pomost,

łączący je z konkretnymi praktykami developerskimi. Extreme
Programming wymienia następujące zasady:

• humanitaryzm (Humanity) – Software jest tworzony przez

ludzi! Developerzy powinni mieć zapewnione wszystkie

niezbędne warunki, które umożliwią im niczym nie skrępo-

waną pracę;

• ekonomia (Economics) – ktoś musi za wszystko zapłacić!

Upewnij się czy to, co robisz ma jakąś wartość biznesową,

Rysunek 1.

„Twardy rdzeń” metody XP stanowią wartości,

które wspierane są przez zasady i praktyki

��

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2007

czy realizuje cele biznesowe oraz czy odpowiada na po-

trzeby rynku;

• wzajemna korzyść (Mutual Benefit) – każde działanie, po-

winno przynosić korzyść wszystkim tym, którzy się w nie-

go angażują! Tworząc oprogramowanie, używaj tylko tych

praktyk developerskich, z których będziesz miał pożytek,

podobnie jak i Twój klient;

• powielanie dobrych rozwiązań (Self-Similarity) – powielaj

dobre rozwiązania wszędzie tam, gdzie jest to możliwe;

• doskonalenie (Improvement) – nie ma doskonałego proce-

su! Nie ma doskonałego projektu systemu! Wykonuj swoją

pracę tak dobrze jak tylko potrafisz. Wyciągaj wnioski z te-

go, co zrobiłeś źle, by móc to doskonalić;

• różnorodność (Diversity) – jednorodne zespoły projek-

towe są mało efektywne! Zespoły powinny składać się

z osób o zróżnicowanych umiejętnościach i zaintereso-

waniach. Umożliwia to spoglądanie na problemy projek-

towe z różnych perspektyw. Zespoły potrzebują różno-

rodności;

• refleksja (Reflection) – dobre zespoły, nie tylko wykonują

swoją pracę, ale zastanawiają się także nad tym „jak” to

robią oraz „dlaczego”. Otwarcie mówią o swoich niepowo-

dzeniach;

• przepływ (Flow) – dostarczaj małe fragmenty działającego

software’u, angażując się we wszystkie aktywności deve-

loperskie równocześnie;

• okazja (Opportunity) – ucz się na błędach! Traktuj każdy

napotkany problem, jako środek do pogłębienia własnej

wiedzy, budowania dojrzałych relacji w zespole, a także

doskonalenia wytwarzanego produktu, nad którym pra-

cujesz;

• nadmiarowość (Redundancy) – o ile redundancja sama w

sobie może być nieekonomiczna, o tyle nie należy z niej

rezygnować, jeżeli służy właściwym celom! Problemy, któ-

re są krytyczne z punktu widzenia developmentu, zawsze

rozwiązuj na kilka możliwych sposobów;

• niepowodzenie (Failure) – nie wiesz, którą z trzech możli-

wych implementacji danej funkcjonalności wybrać? Zaim-

plementuj każdą z osobna, nawet, jeżeli istnieje ryzyko, że

wszystkie zakończą się niepowodzeniem. Czy niepowo-

dzenie jest nieekonomiczne? Nie, jeżeli niesie ze sobą pe-

wien ładunek wiedzy;

• jakość (Quality) – dopinguj projekty do dostarczania pro-

duktów o najwyższej jakości! Tempo prac projektowych

nie wzrośnie, jeżeli założysz ich niższą jakość. Niższa ja-

kość często skutkuje późniejszym dostarczeniem produk-

tu w ręce klienta;

• kroki dziecka (Baby Steps) – wprowadzanie dużych

zmian jednocześnie, może być bardzo niebezpieczne!

Dlatego wprowadzaj je małymi krokami (na wzór kroków

dziecka);

• akceptowana odpowiedzialność (Accepted Responsi-

bility) – odpowiedzialność nie może zostać przypisa-

na, należy ją zaakceptować! Jeśli ktoś chce Ci ją przy-

pisać, Ty musisz sam zdecydować, że weźmiesz ją na

Siebie.

Cykl życia projektów XP

Do istoty projektów informatycznych, realizowanych w du-

chu XP, należy bliska współpraca świata biznesu (klient)

ze światem techniki (developer). Klient jest aktywnie zaan-

gażowany na każdym etapie prac projektowych. Czuwa, by

dostarczany produkt posiadał tylko jemu właściwą wartość

biznesową (Rysunek 2).

Wydawać by się mogło, iż nie ma tutaj nic nowego.

Realizacja każdego projektu informatycznego skupia się

przecież na tworzeniu i dostarczaniu produktu, który po-

siada określoną wartość w oczach naszego klienta. Róż-

nica polega jednak na tym, iż w XP, proces ten przebie-

ga bardzo szybko, z dużą częstotliwością. Zespół dostar-

cza małe fragmenty funkcjonalności z dużym rozmachem

(w skali minut, godzin, czy dni) – w odróżnieniu od podejść

tradycyjnych, gdzie klient niekiedy zmuszony jest czekać

długie miesiące, a nawet lata, żeby jego produkt został do-

starczony. Cykl życia projektu w XP składa się z 5 faz, co

obrazuje Rysunek 3.

Eksploracja

Jest to etap, w którym po raz pierwszy dociera do nas,

czym tak naprawdę mamy się zajmować. Klient dostarcza

tzw. „vision statement” – wysokopoziomowy opis systemu,

który mamy zaprojektować. Zazwyczaj liczy on nie więcej

niż 30 słów (niewiele), i stanowi podstawę do stworzenia

„Metafory systemu” (ang. system meaphor) – praktyki, któ-

rej celem jest wyjaśnienie zasad działania systemu za po-

mocą krótkich, prostych historii. Metafora stanowi namiast-

kę czegoś, co w tradycyjnych podejściach określane jest

mianem „architektury systemu”.

George Lakoff i Mark Johnson, w napisanej wspólnie

książce Metaphors we live by (2003, London: The Univer-
sity of Chicago Press), metaforę określają jako „rozumie-

nie i doświadczenie pewnego rodzaju rzeczy w terminach

innej rzeczy”.

Praktyka metafory, którą posługuje się metoda XP, ma na

celu przede wszystkim usprawnienie komunikacji pomiędzy

zespołem developerów a naszym klientem. Właściwie wyko-

rzystana, może stanowić cenne narzędzie, nie pozostające

bez wpływu na efektywność prac projektowych.

Dobra metafora wyzwala kreatywność w zespole. Usta-

la wspólne nazwy dla obiektów oraz ich relacji. Załóżmy,

że pracujemy nad aplikacją, której celem ma być wspar-

cie dla osób, pracujących w dziale obsługi klienta (ang. cu-
stomer service representatives). Jedną z możliwych meta-

for, opisujących pracę takiego systemu, jest próba spojrze-

nia na proces obsługi klienta jak na pracę linii montażowej.

Rysunek 2.

Klient definiuje wartość, developer ją tworzy i

dostarcza

��

Extreme Programming (XP) i CMMI

www.sdjournal.org

Software Developer’s Journal 10/2007

Tego typu metafora od razu nam sugeruje, iż rozwiązanie

każdego problemu, zgłoszonego wcześniej przez klienta,

będzie kilkuetapowe. Pracę techników oraz osób pracują-

cych w dziale obsługi klienta można przyrównać do pra-

cy osób przy stanowiskach montażowych. Widzimy, iż ta-

ka metaforyczna wizualizacja pracy systemu znacznie uła-

twia nam jego zrozumienie – zwłaszcza, jeśli chodzi o na-

szego klienta. Metafora wyzwala całe mnóstwo pytań, któ-

re w normalnych okolicznościach nigdy by się nie pojawiły.

Po pierwsze, jaka jest przepustowość systemu? (ilość pro-

blemów rozwiązywanych/godzinę). Co stanie się ze zgło-

szonym problemem, gdy osiągnie on ostatni etap linii mon-

tażowej? Być może system powinien wysyłać jakąś infor-

mację zwrotną do klienta? I tak dalej, i tak dalej.

Z fazą eksploracji, związana jest inna, ważna praktyka

XP tzw. „Karty klienta (ang. user stories) – bardzo lakoniczne

opisy poszczególnych funkcjonalności systemu (najczęściej

zapisane na małych karteczkach), przygotowywane przez

klienta lub jego reprezentanta. Ron Jeffries, w jednym ze

swoich artykułów, wskazuje na 3 ważne aspekty user stories

(„Essential XP: Card, Conversation, Confirmation.” XP
Magazine, 30.08.2001):

• karta (ang. Card) – krótki opis historii, zapisany ręcznie na

małej karteczce;

• konwersacja (ang. Conversation) – rozmowa na temat user

story (pozwala uzyskać więcej informacji);

• potwierdzenie (ang. Confirmation) – testy, które stanowią

świadectwo tego, iż funkcjonalność, którą zażyczył sobie

od nas klient została poprawnie zaimplementowana.

Z kolei Rachel Davies (The Power of Stories XP 2001. Sardy-

nia, 2001) trafnie zauważył, iż karty klienta bardziej reprezen-

tują jego wymagania, aniżeli ich dokumentację – i tak powin-

niśmy je właśnie traktować. User stories stanowią tylko krótki

zapis danej funkcjonalności; szczegóły wypracowywane są w

rozmowach i potwierdzane w testach.

W fazie eksploracji, klient przygotowuje zestaw wyso-

kopoziomych user stories, które następnie wykorzystywa-

ne są przez developerów do estymowania czasu ich imple-

mentacji. Estymaty na tym, początkowym etapie, posiada-

ją dość duży stopień ogólności, niemniej jednak wyznacza-

ją kierunek prac w kolejnych cyklach życia projektu. W XP,

do najczęściej używanych technik estymacyjnych należą

techniki oparte na metodzie Wideband Delphi, którą Barry

W. Boehm opisał w swojej książce „Software Engineering
Economics” (Englewood Cliffs, NJ: Prentice – Hall, 1981).

Oczywiście nie wykluczone jest zastosowanie innych tech-

nik, bardziej zaawansowanych – o tym jednak decyduje już

sam zespół.

W celu podniesienia dokładności szacowanych wielko-

ści, developerzy bardzo często posiłkują się techniką spike-

’owania (ang. spike). Jest ona szczególnie pomocna w sy-

tuacjach, gdy trudno nam jednoznacznie stwierdzić, ile cza-

su zajmie nam implementacja określonego rozwiązania.

Wówczas przygotowujemy jego prototyp, który pozwoli nam

oszacować rzeczywisty czas, jaki będzie potrzebny na jego

development. Warto dodać, iż kod, który powstaje na skutek

tej praktyki, jest zwykle odrzucany i nie nadaje się do po-

nownego użytku.

Faza planowania

Podstawowym narzędziem, służącym do planowania pro-

jektów informatycznych w metodzie XP jest praktyka, któ-

rej nazwa może być nieco kontrowersyjna zwłaszcza, je-

śli chodzi o menedżerów – mianowicie „Zabawa w plano-

wanie” (ang. planning game). Jest to kolejna z praktyk XP,

w której znakomicie uwidacznia się bliskie zaangażowanie

i współpraca klienta jako pełnowartościowego członka ze-

społu projektowego. Celem „Zabawy w planowanie” jest po

prostu – zaplanowanie poszczególnych prac projektowych.

Developerzy spotykają się z klientem przy wspólnym sto-

le. Na stole leżą rozrzucone małe karteczki (najczęściej

samoprzylepne) – user stories. Mimo, iż całość przypomi-

na trochę scenę z filmu „Back to the future”, ma jednak nie-

zwykłą skuteczność. Oczywiście, zamiast używania ręcz-

nie zapisanych karteczek, można używać innych narzędzi,

na przykład aplikacji webowych – decyzja zależy od kre-

atywności zespołu.

Iteracje

W metodzie XP, cykl tworzenia oprogramowania podzielony

jest na tzw. wydania (ang. releases), które z kolei składają się

z iteracji (Rysunek 4).

Typowy czas trwania jednej iteracji to 1 – 4 tygodni.

Należy zauważyć, iż początkowe iteracje zazwyczaj pla-

nuje się tak, aby skupiały się na architekturze poszczegól-

nych komponentów, stanowiąc tzw. baseline – linię bazo-

wą dla powstającego systemu. Tego typu iteracje, niekiedy

określane są jako zero business value – gdyż tak napraw-

dę, z punktu widzenia klienta, nie dostarczają żadnej war-

tości biznesowej. Kolejne, wnoszą już więcej treści w po-

wstający produkt. Musimy pamiętać, iż to klient decydu-

je o tym, co powinno się w nich znaleźć. To on jest „moto-

rem zmiany” – którą w tym kontekście należy właściwie ro-

zumieć. Extreme Programming posługuje się techniką time
boxingu – zakres prac w ramach poszczególnych iteracji

nie może ulec zmianie. Innymi słowy – robimy to, co zapla-

nowaliśmy. Technika time boxingu jest znaną i powszech-

Rysunek 3.

Cykl życia projektu XP

��

��
��

��

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2007

nie stosowaną metodą planowania i monitorowania projek-

tów informatycznych. Każdy time box ma określony, stały

czas trwania – zwykle od 1 do 4 tygodni i – po ustalonym

wcześniej terminie dostarczenia – produkt musi znaleźć

się w rękach klienta. Tak więc, gdy zaczniemy już prace w

ramach danej iteracji, zakres prac nie powinien ulec zmia-

nie. Time boxing chroni nas przez klientami niezdecydowa-

nymi. Każda iteracja – to proces w pełnym tego słowa zna-

czeniu. Ma swoje wejścia, wyjścia – posiada swój rytm, co

obrazuje Rysunek 5.

Iteracje, to ten moment w życiu projektu, kiedy ma miej-

sce prawdziwy development. Na początku każdej iteracji

klient, bądź jego reprezentant przygotowuje zestaw user
stories, które powinny zostać zaimplementowane. Develo-

perzy rozbijają je na mniejsze taski (zadania), które z kolei

przydzielane są do poszczególnych programistów. Praca

jest estymowana i priorytetyzowana. Developerzy pracu-

ją w parach, siedząc przy jednej stacji roboczej, używając

tylko jednej klawiatury i jednej myszki. Kodują, dyskutują,

uczą się wspólnie rozwiązywać problemy – „co dwie gło-

wy, to nie jedna”. I nie chodzi tu o patrzenie sobie na ręce,

wytykanie błędów – ale o autentyczną pracę, wspólną od-

powiedzialność za kod. W metodzie XP – system stanowi

własność wszystkich, którzy nad nim pracują. Ideę tę wy-

raża kolejna praktyka XP, określana mianem „Kolektywnej

własności kodu” (ang. collective ownership). Jest to zupeł-

nie przeciwne podejście do tego, które spotykamy w trady-

cyjnych metodach tworzenia oprogramowania, gdzie ma-

my do czynienia z – instytucją wręcz! – właściciela (owner)

danego modułu, bądź obszaru funkcjonalnego. Zapewnia

to oczywiście duże poczucie bezpieczeństwa i zaufania, z

drugiej jednak strony prowadzi do niepotrzebnych frustra-

cji – kluczowi właściciele kodu nagle znikają (urlop, choro-

ba, zmiana pracy) – wszyscy stajemy się zakładnikami ko-

du, który w dodatku nie jest naszą własnością.

Programowanie w parach, współużytkowanie kodu, zna-

komicie koresponduje z kolejną praktyką XP – wspólny

„Standard kodowania” (ang. coding standard): zbiór wska-

zówek i zasad, mających na celu ujednolicenie wyglądu pi-

sanego przez nas kodu (format, struktura kodu, nazewnic-

two, komentarze). Posiadanie wspólnego standardu kodo-

wania odgrywa niebagatelną rolę zwłaszcza, gdy kod pisa-

ny jest w parach.

Zanim jednak developerzy zaczną kodować – wcze-

śniej przygotowują zestaw testów. Testowanie w XP wy-

gląda trochę inaczej, niż w przypadku tradycyjnych po-

dejść kaskadowych, gdzie faza testów następuje zaraz

po fazie kodowania. W XP testy powstają zanim powsta-

nie kod. Developerzy przygotowują zestaw testów jed-

nostkowych (ang. unit tests), których zadaniem jest prze-

testować wszystko, co tak naprawdę może się zepsuć.

Służą temu specjalne szkielety testowe (np. JUnit, CPPU-

nit, VBBUnit). Testy są zautomatyzowane, dzięki czemu

mogą być uruchamiane w sposób ciągły, po każdej inte-

gracji. Takie podejście jest niezwykle elastyczne, klient

jak i developerzy otrzymują praktycznie ciągłą informację

zwrotną o swoim produkcie.

Praktyka testów w XP sprzyja zwiększeniu zaufania

developerów do ich kodu, stanowiąc jednocześnie podsta-

wę do zastosowania praktyki refaktoringu – ulepszania ko-

du bez zmiany jego funkcjonalności. W odróżnieniu od tra-

dycyjnych podejść, gdzie refaktoring był raczej uzależnio-

ny od wolnego czasu developerów, w XP proces ten za-

chodzi w trakcie całego procesu tworzenia oprogramowa-

nia. Dlaczego? Bo kod, który otrzyma nasz klient, powi-

nien być możliwie jak najmniej skomplikowany – ekstremal-

nie prosty.

Kod dostarczony przez programistów jest integrowa-

ny. W XP mówi się o praktyce „Ciągłej integracji” (ang.
continuous integration). Moduły poszczególnych funkcjo-

nalności poddawane są procesowi integracji tak często,

jak to tylko możliwe (raz dziennie, co kilka godzin). Prak-

tycznie ciągłe testy regresyjne testują działanie syste-

mu po to, żeby sprawdzić czy nowo wprowadzone zmia-

ny nie spowodowały pojawienia się niepożądanych skut-

ków ubocznych.

Na końcu każdej iteracji klient wykonuje testy akcepta-

cyjne (ang. acceptance tests), które wcześniej sam przygo-

tował. Stanowią one swoistą bramę jakości (ang. quality ga-
te), która zadecyduje o kształcie kolejnej iteracji. Testy, któ-

re nie przejdą w danej iteracji muszą zostać poprawione w

kolejnej.

Produkcja (ang. Productionizing)

Jest to moment, w którym prace w ramach danego rele-

ase’u są finalizowane, produkt jest weryfikowany (testy ak-

ceptacyjne) i przygotowywany do oddania w ręce klienta.

To, jaką postać przyjmie faza produkcji, zależy tak napraw-

dę od bardzo wielu czynników zarówno tych, które znajdu-

ją się po stronie klienta, jak i tych, które zależą od deve-

loperów. Z czysto teoretycznego punktu widzenia, system

rozwijany w duchu XP, powinien być gotowy do wdrożenia

na platformie produkcyjnej klienta po zakończeniu pierw-

szej iteracji. Praktyka jednak pokazuje, iż tak naprawdę

pierwsza iteracja stanowi jedynie tło dla całego develop-

mentu, i z punktu widzenia klienta posiada zerową wartość

biznesową, bez której jednak trudno byłoby nam mówić o

dalszym, sensownym rozwijaniu systemu.

Moment wdrożenia każdorazowo zależy od specyfiki da-

nego projektu. W zależności od sytuacji możliwe są tutaj róż-

ne scenariusze:

system wdrażany jest na zasadzie „wielkiego wybuchu”

(Big Bang). Wdrożenie przebiega w sposób mało skompli-

kowany, ryzyko jest duże;

Rysunek 4.

Release’y w XP składają się z iteracji

��

Extreme Programming (XP) i CMMI

www.sdjournal.org

Software Developer’s Journal 10/2007

funkcjonalności dostarczane są małymi partiami, co jest

możliwe gdy system da się podzielić na małe logiczne

fragmenty, ryzyko jest niskie;

stary i nowy system pracują przez pewien okres czasu

równolegle. Niestety, mimo niskiego ryzyka związanego z

tym podejściem, koszt całego przedsięwzięcia przemawia

zdecydowanie przeciwko takiemu rozwiązaniu;

wdrażany system nie ma swojego poprzednika. Może-

my mieć do czynienia z jakąś nową linią biznesową,

wspierająca funkcjonowanie określonego software’u –

sytuacja wymarzona; poziom ryzyka jest najniższy ze

wszystkich omawianych przypadków, poza tym nie ma-

my żadnych problemów związanych z integracją ze sta-

rym systemem.

Podtrzymanie (ang. Maintenance)

Po wdrożeniu, przychodzi czas na podtrzymanie (ang. ma-
intenance). Używając praktyki metafory, system w tej fa-

zie, można przyrównać do dziecka w początkowym okre-

sie jego życia. Wdrożenie systemu jest jak stawianie pierw-

szych kroków, które początkowo są bardzo niepewne i ro-

dzice muszą wciąż podtrzymywać swoją pociechę, usuwać

niebezpieczne przedmioty z drogi, etc. – by mogło się swo-

bodnie poruszać, by przypadkiem się nie wywróciło. Taka

właśnie jest faza podtrzymania – pełna troski o pierwsze

kroki systemu.

W tej fazie doskonalimy i optymalizujemy software, któ-

ry został dostarczony w ręce klienta. Jest to czas wprowadza-

nia poprawek, różnego rodzaju patchy, a także upgrade’u sys-

temu. W XP jest to o tyle przyjazne, że mamy zautomatyzo-

waną platformę testową, która umożliwia swobodne ekspery-

mentowanie na kodzie.

Metryki w XP

XP jest metodą, która podobnie jak tradycyjne podejścia

tworzenia oprogramowania, posługuje się metrykami. Me-

tryki służą do monitorowania projektu, śledzenia i plano-

wania poszczególnych jego prac. Są nieocenione w proce-

sie szacowania wielkości poszczególnych iteracji. Pozwala-

ją nam zmierzyć określone własności software’u, (gęstość

błędów, wielkość kodu), projektu (czas trwania, koszty), a

także procesu tworzenia oprogramowania (skuteczność

usuwania błędów). Metryki tworzone są za pomocą okre-

ślonych miar. I tak na przykład metryka, określająca gę-

stość błędów w napisanym przez nas kodzie składa się z

dwóch miar: liczby błędów oraz liczby linii kodu (KLOC),

do których błędy zostały wprowadzone. Ich stosunek po-

zwala stwierdzić, jaką gęstość błędów posiada napisany

przez nas kod.

W XP, podstawową miarą są tzw. story points. Z ich udzia-

łem powstaje metryka prędkości projektu (ang. velocity), któ-

ra określa, ile story points zostało zaimplementowanych w ra-

mach danej iteracji.

Story points można dowolnie definiować. Dla jednego

projektu mogą oznaczać tzw. idealny dzień pracy (ang. ide-
al day), a więc dzień bez spotkań, maili, telefonów etc.; dla

innego zaś idealny tydzień pracy (ang. ideal week). Wyda-

je się jednak, iż najlepszym określeniem pasującym do tej

miary jest, zaproponowane przez Joshua’ę Kerievsky’ego –
Nebuluous Units of Time (NUT)”, a więc „Mgliste Jednost-

ki Czasu” (J. Kerievsky, extremeprogramming@yahoogro-
ups.com, 05. 08. 2003).

W oparciu o story points i metrykę velocity przygotowywa-

ne są tzw. wykresy spalania (ang. burndown charts) dla po-

szczególnych iteracji oraz release’ów. Pozwalają one dokład-

nie śledzić zachowanie projektu, przewidywać pewne zdarze-

nia, szacować ich rozmiar. Metryki są bardzo cennym narzę-

dziem, również w tradycyjnych metodach tworzenia oprogra-

mowania.

Podsumowanie

Artykuł jest pierwszą częścią cyklu trzech artykułów, poświę-

conych porównaniu dwóch metod tworzenia oprogramowania

– „lekkich”, reprezentowanych przez podejście określane mia-

nem Extreme Programming oraz „tradycyjnych”, których istotę

oddaje model CMMI.

Publikacja omawia podstawowe zasady, jakimi kieru-

je się jedna z bardziej znanych metod agile'owych – Extre-
me Programming. Została ona powiązana z tym wszyst-

kim, co uosabia pojęcie „kreatywności” – spontaniczno-

ścią, zwinnością (agility), otwartością na zmianę, a także

odwagą w przekraczaniu stereotypów. Trzy podstawowe

elementy metody XP – wartości, zasady oraz praktyki de-

veloperskie – przedstawione zostały z perspektywy pięciu

faz cyklu życia Extreme Programming: Planowania, Eks-

ploracji, Iteracji, Produkcji oraz Podtrzymania (ang. Main-
tenance). Dodatkowo, wyszczególniono zbiór podstawo-

wych metryk, którymi posługują się projekty realizowane

w duchu XP.

Druga część prezentowanego cyklu, która ukaże się

w kolejnym numerze pisma, omówi tradycyjne meto-

dy tworzenia oprogramowania. Wykorzystują one najczę-

ściej kaskadowy cykl życia projektu (wymagania/projekt/

implementacja), a ich cechą charakterystyczną jest precy-

zyjnie zdefiniowany proces, który podlega ciągłemu dosko-

naleniu. Wyrażają to wszystko, co zawiera się w pojęciu

„dyscypliny”. Tradycyjne podejścia, określane niekiedy mia-

nem strukturalnych, omówione zostaną na przykładzie Ca-
pability Maturity Model Integration (CMMI) – wcześniej zna-

nego jako Capability Maturity Model (CMM).

W kolejnej, trzeciej, części cyklu – przedstawiona zo-

stanie próba pogodzenia tych dwóch, pozornie odmien-

nych, stanowisk: „lekkiego” (Extreme Programming) oraz

„strukturalnego” (CMMI). Praktyki metody XP zestawione

zostaną z obszarami procesowymi (ang. Process Areas)

modelu CMMI. Siła „kreatywności” zmierzy się z siłą „dys-

cypliny”. n

Rysunek 5.

Cykl życia iteracji w XP

��