Inżynieria
oprogramowania
Extreme Programming (XP) i CMMI
 Kreatywność, czy Dyscyplina?
Mariusz Chrapko
yscyplina jest nieodzownym elementem wie- nizacje to takie, w których wymiar dyscypliny jest
lu przedsięwzięć, niekoniecznie informa- tak samo obecny jak wymiar postawy przedsię-
Dtycznych. Sportowcy, muzycy, rzemieślnicy, biorczej  na zasadzie równouprawnienia.
żeby osiągnąć sukces w swojej branży, muszą pod- Środowisko, w jakim znalazła się obecnie in-
dawać się wielogodzinnym treningom, które dosko- żynieria oprogramowania, zmienia się w zawrot-
nalą ich warsztat. Mówi się, iż dyscyplina daje pew- nym tempie. Systemy informatyczne stają się co-
nego rodzaju komfort  niezastąpiony w sytuacjach raz bardziej złożone i wszechobecne. W ślad za
granicznych  kiedy rzeczy stają się nagle nad wy- tym, rośnie tempo, w jakim zmieniają się wyma-
raz skomplikowane. Dyscyplina stanowi swoisty re- gania klienta. Wszystko to sprawia, iż jakość i uży-
zerwuar tego wszystkiego, co w projektach informa- teczność wytwarzanego oprogramowania zaczy-
tycznych określamy mianem danych historycznych, nają odgrywać niesłychanie ważną  krytyczną
doświadczenia. wręcz  rolę.
Kreatywność, rozumiana jako przedsiębior- Świat tradycyjnych metod wytwarzania opro-
czość, zwinność  stoi po przeciwnej stronie te- gramowania  zorientowany na proces, jego po-
go wszystkiego, co mieści w sobie pojęcie:  dys- wtarzalność oraz ciągłe doskonalenie  jako spo-
cypliny . Dyscyplina jest czymś, co pozwala ugrun- sób na radzenie sobie z wszechobecną zmianą,
tować nasze wszystkie dotychczasowe działa- proponuje umiejętność przewidywania zacho-
nia; kreatywność  wyswobadza, uwalnia od przy- wań procesów wytwórczych. Przykładem trady-
jętych struktur, ram  nadając właściwą im szla- cyjnych podejść, określanych niekiedy mianem
chetność. Sprawia, że piłkarz potrafi strzelić zupeł- strukturalnych, jest Capability Maturity Model In-
nie niepowtarzalną bramkę, a muzyk  w jemu tyl- tegration (CMMI)  wcześniej znany jako Capabi-
ko właściwy sposób  wykonać określony utwór. W lity Maturity Model (CMM). Został on wdrożony w
świecie inżynierii oprogramowania  kreatywność tysiącach organizacji software owych, w których
jest czymś, co pozwala szybko reagować na zmia-  jak pokazują raporty systematycznie publiko-
nę. Potrafi wykorzystać dane historyczne oraz do- wane przez Software Engineering Institute (SEI)
świadczenie poszczególnych developerów i przy-  procesy związane z tworzeniem oprogramowa-
stosować je do nowego, ciągle zmieniającego się nia stały się mniej chaotyczne i bardziej powta-
środowiska ich pracy (nowe technologie, zmien- rzalne. Przeciwnicy modelu, skarżą się na du-
ność wymagań klienta etc.). że koszty jego wdrożenia. Pytają:  Czy faktycz-
Jim Collins w książce pod tytułem  Good to nie musimy poświęcać cenny czas programistów
Great (Collins J. 2001, New York: HarperCollins) na tworzenie zbędnej dokumentacji, podczas
mówi o dwóch czynnikach, które decydują o suk- gdy naszego klienta interesuje przede wszystkim
cesie w biznesie  dyscyplinie i postawie przed- działający produkt? Czy chcemy, aż takiej biu-
siębiorczej (kreatywność). Jeżeli organizacja sku- rokratyzacji życia? Czy naszą firmę stać na za-
pia się tylko i wyłącznie na dyscyplinie, rezulta- trudnienie całego sztabu ludzi, którzy zajęliby się
tem może być zbytnia biurokratyzacja i stagnacja wdrażaniem modelu oraz kontrolą jakości proce-
jej procesów wytwórczych. Z kolei, przyjmowanie sów wytwórczych? .
samej postawy przedsiębiorczości, może spowo- Jako reakcja na tego typu podejścia wykształ-
dować, iż początkowy entuzjazm, związany z po- cił się inny nurt, który  na wszechobecną zmianę
wstaniem firmy, może nie zostać podtrzymany w  patrzy z zupełnie innej perspektywy. Nowe podej-
kolejnych latach jej funkcjonowania. Dobre orga- ście, określane mianem  agile , zachęca programi-
stów do porzucenia surowej dyscypliny, wynikają-
cej z konieczności ścisłego definiowania poszczegól-
Autor pracuje w Motorola Polska Electronics sp. z o.o.
nych procesów, i uznanie zmiany  jako czegoś na-
(krakowskie Centrum Oprogramoawnia Motoroli) na
turalnego i obecnego w cyklu życia projektu. Jest to
stanowisku inżyniera jakości. Od strony zawodowej in-
podejście, które charakteryzuje iteracyjny cykl życia
teresuje się problematyką doskonalenia procesu two-
projektu oraz bliskie zaangażowanie klienta w prace
rzenia oprogramowania w oparciu o Model CMMI, a tak-
zespołu projektowego.
że praktykami Agile Software Development. Prywatnie
Agile, jest tym wszystkim, co uosabia pojęcie kre-
lubi jazz i filozofię (głównie współczesną). W wolnych
chwilach fotografuje. atywności  spontanicznością, zwinnością (agility),
Kontakt z autorem: [e-mail]
otwartością na zmianę, a także odwagą w przekra-
czaniu stereotypów. Metody agile, mimo iż należą
56
www.sdjournal.org
Software Developer s Journal 10/2007
Extreme Programming (XP) i CMMI
obecnie do bodajże najbardziej popularnych tematów w dzie-  developerzy powinny implementować tylko to, co wyraża-
dzinie zarządzania przedsięwzięciami informatycznymi, mają ją aktualne potrzeby klienta; nie zaś to co, ich zdaniem, może
również swoich zagorzałych oponentów, szczególnie wśród być klientowi potrzebne.
dużych organizacji, które pytają:  Czy możemy zajmować się Komunikacja (ang. Communication). Dla Extreme Pro-
dużymi projektami bez kompleksowej dokumentacji? Czy mo- gramming, komunikacja stanowi kluczową wartość. Wie-
żemy sobie pozwolić na akceptację każdej zmiany, po dopie- le problemów związanych z życiem projektu wywodzi się
ro co zakończonych negocjacjach z klientem (często kilkumie- właśnie ze złej komunikacji. Czasem developer nie powia-
sięcznych)? . domi odpowiedniej osoby o zmianie, którą wprowadził w
Publikacja stanowi próbę pogodzenia tych dwóch, pozor- projekcie systemu; czasem menedżer nie zada develope-
nie odmiennych stanowisk:  lekkiego (Extreme Programming) rowi właściwego pytania. XP wpływa na poprawę komuni-
oraz  strukturalnego (CMMI), które podobnie jak  zaczerp- kacji w zespole przez stosowanie określonej grupy prak-
nięte ze starożytnej filozofii chińskiej  dwie pierwotne siły Yin tyk, których egzekwowanie nie jest możliwe bez właściwej
i Yang, z jednej strony są przeciwstawne, z drugiej zaś jednak komunikacji.
nigdy się nie wykluczają. Wszystko ma swoje przeciwieństwo, Sprzężenie zwrotne (ang. Feedback). Jest to integral-
jednak nigdy całkowite. Żadna rzecz nie jest nigdy w pełni Yin, na część każdej dwustronnej komunikacji. W XP feedback
ani całkowicie Yang. jest nam przekazywany cały czas. Możemy mówić o feed-
backu w skali  minut i dni . Programista przygotowuje ze-
Extreme Programming (XP) staw testów jednostkowych (unit tests), które testują logi-
Nie sposób mówić o Extreme Programming, nie wspomina- kę naszego systemu. W ten sposób otrzymuje, minuta po
jąc Kenta Becka, który uważany jest za twórcę tej metody. W minucie, wiadomość o tym, co działa z
le w jego systemie
swojej książce  Extreme Programming  Explained [K. Beck, i wymaga poprawy. Podobnie, szybką informację zwrotną
1999, 2004], definiuje ją jako:  lekką, wydajną, o niskim pozio- otrzymuje klient, który pisze kartę klienta (ang. user story)
mie ryzyka, elastyczną, naukową, i sprawiającą przyjemność  opisującą nową funkcjonalność, którą chciałby, żeby by-
metodę wytwarzania oprogramowania . Jest metodą zapro- ła dodana do jego systemu. Developer estymuje czas ja-
jektowaną dla małych i średnich zespołów projektowych, sta- ki poświęci na jej implementację, przez co klient otrzymuje
nowiąc tym samym pewnego rodzaju przeciwwagę dla trady- szybką informację zwrotną na temat możliwości implemen-
cyjnych podejść. tacji zaproponowanej przez niego zmiany. W Extreme Pro-
Podejście XP składa się z 3 podstawowych elementów: gramming możemy również mówić o feedback u w skali  ty-
wartości, zasad oraz praktyk. Wartości, stanowią  twardy godni i miesięcy . Tester wraz z klientem przygotowuje ze-
rdzeń tej metody, stanowiąc jednocześnie podstawę dla po- staw testów funkcjonalnych, których zadaniem jest spraw-
zostałych elementów, co obrazuje Rysunek 1. dzenie poprawności zaimplementowanych wymagań. W ten
Extreme Programming mówi o pięciu podstawowych war- sposób otrzymują konkretną informację na temat aktualne-
tościach, których nie może zabraknąć podczas realizacji pro- go stanu ich systemu.
jektów informatycznych: Odwaga (ang. Courage). Pozostaje w ściślej zależ-
Prostota (ang. Simplicity). Buduj system możliwie jak naj- ności z pozostałymi wartościami: prostotą, komunikacją
mniej skomplikowany. Tradycyjne metody wytwarzania opro- oraz sprzężeniem zwrotnym. Odwaga w XP, to umiejęt-
gramowania, zanim przystąpią do implementacji wymagań ność pro-aktywnego rozwiązywania problemów  śmia-
klienta, wcześniej  wszystko dokładnie planują (tzw.  up łość działania, oparta na solidnych podstawach, w posta-
front planning ). Można powiedzieć, iż klientowi na samym ci zautomatyzowanej uprzęży testowej (automatem  test
początku, dostarczona jest pewna gotowa wizja całości. W harness).
tego typu podejściach zmiana, w kolejnych fazach realiza- Respekt (ang. Respect). Wartość, która scala pozosta-
cji projektu, jest raczej mało prawdopodobna, czasem wręcz łe wartości. Respekt  to poważanie i szacunek, którym po-
niemożliwa. Zupełnie innego typu sytuacja ma miejsce w me- winni się wzajemnie obdarowywać członkowie zespołu pro-
todzie XP, dla której tak naprawdę najważniejsze są aktualne jektowego. Bez tej wartości, metoda Extreme Programming
potrzeby klienta. Bardzo dobrze oddaje to powiedzenie, któ- pozostaje tylko czczą ideą. Wartości XP stanowią pewne-
re określane jest w skrócie:  YAGNI (You aren t going need it) 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ć.
PRAKTYKI
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:
ZASADY
" humanitaryzm (Humanity)  Software jest tworzony przez
ludzi! Developerzy powinni mieć zapewnione wszystkie
WARTOŚCI
niezbędne warunki, które umożliwią im niczym nie skrępo-
waną pracę;
" ekonomia (Economics)  ktoś musi za wszystko zapłacić!
Rysunek 1.  Twardy rdzeń metody XP stanowią wartości,
które wspierane są przez zasady i praktyki Upewnij się czy to, co robisz ma jakąś wartość biznesową,
Software Developer s Journal 10/2007 www.sdjournal.org
57
Inżynieria
oprogramowania
czy realizuje cele biznesowe oraz czy odpowiada na po- kość często skutkuje póz
niejszym dostarczeniem produk-
trzeby rynku; tu w ręce klienta;
" wzajemna korzyść (Mutual Benefit)  każde działanie, po- " kroki dziecka (Baby Steps)  wprowadzanie dużych
winno przynosić korzyść wszystkim tym, którzy się w nie- zmian jednocześnie, może być bardzo niebezpieczne!
go angażują! Tworząc oprogramowanie, używaj tylko tych Dlatego wprowadzaj je małymi krokami (na wzór kroków
praktyk developerskich, z których będziesz miał pożytek, dziecka);
podobnie jak i Twój klient; " akceptowana odpowiedzialność (Accepted Responsi-
" powielanie dobrych rozwiązań (Self-Similarity)  powielaj bility)  odpowiedzialność nie może zostać przypisa-
dobre rozwiązania wszędzie tam, gdzie jest to możliwe; na, należy ją zaakceptować! Jeśli ktoś chce Ci ją przy-
" doskonalenie (Improvement)  nie ma doskonałego proce- pisać, Ty musisz sam zdecydować, że wez
miesz ją na
su! Nie ma doskonałego projektu systemu! Wykonuj swoją Siebie.
pracę tak dobrze jak tylko potrafisz. Wyciągaj wnioski z te-
go, co zrobiłeś z
le, by móc to doskonalić; Cykl życia projektów XP
" różnorodność (Diversity)  jednorodne zespoły projek- Do istoty projektów informatycznych, realizowanych w du-
towe są mało efektywne! Zespoły powinny składać się chu XP, należy bliska współpraca świata biznesu (klient)
z osób o zróżnicowanych umiejętnościach i zaintereso- ze światem techniki (developer). Klient jest aktywnie zaan-
waniach. Umożliwia to spoglądanie na problemy projek- gażowany na każdym etapie prac projektowych. Czuwa, by
towe z różnych perspektyw. Zespoły potrzebują różno- dostarczany produkt posiadał tylko jemu właściwą wartość
rodności; biznesową (Rysunek 2).
" refleksja (Reflection)  dobre zespoły, nie tylko wykonują Wydawać by się mogło, iż nie ma tutaj nic nowego.
swoją pracę, ale zastanawiają się także nad tym  jak to Realizacja każdego projektu informatycznego skupia się
robią oraz  dlaczego . Otwarcie mówią o swoich niepowo- przecież na tworzeniu i dostarczaniu produktu, który po-
dzeniach; siada określoną wartość w oczach naszego klienta. Róż-
" przepływ (Flow)  dostarczaj małe fragmenty działającego nica polega jednak na tym, iż w XP, proces ten przebie-
software u, angażując się we wszystkie aktywności deve- ga bardzo szybko, z dużą częstotliwością. Zespół dostar-
loperskie równocześnie; cza małe fragmenty funkcjonalności z dużym rozmachem
" okazja (Opportunity)  ucz się na błędach! Traktuj każdy (w skali minut, godzin, czy dni)  w odróżnieniu od podejść
napotkany problem, jako środek do pogłębienia własnej tradycyjnych, gdzie klient niekiedy zmuszony jest czekać
wiedzy, budowania dojrzałych relacji w zespole, a także długie miesiące, a nawet lata, żeby jego produkt został do-
doskonalenia wytwarzanego produktu, nad którym pra- starczony. Cykl życia projektu w XP składa się z 5 faz, co
cujesz; obrazuje Rysunek 3.
" nadmiarowość (Redundancy)  o ile redundancja sama w
sobie może być nieekonomiczna, o tyle nie należy z niej Eksploracja
rezygnować, jeżeli służy właściwym celom! Problemy, któ- Jest to etap, w którym po raz pierwszy dociera do nas,
re są krytyczne z punktu widzenia developmentu, zawsze czym tak naprawdę mamy się zajmować. Klient dostarcza
rozwiązuj na kilka możliwych sposobów; tzw.  vision statement  wysokopoziomowy opis systemu,
" niepowodzenie (Failure)  nie wiesz, którą z trzech możli- który mamy zaprojektować. Zazwyczaj liczy on nie więcej
wych implementacji danej funkcjonalności wybrać? Zaim- niż 30 słów (niewiele), i stanowi podstawę do stworzenia
plementuj każdą z osobna, nawet, jeżeli istnieje ryzyko, że  Metafory systemu (ang. system meaphor)  praktyki, któ-
wszystkie zakończą się niepowodzeniem. Czy niepowo- rej celem jest wyjaśnienie zasad działania systemu za po-
dzenie jest nieekonomiczne? Nie, jeżeli niesie ze sobą pe- mocą krótkich, prostych historii. Metafora stanowi namiast-
wien ładunek wiedzy; kę czegoś, co w tradycyjnych podejściach określane jest
" jakość (Quality)  dopinguj projekty do dostarczania pro- mianem  architektury systemu .
duktów o najwyższej jakości! Tempo prac projektowych George Lakoff i Mark Johnson, w napisanej wspólnie
nie wzrośnie, jeżeli założysz ich niższą jakość. Niższa ja- 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
Klient
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
Budowanie wartości Definicja wartości
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,
Developer
ż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-
Rysunek 2. Klient definiuje wartość, developer ją tworzy i
dostarcza nia na proces obsługi klienta jak na pracę linii montażowej.
58
www.sdjournal.org
Software Developer s Journal 10/2007
Extreme Programming (XP) i CMMI
Tego typu metafora od razu nam sugeruje, iż rozwiązanie Faza planowania
każdego problemu, zgłoszonego wcześniej przez klienta, Podstawowym narzędziem, służącym do planowania pro-
będzie kilkuetapowe. Pracę techników oraz osób pracują- jektów informatycznych w metodzie XP jest praktyka, któ-
cych w dziale obsługi klienta można przyrównać do pra- rej nazwa może być nieco kontrowersyjna zwłaszcza, je-
cy osób przy stanowiskach montażowych. Widzimy, iż ta- śli chodzi o menedżerów  mianowicie  Zabawa w plano-
ka metaforyczna wizualizacja pracy systemu znacznie uła- wanie (ang. planning game). Jest to kolejna z praktyk XP,
twia nam jego zrozumienie  zwłaszcza, jeśli chodzi o na- w której znakomicie uwidacznia się bliskie zaangażowanie
szego klienta. Metafora wyzwala całe mnóstwo pytań, któ- i współpraca klienta jako pełnowartościowego członka ze-
re w normalnych okolicznościach nigdy by się nie pojawiły. społu projektowego. Celem  Zabawy w planowanie jest po
Po pierwsze, jaka jest przepustowość systemu? (ilość pro- prostu  zaplanowanie poszczególnych prac projektowych.
blemów rozwiązywanych/godzinę). Co stanie się ze zgło- Developerzy spotykają się z klientem przy wspólnym sto-
szonym problemem, gdy osiągnie on ostatni etap linii mon- le. Na stole leżą rozrzucone małe karteczki (najczęściej
tażowej? Być może system powinien wysyłać jakąś infor- samoprzylepne)  user stories. Mimo, iż całość przypomi-
mację zwrotną do klienta? I tak dalej, i tak dalej. na trochę scenę z filmu  Back to the future , ma jednak nie-
Z fazą eksploracji, związana jest inna, ważna praktyka zwykłą skuteczność. Oczywiście, zamiast używania ręcz-
XP tzw.  Karty klienta (ang. user stories)  bardzo lakoniczne nie zapisanych karteczek, można używać innych narzędzi,
opisy poszczególnych funkcjonalności systemu (najczęściej na przykład aplikacji webowych  decyzja zależy od kre-
zapisane na małych karteczkach), przygotowywane przez atywności zespołu.
klienta lub jego reprezentanta. Ron Jeffries, w jednym ze
swoich artykułów, wskazuje na 3 ważne aspekty user stories Iteracje
( Essential XP: Card, Conversation, Confirmation. XP W metodzie XP, cykl tworzenia oprogramowania podzielony
Magazine, 30.08.2001): jest na tzw. wydania (ang. releases), które z kolei składają się
z iteracji (Rysunek 4).
" karta (ang. Card)  krótki opis historii, zapisany ręcznie na Typowy czas trwania jednej iteracji to 1  4 tygodni.
małej karteczce; Należy zauważyć, iż początkowe iteracje zazwyczaj pla-
" konwersacja (ang. Conversation)  rozmowa na temat user nuje się tak, aby skupiały się na architekturze poszczegól-
story (pozwala uzyskać więcej informacji); nych komponentów, stanowiąc tzw. baseline  linię bazo-
" potwierdzenie (ang. Confirmation)  testy, które stanowią wą dla powstającego systemu. Tego typu iteracje, niekiedy
świadectwo tego, iż funkcjonalność, którą zażyczył sobie określane są jako zero business value  gdyż tak napraw-
od nas klient została poprawnie zaimplementowana. dę, z punktu widzenia klienta, nie dostarczają żadnej war-
tości biznesowej. Kolejne, wnoszą już więcej treści w po-
Z kolei Rachel Davies (The Power of Stories XP 2001. Sardy- wstający produkt. Musimy pamiętać, iż to klient decydu-
nia, 2001) trafnie zauważył, iż karty klienta bardziej reprezen- je o tym, co powinno się w nich znalez
ć. To on jest  moto-
tują jego wymagania, aniżeli ich dokumentację  i tak powin- rem zmiany  którą w tym kontekście należy właściwie ro-
niśmy je właśnie traktować. User stories stanowią tylko krótki zumieć. Extreme Programming posługuje się techniką time
zapis danej funkcjonalności; szczegóły wypracowywane są w boxingu  zakres prac w ramach poszczególnych iteracji
rozmowach i potwierdzane w testach. nie może ulec zmianie. Innymi słowy  robimy to, co zapla-
W fazie eksploracji, klient przygotowuje zestaw wyso- nowaliśmy. Technika time boxingu jest znaną i powszech-
kopoziomych user stories, które następnie wykorzystywa-
ne są przez developerów do estymowania czasu ich imple-
2. PLANOWANIE
mentacji. Estymaty na tym, początkowym etapie, posiada-
Piorytetyzacja
prac projektowych,
ją dość duży stopień ogólności, niemniej jednak wyznacza-
przygotowanie
ją kierunek prac w kolejnych cyklach życia projektu. W XP,
roboczej wersji
do najczęściej używanych technik estymacyjnych należą
planu
techniki oparte na metodzie Wideband Delphi, którą Barry
W. Boehm opisał w swojej książce  Software Engineering
1. EKSPLORACJA 3. ITERACJA
Economics (Englewood Cliffs, NJ: Prentice  Hall, 1981).
Inicjalizacja prac
Oczywiście nie wykluczone jest zastosowanie innych tech-
Planowanie
projektowych,
iteracji,
nik, bardziej zaawansowanych  o tym jednak decyduje już
przygotowanie
testowanie
sam zespół. wymagań klienta,
i development
prototypowanie
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- 5. PODTRZYMANIE 4. PRODUKCJA
su zajmie nam implementacja określonego rozwiązania.
Podtrzymywanie, Dostarczenie
Wówczas przygotowujemy jego prototyp, który pozwoli nam
poprawki (patches) software'u do
oszacować rzeczywisty czas, jaki będzie potrzebny na jego udoskonalenia środowiska
(enhancements) klienckiego
development. Warto dodać, iż kod, który powstaje na skutek
tej praktyki, jest zwykle odrzucany i nie nadaje się do po-
nownego użytku. Rysunek 3. Cykl życia projektu XP
Software Developer s Journal 10/2007 www.sdjournal.org
59
Inżynieria
oprogramowania
nie stosowaną metodą planowania i monitorowania projek- gląda trochę inaczej, niż w przypadku tradycyjnych po-
tów informatycznych. Każdy time box ma określony, stały dejść kaskadowych, gdzie faza testów następuje zaraz
czas trwania  zwykle od 1 do 4 tygodni i  po ustalonym po fazie kodowania. W XP testy powstają zanim powsta-
wcześniej terminie dostarczenia  produkt musi znalez
ć nie kod. Developerzy przygotowują zestaw testów jed-
się w rękach klienta. Tak więc, gdy zaczniemy już prace w nostkowych (ang. unit tests), których zadaniem jest prze-
ramach danej iteracji, zakres prac nie powinien ulec zmia- testować wszystko, co tak naprawdę może się zepsuć.
nie. Time boxing chroni nas przez klientami niezdecydowa- Służą temu specjalne szkielety testowe (np. JUnit, CPPU-
nymi. Każda iteracja  to proces w pełnym tego słowa zna- nit, VBBUnit). Testy są zautomatyzowane, dzięki czemu
czeniu. Ma swoje wejścia, wyjścia  posiada swój rytm, co mogą być uruchamiane w sposób ciągły, po każdej inte-
obrazuje Rysunek 5. gracji. Takie podejście jest niezwykle elastyczne, klient
Iteracje, to ten moment w życiu projektu, kiedy ma miej- jak i developerzy otrzymują praktycznie ciągłą informację
sce prawdziwy development. Na początku każdej iteracji zwrotną o swoim produkcie.
klient, bądz
jego reprezentant przygotowuje zestaw user Praktyka testów w XP sprzyja zwiększeniu zaufania
stories, które powinny zostać zaimplementowane. Develo- developerów do ich kodu, stanowiąc jednocześnie podsta-
perzy rozbijają je na mniejsze taski (zadania), które z kolei wę do zastosowania praktyki refaktoringu  ulepszania ko-
przydzielane są do poszczególnych programistów. Praca du bez zmiany jego funkcjonalności. W odróżnieniu od tra-
jest estymowana i priorytetyzowana. Developerzy pracu- dycyjnych podejść, gdzie refaktoring był raczej uzależnio-
ją w parach, siedząc przy jednej stacji roboczej, używając ny od wolnego czasu developerów, w XP proces ten za-
tylko jednej klawiatury i jednej myszki. Kodują, dyskutują, chodzi w trakcie całego procesu tworzenia oprogramowa-
uczą się wspólnie rozwiązywać problemy   co dwie gło- nia. Dlaczego? Bo kod, który otrzyma nasz klient, powi-
wy, to nie jedna . I nie chodzi tu o patrzenie sobie na ręce, nien być możliwie jak najmniej skomplikowany  ekstremal-
wytykanie błędów  ale o autentyczną pracę, wspólną od- nie prosty.
powiedzialność za kod. W metodzie XP  system stanowi Kod dostarczony przez programistów jest integrowa-
własność wszystkich, którzy nad nim pracują. Ideę tę wy- ny. W XP mówi się o praktyce  Ciągłej integracji (ang.
raża kolejna praktyka XP, określana mianem  Kolektywnej continuous integration). Moduły poszczególnych funkcjo-
własności kodu (ang. collective ownership). Jest to zupeł- nalności poddawane są procesowi integracji tak często,
nie przeciwne podejście do tego, które spotykamy w trady- jak to tylko możliwe (raz dziennie, co kilka godzin). Prak-
cyjnych metodach tworzenia oprogramowania, gdzie ma- tycznie ciągłe testy regresyjne testują działanie syste-
my do czynienia z  instytucją wręcz!  właściciela (owner) mu po to, żeby sprawdzić czy nowo wprowadzone zmia-
danego modułu, bądz
obszaru funkcjonalnego. Zapewnia ny nie spowodowały pojawienia się niepożądanych skut-
to oczywiście duże poczucie bezpieczeństwa i zaufania, z ków ubocznych.
drugiej jednak strony prowadzi do niepotrzebnych frustra- Na końcu każdej iteracji klient wykonuje testy akcepta-
cji  kluczowi właściciele kodu nagle znikają (urlop, choro- cyjne (ang. acceptance tests), które wcześniej sam przygo-
ba, zmiana pracy)  wszyscy stajemy się zakładnikami ko- tował. Stanowią one swoistą bramę jakości (ang. quality ga-
du, który w dodatku nie jest naszą własnością. te), która zadecyduje o kształcie kolejnej iteracji. Testy, któ-
Programowanie w parach, współużytkowanie kodu, zna- re nie przejdą w danej iteracji muszą zostać poprawione w
komicie koresponduje z kolejną praktyką XP  wspólny kolejnej.
 Standard kodowania (ang. coding standard): zbiór wska-
zówek i zasad, mających na celu ujednolicenie wyglądu pi- Produkcja (ang. Productionizing)
sanego przez nas kodu (format, struktura kodu, nazewnic- Jest to moment, w którym prace w ramach danego rele-
two, komentarze). Posiadanie wspólnego standardu kodo- ase u są finalizowane, produkt jest weryfikowany (testy ak-
wania odgrywa niebagatelną rolę zwłaszcza, gdy kod pisa- ceptacyjne) i przygotowywany do oddania w ręce klienta.
ny jest w parach. To, jaką postać przyjmie faza produkcji, zależy tak napraw-
Zanim jednak developerzy zaczną kodować  wcze- dę od bardzo wielu czynników zarówno tych, które znajdu-
śniej przygotowują zestaw testów. Testowanie w XP wy- 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-
Bispolacja
szej iteracji. Praktyka jednak pokazuje, iż tak naprawdę
pierwsza iteracja stanowi jedynie tło dla całego develop-
Release
mentu, i z punktu widzenia klienta posiada zerową wartość
biznesową, bez której jednak trudno byłoby nam mówić o
Iteracja 1 Iteracja 2
dalszym, sensownym rozwijaniu systemu.
Build Build Build Build Build Build
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:
Podtrzymanie Produkcja
l
system wdrażany jest na zasadzie  wielkiego wybuchu
(Big Bang). Wdrożenie przebiega w sposób mało skompli-
Rysunek 4. Release y w XP składają się z iteracji kowany, ryzyko jest duże;
60
www.sdjournal.org
Software Developer s Journal 10/2007
Extreme Programming (XP) i CMMI
zwala stwierdzić, jaką gęstość błędów posiada napisany
Zaznaczamy iterację
przez nas kod.
W XP, podstawową miarą są tzw. story points. Z ich udzia-
Iteracja
łem powstaje metryka prędkości projektu (ang. velocity), któ-
ra określa, ile story points zostało zaimplementowanych w ra-
Estymacja &
Wybór
Priorytetyzacja Testy/Build
mach danej iteracji.
use stories
pracy
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
Powtarzamy aż do zakończenia iteracji
innego zaś idealny tydzień pracy (ang. ideal week). Wyda-
Release
je się jednak, iż najlepszym określeniem pasującym do tej
miary jest, zaproponowane przez Joshua ę Kerievsky ego 
Rysunek 5. Cykl życia iteracji w XP
Nebuluous Units of Time (NUT) , a więc  Mgliste Jednost-
l
funkcjonalności dostarczane są małymi partiami, co jest ki Czasu (J. Kerievsky, extremeprogramming@yahoogro-
możliwe gdy system da się podzielić na małe logiczne ups.com, 05. 08. 2003).
fragmenty, ryzyko jest niskie; W oparciu o story points i metrykę velocity przygotowywa-
l
stary i nowy system pracują przez pewien okres czasu ne są tzw. wykresy spalania (ang. burndown charts) dla po-
równolegle. Niestety, mimo niskiego ryzyka związanego z szczególnych iteracji oraz release ów. Pozwalają one dokład-
tym podejściem, koszt całego przedsięwzięcia przemawia nie śledzić zachowanie projektu, przewidywać pewne zdarze-
zdecydowanie przeciwko takiemu rozwiązaniu; nia, szacować ich rozmiar. Metryki są bardzo cennym narzę-
l
wdrażany system nie ma swojego poprzednika. Może- dziem, również w tradycyjnych metodach tworzenia oprogra-
my mieć do czynienia z jakąś nową linią biznesową, mowania.
wspierająca funkcjonowanie określonego software u 
sytuacja wymarzona; poziom ryzyka jest najniższy ze Podsumowanie
wszystkich omawianych przypadków, poza tym nie ma- Artykuł jest pierwszą częścią cyklu trzech artykułów, poświę-
my żadnych problemów związanych z integracją ze sta- conych porównaniu dwóch metod tworzenia oprogramowania
rym systemem.   lekkich , reprezentowanych przez podejście określane mia-
nem Extreme Programming oraz  tradycyjnych , których istotę
Podtrzymanie (ang. Maintenance) oddaje model CMMI.
Po wdrożeniu, przychodzi czas na podtrzymanie (ang. ma- Publikacja omawia podstawowe zasady, jakimi kieru-
intenance). Używając praktyki metafory, system w tej fa- je się jedna z bardziej znanych metod agile'owych  Extre-
zie, można przyrównać do dziecka w początkowym okre- me Programming. Została ona powiązana z tym wszyst-
sie jego życia. Wdrożenie systemu jest jak stawianie pierw- kim, co uosabia pojęcie  kreatywności  spontaniczno-
szych kroków, które początkowo są bardzo niepewne i ro- ścią, zwinnością (agility), otwartością na zmianę, a także
dzice muszą wciąż podtrzymywać swoją pociechę, usuwać odwagą w przekraczaniu stereotypów. Trzy podstawowe
niebezpieczne przedmioty z drogi, etc.  by mogło się swo- elementy metody XP  wartości, zasady oraz praktyki de-
bodnie poruszać, by przypadkiem się nie wywróciło. Taka veloperskie  przedstawione zostały z perspektywy pięciu
właśnie jest faza podtrzymania  pełna troski o pierwsze faz cyklu życia Extreme Programming: Planowania, Eks-
kroki systemu. ploracji, Iteracji, Produkcji oraz Podtrzymania (ang. Main-
W tej fazie doskonalimy i optymalizujemy software, któ- tenance). Dodatkowo, wyszczególniono zbiór podstawo-
ry został dostarczony w ręce klienta. Jest to czas wprowadza- wych metryk, którymi posługują się projekty realizowane
nia poprawek, różnego rodzaju patchy, a także upgrade u sys- w duchu XP.
temu. W XP jest to o tyle przyjazne, że mamy zautomatyzo- Druga część prezentowanego cyklu, która ukaże się
waną platformę testową, która umożliwia swobodne ekspery- w kolejnym numerze pisma, omówi tradycyjne meto-
mentowanie na kodzie. dy tworzenia oprogramowania. Wykorzystują one najczę-
ściej kaskadowy cykl życia projektu (wymagania/projekt/
Metryki w XP implementacja), a ich cechą charakterystyczną jest precy-
XP jest metodą, która podobnie jak tradycyjne podejścia zyjnie zdefiniowany proces, który podlega ciągłemu dosko-
tworzenia oprogramowania, posługuje się metrykami. Me- naleniu. Wyrażają to wszystko, co zawiera się w pojęciu
tryki służą do monitorowania projektu, śledzenia i plano-  dyscypliny . Tradycyjne podejścia, określane niekiedy mia-
wania poszczególnych jego prac. Są nieocenione w proce- nem strukturalnych, omówione zostaną na przykładzie Ca-
sie szacowania wielkości poszczególnych iteracji. Pozwala- pability Maturity Model Integration (CMMI)  wcześniej zna-
ją nam zmierzyć określone własności software u, (gęstość nego jako Capability Maturity Model (CMM).
błędów, wielkość kodu), projektu (czas trwania, koszty), a W kolejnej, trzeciej, części cyklu  przedstawiona zo-
także procesu tworzenia oprogramowania (skuteczność stanie próba pogodzenia tych dwóch, pozornie odmien-
usuwania błędów). Metryki tworzone są za pomocą okre- nych, stanowisk:  lekkiego (Extreme Programming) oraz
ślonych miar. I tak na przykład metryka, określająca gę-  strukturalnego (CMMI). Praktyki metody XP zestawione
stość błędów w napisanym przez nas kodzie składa się z zostaną z obszarami procesowymi (ang. Process Areas)
dwóch miar: liczby błędów oraz liczby linii kodu (KLOC), modelu CMMI. Siła  kreatywności zmierzy się z siłą  dys-
do których błędy zostały wprowadzone. Ich stosunek po- cypliny . n
Software Developer s Journal 10/2007 www.sdjournal.org
61