Inżynieria
oprogramowania
Extreme Programming i CMMI
 kreatywność czy dyscyplina? (Cz. 3)
Mariusz Chrapko
ojęcie balansu, czy też balansowania kojarzy Różnica celów
nam się przede wszystkim z próbą utrzyma- Podstawowym celem projektów agile owych jest
Pnia równowagi, np. przez linoskoczków w cyr-  szybkość oraz  błyskawiczne reagowanie na zmia-
ku. Zresztą  balansem nazywany jest również drąg, nę . Pierwsza z 12 zasad Manifestu Agile (htttp://
za pomocą którego linoskoczek wspomnianą rów- www.agilemanifesto.org), głosi: Naszym najwyższym
nowagę próbuje utrzymać. Niemniej jednak, pojęcie celem jest zaspokojenie oczekiwań klienta przez szyb-
to, posiada jeszcze głębsze, filozoficzne znaczenie kie i ciągłe dostarczanie mu działającego software u .
 poszukiwanie umiaru.  Umiar stanowi syntezÄ™ sta- Projekty agile owe zazwyczaj nie przeprowadzajÄ… ana-
rożytnej mądrości greckiej, która swój typowy wyraz lizy ROI (ang. Return on Investment) po to, żeby usta-
znalazła w pismach wielu poetów, filozofów (Pitago- lić najbardziej opłacalną alokację zasobów, z punktu
ras, Platon, Arystoteles), a która wielokrotnie wska- widzenia dostarczanego produktu. Wolą raczej szyb-
zywała na drogę środka, niczego za dużo, słuszną ko tworzyć software, określając na bazie doświadcze-
miarę jako regułę działania moralnego: regułę, któ- nia z poprzednich iteracji, co tak naprawdę  opłaca
ra była wzorcem helleńskiego sposobu życia, od- się (wartość biznesowa) dodać w kolejnej. Przypomi-
czuwania. na to trochÄ™ znanÄ… maksymÄ™: Laissez faire, laissez pas-
Celem prezentowanego cyklu artykułów, jest pró- ser!  dajcie wolność zarobkowania i handlu, która wy-
ba wypośrodkowania, pomiędzy dwiema dość skraj- rażała podstawową zasadę gospodarki liberalnej, gło-
nymi sposobami tworzenia oprogramowania  agile- szÄ…cÄ… swobodÄ™ gospodarczÄ… jednostek, bez ingerencji
 owym i tradycyjnym. Wypośrodkowanie, nie oznacza państwa. W przypadku agile a, taka postawa jest o ty-
jednak przeciętności, co więcej, jest nawet jej przeci- le godna polecenia, iż znakomicie minimalizuje wszel-
wieństwem.  Słuszny środek znajduje się zdecydowa- kie straty, wynikające z tzw. złych inwestycji  realizo-
nie ponad skrajnościami i stanowi wręcz ich przezwy- wanych na podstawie błędnych założeń, analiz. Z dru-
ciężenie, a więc jest pewnego rodzaju  szczytem , któ- giej jednak strony, brak analizy zysku i strat, przy oka-
ry w wielu wypadkach oznacza zwycięstwo rozumu, zji alokacji zasobów projektowych, może mieć nega-
nad tym, co irracjonalne. tywny wpływ na dalszą realizację projektu.
Kolejną cechą charakterystyczną projektów agi-
Próba sił le owych jest przyjęcie postawy reaktywnej w trakcie
Próba znalezienia równowagi pomiędzy światem me- prac projektowych, co wyraża jedno ze stwierdzeń Ma-
tod agile owych a tradycyjnym developmentem nie jest nifestu Agile   reagowanie na zmianÄ™, ponad trzyma-
sprawÄ… Å‚atwÄ…. Wynika to poniekÄ…d z samej natury two- niem siÄ™ planu . Postawa szybkiej reakcji ma bardzo
rzenia software u, a także z dużej różnorodności me- dużo zalet, zwłaszcza w dobie, kiedy wymagania ryn-
tod, rozwijanych w ramach dwóch prezentowanych po- ku i technologie zmieniają się w zawrotnym tempie. Wy-
dejść. W trzeciej, ostatniej części prezentowanego cy- obraz
my sobie jednak hipotetycznÄ… sytuacjÄ™, kiedy tra-
klu,  zderzone zostaną ze sobą podstawowe wartości fi nam się tzw.  niezdecydowany klient , który  tak na-
i założenia metod agile owych z tymi, które dominują w prawdę  do końca nie wie, jak powinien wyglądać je-
świecie tradycyjnych sposobów tworzenia oprogramo- go produkt  wówczas  reaktywne zarządzanie może
wania. Praktyki Extreme Programming, zestawione zo- skutkować niepotrzebnym chaosem.
staną z obszarami procesowymi modelu CMMI. Poka- Zupełnie inny jest świat celów, który przyświeca
zane zostanie to, co łączy i to, co dzieli  świat swo- tradycyjnym metodom tworzenia oprogramowania.
bodnego, nieskrępowanego programowania, zaproszo- Tam liczy się stabilizacja i przewidywalność istnieją-
ny zostanie do świata dyscypliny i rygoru procesów. cych procesów w organizacji. Szczegółowe plany pro-
Czy zostanie przyjęty? jektowe, rozbudowane strategie weryfikacji i walidacji,
dodatkowo wspomagajÄ… te cele. Doskonalenie proce-
sów odbywa się w oparciu o różnego rodzaju mode-
Autor pracuje w Motorola Polska Electronics Sp. z o.o.
le, których znakomitym reprezentantem jest CMMI. Za-
(krakowskie Centrum Oprogramowania Motoroli) na sta-
chowanie procesów, analizowane jest za pomocą me-
nowisku inżyniera jakości. Od strony zawodowej inte-
resuje się problematyką doskonalenia procesu tworze- tod analizy statystycznej, ich przebieg jest szczegóło-
nia oprogramowania w oparciu o model CMMI®, a także wo Å›ledzony i mierzony. Wszystkie odchylenia od przy-
praktykami Agile Software Development. Prywatnie lubi
jętych linii bazowych (ang. baseline) są mierzone i na
jazz i filozofiÄ™. W wolnych chwilach fotografuje.
bieżąco korygowane, przez co zapewniona jest prze-
Kontakt z autorem: [e-mail]
widywalność i powtarzalność istniejących procesów w
organizacji.
24
www.sdjournal.org
Software Developer s Journal 2/2008
Extreme Programming i CMMI
W odróżnieniu od projektów agile owych, tradycyjne meto- magania  ujawniają się niejako w trakcie samej realizacji pro-
dy tworzenia oprogramowania charakteryzuje postawa proak- jektu. Oczywiście ma to swoje dobre strony. Bardzo często ma-
tywna. Miary i analizy działań projektowych, pozwalają wycho- my przecież do czynienia z projektami (zwłaszcza w dużych fir-
dzić naprzeciw wszelkim potencjalnym niezgodnościom. Jest to mach), które powstają we współpracy z kilkoma zespołami, roz-
znakomita sytuacja dla bardzo stabilnego środowiska. Nakłady mieszczonymi w różnych lokalizacjach na świecie. Wówczas
na działania proaktywne oraz szczegółowe planowanie przed bardzo często wymagania tworzone są przez oddzielny, spe-
rozpoczęciem projektu, niewątpliwie sprzyja stabilizacji i prze- cjalnie dedykowany do tej pracy zespół, zajmujący się tylko i
widywalności procesów wytwórczych. Sytuacja jednak kompli- wyłącznie tą dziedziną. Stąd zdarza się, iż wymagania nie są do-
kuje się, kiedy mamy do czynienia z niestabilnym środowiskiem starczane na czas, co  rzecz zrozumiała  często frustruje ze-
projektowym, o wysokim współczynniku nieprzewidywalności i społy developerskie. Wówczas iteracyjne, a co za tym idzie, in-
zmiany. Wówczas próba stabilizacji i utrzymania przewidywalno- krementalne dostarczanie wymagań może okazać się świetnym
ści może wymuszać dodatkowe koszty. rozwiązaniem, oczywiście przy właściwym procesie zarządza-
nia zmianą wymagań.
Rozmiar projektów Metody typu  plan-driven (wiedzione planem) z kolei naj-
Projekty agile owe znakomicie sprawdzają się w małych i śred- lepiej sprawdzają się w sytuacjach, gdy proces zbierania i
nich zespołach, pracujących zazwyczaj nad małymi aplikacja- analizy wymagań zamyka się przed oficjalnym rozpoczęciem
mi. Wspominał o tym Kent Beck, jeden z twórców metody Extre- prac nad designem systemu. Stąd też w tym przypadku wszel-
me Programming:  Wielkość projektu nie pozostaje bez znacze- ki brak stabilności wymagań wpływa negatywnie na cały póz
-
nia. Najprawdopodobniej nie jest możliwe stosowanie podejścia niejszy development. Statystycznie rzecz biorąc, metody plan-
XP w projektach liczących stu developerów, nawet pięćdziesię- driven, dopuszczają zmiany wymagań w granicach 1% w ska-
ciu, czy czterdziestu. Dwudziestu również dziesięć to wartość li miesiąca. W przeciwnym wypadku firma zmuszona jest pła-
optymalna (K. Beck, Extreme Programming, Boston: Addison- cić niezwykle duże koszty, wynikające z konieczności utrzy-
Wesley, 1999). Panuje powszechna zgoda, iż wymiana informa- mania, wcześniej zdefiniowanych, procesów związanych z za-
cji oraz efektywne zarządzanie projektem agile owym ma sens, pewnieniem jakości i spójności zbieranych wymagań, a także
kiedy liczy on nie więcej niż 40 programistów. Oczywiście zda- ich testowalnością.
rzają się przypadki projektów, liczących nawet do 250 osób. Ta-
kim przykładem może być 250 osobowy projekt prowadzony w Relacje z klientem
Singapurze, który zajmował się stworzeniem aplikacji bankowej. Agile Software Development kładzie duży nacisk na bliską
Jednak menedżer tego projektu, po jego zakończeniu stwierdził, współpracę z klientem. Klient jest wręcz równoprawnym człon-
iż nie podjąłby się takiego przedsięwzięcia po raz drugi (J. Hi- kiem zespołu projektowego. W praktyce, perspektywa klienta,
ghsmith, Agile Software Development Ecosystems, Boston: Addi- reprezentowana jest przez różnego rodzaju analityków bizne-
son-Wesley, 2002). Stosowanie metod agile owych, w tego typu sowych, którzy posiadają bardzo dobrą znajomość wymagań
projektach, po prostu nie ma sensu. Jednak do dzisiaj najwięk- końcowych użytkowników systemu. Można powiedzieć, iż sta-
szy projekt, który używał metody SCRUM, liczył aż 800 deve- nowią pewnego rodzaju medium pomiędzy zespołem develo-
loperów. Projekt ten prowadziła firma IDX, zajmująca się usłu- perów, a klientem końcowym. Dlatego sukces projektów agi-
gami z zakresu udzielania informacji medycznej (J. Highsmith, le owych zależy w dużym stopniu od charakteru tej współpra-
Agile Software Development Ecosystems, Boston: Addison-We- cy  na ile przedstawiciel klienta będzie w stanie odzwiercie-
sley, 2002). dlić jego rzeczywiste potrzeby. Zawsze przecież może gdzieś
Doświadczenie pokazuje, iż prowadzenie projektów agile o- wkraść się błąd, dwuznaczność, niezrozumienie. Dlatego też,
wych w dużych, bardzo złożonych projektach, ma sens o tyle, sukces tych projektów, w dużym stopniu zależy od właści-
o ile development wspomagany jest elementami tradycyjnych wych relacji z klientem.
metod tworzenia oprogramowania, takimi jak: plany projekto- TrochÄ™ inaczej sytuacja wyglÄ…da w przypadku tradycyj-
we, specyfikacja wymagań etc. Wymaga tego poniekąd bar- nych metod tworzenia oprogramowania. Tutaj, punkt nacisku
dzo złożona, wielowymiarowa rzeczywistość interakcji zacho- położony jest na właściwe sformułowanie kontraktu, pomiędzy
dzących pomiędzy poszczególnymi komponentami prowadzo- klientem i developerami/firmą. Na tym właściwie kończy się ta
nych przedsięwzięć. współpraca (oczywiście, wykluczają sytuacje nadzwyczajne).
Tradycyjne metody tworzenia oprogramowania doskonale Metody plan-driven niezwykle pieczołowicie konstruują umo-
sprawdzają się właśnie przy okazji realizacji kompleksowych wy z klientem. Muszą zaangażować wszelkie zdolności  wizjo-
projektów informatycznych. Szczegółowe plany projektowe, do- nerskie , żeby niejako na papierze przewidzieć wszelkie poten-
kumentacja, zarządzanie procesami sprzyjają lepszej komunika- cjalne problemy oraz ich możliwe rozwiązania, zanim faktycznie
cji i koordynacji prac poszczególnych zespołów. Podstawowym wystąpią w trakcie realizacji projektu. Ponieważ klient nie jest
zagrożeniem takiej postawy jest oczywiście zbytnia biurokraty- członkiem zespołu projektowego i nie może zmieniać wymagań
zacja życia, dlatego szczególnie ważny jest tutaj zdrowy rozsą- w trakcie realizacji projektu, kontrakt powinien zawierać tak du-
dek oraz wspomniana na początku  zasada złotego środka. W żo szczegółów, jak to tylko możliwe. Pozytywną stroną tego po-
przeciwnym wypadku, może mieć to bardzo negatywne skutki dejścia jest fakt, iż developerzy przez cały okres trwania pro-
dla całej organizacji. jektu dokładnie wiedzą, co mają robić; także klient wie, czego
może się spodziewać po zakończeniu projektu. Z drugiej jed-
Åšrodowisko nak strony, prace nad precyzyjnym sporzÄ…dzeniem kontraktu,
Metody agile owe najlepiej sprawdzają się w bardzo  burzliwym , chęć uwzględnienia wszystkich niezbędnych detali, mogą po-
szybko zmieniającym się środowisku projektowym, gdzie wy- wodować niepotrzebne opóz
nienia na samym starcie; co wiÄ™-
Software Developer s Journal 2/2008 www.sdjournal.org
25
Inżynieria
oprogramowania
cej, zmiany w trakcie realizacji przedsięwzięcia, czynią wręcz ją wiedzą, która nie wymaga złożonej dokumentacji. Niemniej
niemożliwymi. jednak, pokładanie całego zaufania firmy w założenie, iż wie-
Podstawa budowania zaufania w relacjach z klientem, w dza ukryta jest konsystentna we wszystkich zespołach pro-
obu podejściach, oparta jest na różnych zasadach. W projek- jektowych  należy traktować jako wysoce ryzykowne. Ryzy-
tach agile owych, zaufanie budowane jest w oparciu o dostar- ko zwiększa się jeszcze bardziej, gdy mamy do czynienia z du-
czanie klientowi fragmentów działającego software u. Co ja- żą rotacją w tych zespołach, co jest przecież rzeczą dość czę-
kiś czas klient dostaje mały fragment swojego produktu, testu- stą w organizacjach.
je go  widzi, że developerzy faktycznie pracują. W przypadku Im większa organizacja, tym sposób przekazywania wie-
tradycyjnych metod, zaufanie budowane jest w oparciu o doj- dzy ukrytej staje się coraz bardziej nieefektywny. Należy tu-
rzałość procesów wytwórczych danej organizacji. Z kolei, bar- taj rozważyć, jak bardzo zwiększa się liczba relacji zależno-
dzo często gwarantem dojrzałości procesów jest legitymowa- ści pomiędzy poszczególnymi pracownikami. Dlatego meto-
nie się przez firmę implementacją określonych celów i praktyk, dy plan-driven, tak wielką wagę przykładają do wiedzy  jaw-
obecnych w modelach dojrzałości procesów, takich jak CMMI. nej , formalnej  a więc jasno sprecyzowanej i usystematyzo-
Klient decyduje się na podpisanie kontraktu z firmą, której pro- wanej, którą można udokumentować. Jednak i tutaj pojawiają
cesy znajdują się na określonym poziomie dojrzałości, bo wie, się przeszkody. Informacje znajdują się w wielu miejscach i w
że stanowi to określoną, solidną podstawę budowania zaufa- różnych formach, nie zawsze jest też oczywiste, gdzie daną in-
nia. Podejście to niesie ze sobą jednak duże pokłady ryzyka. formację można znalez
ć.
Zaufanie oparte na certyfikatach i ludziach, posiada zawsze Należy jednak pamiętać, iż ścisły rozdział wiedzy  jawnej
wiele ograniczeń. od  ukrytej , w żadnym z omawianych podejść, nie ma charakte-
ru absolutnego. Kod z
ródłowy czy przypadki testowe, które po-
Planowanie i kontrola wstajÄ… w projektach agile wych jak najbardziej kwalifikujÄ… siÄ™ do
Cytowany już Kent Beck, powiedział kiedyś, że metodę XP uznania ich jako wiedzę  jawną . Podobnie, w przypadku metod
można scharakteryzować jako  planning-driven , co należa- plan-driven, komunikacja interpersonalna, indywidualna wymia-
łoby przetłumaczyć jako  wiedzioną planowaniem . Planowa- ny doświadczeń  wspierają rozumienie dokumentacji proceso-
nie w projektach agile owych zajmuje około 20% ich czasu i wej. Metody agile owe dokumentują niezbędne minimum (user
jest wynikiem zaangażowania się całego zespołu oraz dziele- stories, plan projektu).
nia siÄ™ tzw.  wiedzÄ… ukrytÄ… (ang. tacit knowledge). Jest to wie- Tradycyjne metody tworzenia oprogramowania cierpiÄ… z
dza, z której istnienia wprawdzie zdajemy sobie sprawę i któ- kolei bardzo często na syndrom, nazwijmy to  niepewnego de-
rą wykorzystujemy w codziennym działaniu, ale nie potrafimy velopera . Oto bowiem, z jednej strony, dość duży nacisk kła-
jej do końca określić, a przez to wszelkie próby jej sformali- dą na szczegółową dokumentację wszystkich procesów, za-
zowania są niezwykle trudne. Więcej szczegółów na ten temat chodzących na poziomie organizacji i poszczególnych pro-
można znalez
ć w książce autora pojęcia  wiedzy ukrytej Mi- jektów, z drugiej zaś  dają ludziom bardzo cenne narzędzie
chaela Polanyi, The Tacit Dimension, Routledge & Kegan Paul w postaci  tailoringu  a więc przykrywania istniejących pro-
Ltd, London 1967. cesów do zindywidualizowanych potrzeb konkretnego projek-
Wiedza ukryta, jest tym rodzajem wiedzy, który doskona- tu. Narzędzie to świetnie wykorzystywane jest przez tzw.  de-
le sprawdza się w małych zespołach agile owych, które bar- veloperów ekspertów , których wiedza i doświadczenie są na
dzo efektywnie mogą dzielić się tym rodzajem wiedzy, która nie tyle duże, iż bez problemu potrafią dopasować istniejący gor-
jest przecież wiedzą udokumentowaną. Niestety, wraz ze wzro- set wymagań procesowych, do własnych potrzeb, które skądi-
stem organizacji ten sposób przekazywania wiedzy staje się co- nąd zawsze posiadają rozsądne uzasadnienie biznesowe. Nie-
raz bardziej nieefektywny. Dlatego metody plan-driven tak duży stety, w wielu projektach, bardzo często, zwłaszcza wśród me-
nacisk kładą na dokumentowanie planów projektowych, w du- nedżerów, pojawiają się osoby, które mimo swoich ogromnych
żej mierze, w celu usprawnienia komunikacji projektowej. Trady- kompetencji oraz ogromnego doświadczenia/ekspertyzy, wo-
cyjne metody tworzenia oprogramowania mają ściśle zdefinio- lą spełnić wymagania wszystkich istniejących procesów w or-
wany proces planowania prac projektowych (tworzenie harmo- ganizacji, po to tylko, ażeby się za nimi schować, przyjmując
nogramu, określenie punktów milowych, szacowanie wielkości w ten sposób postawę asekuracyjną na wypadek, gdyby pro-
prac, kosztów etc.) oraz prac związanych z rozwijanym produk- jekt zakończył się niepowodzeniem. Takie podejście, skutkuje
tem (wymagania, opis architektury systemu, design, implemen- najczęściej ogromną frustracją ze strony pozostałych człon-
tacja, testy). Poszczególne plany, których przygotowanie zwią- ków zespołu projektowego i mnożeniem ton nikomu niepo-
zane jest z konkretnÄ… fazÄ… prac projektowych  Å‚Ä…czÄ… siÄ™, two- trzebnej dokumentacji.
rząc integralną całość.
Wymagania, design i testy
Komunikacja w projekcie Wśród dyskusji na temat różnic pomiędzy agilem, a tradycyj-
Komunikacja w projektach agile owych w dużej mierze opar- nymi metodami tworzenia software u, najczęściej wskazuje się
ta jest na dzieleniu się, wspomnianą wcześniej, wiedzą  ukry- na aspekty techniczne. Po pierwsze  sposób zbierania wyma-
tą . Wiedza ta, rozwijana jest w takich praktykach agile owych gań. Jak już zostało wcześniej powiedziane, w projektach agile-
jak: zabawa w planowanie (ang. planning game), programowa-  owych sposób zbierania i tworzenia wymagań ma charakter bar-
nie w parach, czy retrospekcje. Wiedza ukryta odsłania się w dzo nieformalny. Słowem-kluczem jest tutaj pojęcie  kart klien-
codziennej pracy projektowej. Programiści, pracując nad kon- ta (ang. user stories), a więc bardzo lakonicznych opisów po-
kretnymi zadaniami, w ramach konkretnej iteracji, wymienia- szczególnych funkcjonalności systemu (najczęściej zapisanych
ją swoje doświadczenia, wzajemnie obdarowywują się swo- na małych karteczkach), powstałych w wyniku współpracy klient
26
www.sdjournal.org
Software Developer s Journal 2/2008
Extreme Programming i CMMI
 developer. To, które wymagania zostanie zaimplementowane Metody plan-driven zapobiegają póz
nemu znajdowaniu błę-
w każdej kolejnej iteracji, w dużej mierze decyduje klient. Deve- dów w kodzie, poprzez jego ciągłe inspektowanie. Jest to prak-
loperzy określają jedynie, na ile dana karta może zostać zaim- tyka, mająca na celu wykrycie jak największej ilości błędów, a
plementowana. Zawsze jednak, jest to przedmiotem negocjacji, także ich naprawę, jeszcze w trakcie fazy kodowania. Polega na
w które każdorazowo zaangażowane są obie strony: kliencka i przeglądzie kodu przez niewielkie grupy programistów (zwykle
developerska. 4-5 osób) zanim kod zostanie objęty kontrolą wersji i przetesto-
Åšwiat tradycyjnych metod tworzenia oprogramowania, pod wany. W tradycyjnych metodach tworzenia oprogramowania, in-
względem zbierania i dostarczania wymagań, funkcjonuje zu- spekcje zazwyczaj są stosowane w odniesieniu do wszystkich
pełnie inaczej. Tutaj wszystko ma charakter wysoce sformalizo- artefaktów projektowych, takich jak: wymagania, design, plany/
wany. Wymagania są wersjonowane, a ich zmiany skrupulatnie strategie testowania, przypadki testowe, a także do dokumen-
śledzone. Służą temu różnego rodzaju narzędzia, które pozwa- tów procesowych. Pełnią rolę tzw.  bram jakości (ang. quali-
lają należycie nimi zarządzać, przez cały czas trwania projek- ty gates). Projekt nie może opuścić jednej fazy i przejść do na-
tu. Wspomnę tutaj chociażby o takich komercyjnych systemach stępnej, bez uprzedniego przeinspektowania wszystkich jej ar-
jak RequisitePro firmy Rational, CaliberRM firmy TBI, czy DO- tefaktów. A więc, nie możemy opuścić fazy designu i przejść
ORS firmy Telelogic. do fazy kodowania, bez uprzedniego przeglÄ…du projektu nasze-
Mówiąc o różnicach technicznych, warto również wspomnieć go systemu. Podobnie w przypadku fazy kodowania  nie mo-
o kwestiach związanych z tworzeniem designu systemu. Świat żemy rozpocząć testów, bez uprzednich przeglądów kodu. Ta-
metod agile owych zaleca maksymalną prostotę  pojawia się kie podejście umożliwia bardzo wczesne wychwytywanie błę-
praktyka określana mianem simple design, która zaleca budo- dów w procesie developmentu software u. Więcej na temat pro-
wanie systemu możliwie jak najmniej skomplikowanego, co zna- cesu inspekcji w artykule: M. Chrapko, Inspekcje kodu jako sku-
komicie oddaje powiedzenie, określane w skrócie  YAGNI (You teczna metoda weryfikacji kodu, Software Developer s Journal,
aren t going need it)  developerzy powinni implementować tylko nr 3/2007 (147).
to, co wyrażają aktualne potrzeby klienta, nie zaś to, co ich zda-
niem, może być klientowi potrzebne. Oczywiście przekłada się Czynnik ludzki
to na tworzenie designu systemu. Przemawiają za tym dwa argu- Dotykamy obszaru, który jest bodajże najbardziej newralgiczny
menty. Pierwszy, zakłada mniejszy koszt związany z reworkiem z punktu widzenia tematu niniejszej publikacji.  Lekkie metody-
wszelkich zmian w trakcie trwania developmentu (ciągła refak- ki, o czym była mowa wcześniej, stosunkowo duży nacisk kładą
toryzacja wymagań, kodu, przypadków testowych). Drugim ar- na ciągłą obecność i aktywne zaangażowanie klienta, bądz
je-
gumentem, przemawiającym za stosowaniem tej praktyki, jest go reprezentanta (analityk biznesowy), w prace zespołu projek-
tempo prac developerskich zorientowanych wokół poszczegól- towego. Owo zaangażowanie sprawia, iż z jednej strony uczest-
nych iteracji. Nasz system zmienia się tak szybko, że jakiekol- niczy on w planowaniu i priorytetyzowaniu prac projektowych,
wiek próby  przygotowania go do przyjęcia w przyszłości in- przygotowuje testy akceptacyjne, opowiada na wszystkie pyta-
nych funkcjonalności mogłoby okazać się zabójcze dla całego nia programistów, związane z tworzonym produktem  z dru-
przedsięwzięcia. giej zaś, bardzo często zdarza się, że firmy oddelegowują tzw.
Zupełnie inaczej sytuacja wygląda w metodach plan-dri-  zbędnych pracowników do pracy właśnie w projektach agile-
ven. Pomijając fakt, iż fazy architektury i designu są szczegóło-  owych, nie mając przy tym świadomości, jak bardzo duże nie-
wo dokumentowane, to jednak chyba najważniejszą rzeczą, jest sie to ryzyko.
ogromny wysiłek, wkładany w to, aby system był przygotowany
do przyjęcia wszelkich możliwych zmian w przyszłości. Dobrym
Wysoka
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ę-
Metody Agile
cy do 12, w ciągu 5 lat. Więcej szczegółów na ten temat można
znalez
ć 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-
Metody Plan-Driven
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óz
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 Niska
piszemy test, a potem kod, który ten test spełnia. Ma to wiele
Lekka Ciężka
Optymalizacja
(proces, dokumentacja)
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-
Rysunek 1. Znaczenie czynnika ludzkiego w metodach agile i
ny do osiągnięcia danej funkcjonalności), a także umożliwia peł- plan-driven. y
ródło: J. Highsmith, Agile Software Development
Ecosystems, Boston: Addison-Wesley, 2002
ną automatyzację testów.
Software Developer s Journal 2/2008 www.sdjournal.org
27
Adaptacja
(umiejętności "miękkie")
Inżynieria
oprogramowania
Metody plan-driven angażują klienta jedynie na początku prac ciągłej (ang. continuous). Przypominają one trochę dwa odręb-
projektowych  w momencie zbierania i definiowania wymagań ne widoki (ang. view) w bazie danych, są czymś w rodzaju wir-
oraz w momencie przygotowywania i zawierania kontraktu. Jed- tualnej tabeli. PozwalajÄ… firmie na 22 obszary procesowe spo-
nak, w odróżnieniu od metod agile owych, nie jest to obecność glądać z dwóch odmiennych perspektyw/reprezentacji. Z jed-
permanentna. nej strony, akcentują tylko te procesy wytwórcze, które wyma-
Obie metody wymagają jednak zaangażowania, właściwych i gają poprawy i dostarczają niezbędnych środków do ich rozwo-
kompetentnych osób. W projektach agile owych, oprócz okre- ju (reprezentacja ciągła); z drugiej zaś, umożliwiają organiza-
ślonych umiejętności technicznych, niezbędne są pewne pre- cję, stopniowe, krok po kroku, doskonalenie procesów, dostar-
dyspozycje  miękkie , a więc zdolność do komunikacji, pracy czając jej gotowej, kilku stopniowej ścieżki rozwoju (reprezen-
w grupie, twórczego rozwiązywania problemów, co wynika ze tacja stała). Takie podejście, umożliwia pracę nad poprawą pro-
specyfiki obecnych w nich praktyk. Nie sposób programować cesów wytwórczych, zarówno tym organizacjom, które posia-
w parach, nie posiadając zdolności pracy w grupie czy komu- dają dobrą znajomość swoich procesów, jak i firmom, które do-
nikacji. Oczywiście w tradycyjnych metodach tworzenia opro- piero zaczynają swoją przygodę z ich poprawą, startując bar-
gramowania cechy te są równie ważne, jednak nie krytyczne. W dzo często od zera.
tradycyjnych metodykach, powodzenie projektów nie zależy od Model CMMI pełni więc rolę swoistego drogowskazu na
posiadania określonych cech interpersonalnych developerów. drodze doskonalenia procesów tworzenia oprogramowania w
Dobrze zdefiniowany i zarządzany proces, jego powtarzalność organizacji  mówi  co robić (praktyki i cele), aby jej proces
i przewidywalność są gwarantem sukcesu projektów. Oczywi- był faktycznie dojrzały. Metoda XP natomiast, stanowi kon-
ście nie jest też tak, iż w projektach tych pracują roboty, które kretną propozycją implementacji niektórych praktyk, obec-
w cieniu swoich kubików, w odizolowaniu od świata, tworzą ma- nych w modelu CMMI. Tutaj odsłania się możliwość synergii
łe fragmenty kodu. omawianych podejść. Kiedy zestawimy praktyki Extreme Pro-
gramming z obszarami procesowymi modelu CMMI, nie od-
Kultura organizacji kryjemy sprzeczności  w niektórych przypadkach możemy
Dotykamy tutaj elementu, którego rola jest krytyczna w poszu- mówić co najwyżej o sytuacji, kiedy pewne obszary proceso-
kiwaniu równowagi pomiędzy omawianymi podejściami. Kultura we pozostają neutralne względem praktyk Extreme Program-
projektów agile owych opiera się na wolności  swobodzie w de- ming (ich ewentualna implementacja na gruncie XP nie stano-
finiowaniu i organizacji pracy. Jest to kultura swobodnego, nie- wiłaby więc sprzeczności); bądz
skrajnie możliwe (prawdopo-
skrępowanego działania. W projektach agile owych każda oso- dobieństwo ich wprowadzenie jest bardzo niskie, choć oczy-
ba dokładnie wie, co należy do jej obowiązków. wiście nie wykluczone). Można, więc całkiem zasadnie stwier-
W tradycyjnych metodach, programiści czują się najlepiej, dzić, iż relacja zakresu obszarów procesowych modelu CMMI
kiedy ich role i zakres obowiązków zostały jasno i czytelnie zde- względem konkretnych praktyk metody XP jest relacją  zbio-
finiowane (polityki, procesy, procedury). W ten sposób, każdy ru względem jego podzbioru. Wszystkie praktyki Extreme Pro-
dokładnie wie, jakie są względem niego oczekiwania oraz za wy- gramming stanowią  ucieleśnienie większości praktyk obec-
tworzenie, jakiego fragmentu produktu jest on odpowiedzialny. nych w modelu CMMI.
Kultura organizacji jest tym elementem, który najbardziej opie- Dla potrzeb tej publikacji, praktyki metody XP zostaną ze-
ra się wprowadzaniu zmian. Oczywiście nie są one wykluczone, stawione z obszarami procesowymi modelu CMMI w czterech
niemniej jednak wymagają dużo cierpliwości i czasu. kategoriach reprezentacji ciągłej: Zarządzanie projektem (ang.
Project Management), Inżynieria (ang. Engineering), Wsparcie
XP i CMMI (ang. Support) oraz ZarzÄ…dzanie procesem (ang. Process Ma-
Metoda XP oraz Model CMMI to pozornie dwa różne światy, któ- nagement).
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-
5
sów wytwórczych w organizacji. Składa się z 22 obszarów pro-
OPTYMALIZUJ
CY
cesowych (ang. Proces Areas), które tworzą dobre praktyki z
zakresu inżynierii oprogramowania. Należy pamiętać, iż model
4
CMMI nie jest w żadnym wypadku tworem intelektualnym, stwo-
ZARZ
DZANY
rzonym przez środowisko akademickie, choć oczywiście posia- ILOŚCIOWO
da ono niezaprzeczalny wkład w jego rozwijanie. Jest to jednak
3
model, o którego powstaniu zadecydowała przede wszystkim
ZDEFINIOWANY
praktyka  Departament Obrony Stanów Zjednoczonych (ang.
2
United States Department of Defense) chciał mieć narzędzie do
oceny swoich kontraktorów, chciał współpracować z firmami,
ZARZ
DZANY
którym można zaufać. Dlatego powstał model, posiadający po-
1
dwójne zastosowanie, z jednej strony stanowi on doskonałe na-
rzędzie oceny poziomu dojrzałości procesów wytwórczych da-
POCZ
TKOWY
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 Rysunek 2. Reprezentacja modelu CMMI. Reprezentacja stała
28
www.sdjournal.org
Software Developer s Journal 2/2008
DOJRZAA
OŚĆ PROCESÓW
Extreme Programming i CMMI
Zarządzanie projektem śledzenie tzw.  prędkości (ang. velocity) projektu  określającej,
W obszarach procesowych CMMI, należących do tej katego- jak wiele kart klienta udało się zespołowi zaimplementować w ra-
rii, znalazły się: mach danej iteracji. Metryka ta jest dość precyzyjnie śledzona w
metodzie Extreme Programming. Szacowana prędkość projektu,
" planowanie projektu (ang. Project Planning)  szacowanie porównywana jest z wartościami rzeczywistymi; analizowany jest
projektu (wielkość, koszty, czasu trwania); definiowaniu je- całkowity wysiłek zespołu względem danej iteracji (ang. cumula-
go cyklu życia (kaskadowy, spiralny, przyrostowy etc.); two- tive story point chart), a także ile pracy pozostało do wykonania
rzenia dokumentacji projektowej; sporzÄ…dzanie planu; pod koniec trwania danej iteracji (ang. iteration burndown chart).
" monitoring i kontrola (ang. Project Monitoring and Control) Również obszar  Zintegrowanego zarządzania projektem znaj-
 monitorowanie prac projektowych pod kątem zgodności duje swoje odzwierciedlenie w praktykach agile owych. XP po-
z przyjętym planem (śledzenie harmonogramu, wydatków, siada ściśle zdefiniowany iteracyjny cykl życia oprogramowania
dostępności zasobów, ryzyk); zarządzanie procesem defi-  estymaty oraz plany poszczególnych wydań i iteracji, wykorzy-
niowania i rozwiązywania akcji korekcyjnych, powstałych na stywane są do planowania kolejnych aktywności projektowych;
skutek odchyleń od przyjętego planu; wraz z planowaniem projektu, tworzone jest odpowiednie środo-
" zarządzanie dostawcami (ang. Supplier Agreement Mana- wisko pracy (narzędzia, krytyczne zasoby); definiowane są pod-
gement)  określenie jakiego typu produkty i usługi, zwią- stawowe metryki (np. velocity) oraz sposób, w jaki będą mierzone
zane z realizacją danego projektu, będą realizowane przez i przechowywane. W procesie planowania poszczególnych itera-
zewnętrznych bądz
wewnętrznych dostawców; definiowa- cji, metody agile owe stosują podejście określane mianem risk-dri-
nie kryteriów wyboru dostawców; sporządzanie umów z do- ven iterative development. Oznacza to, iż przy planowaniu począt-
stawcami; ewaluacja dostarczanych produktów, zwłaszcza kowych iteracji brane są pod uwagę przede wszystkim te elemen-
tych, które mają znaczenie krytyczne dla powodzenia reali- ty systemu, które odznaczają się dużym poziomem ryzyka wzglę-
zowanego projektu; organizowanie procesu tranzycji dostar- dem pozostałych. Mimo, że Extreme Programming nie posługuje
czanego produktu/usługi (szkolenia, konsultacje, support); się zaawansowanym planem zarządzania ryzykiem, niemniej jed-
" zintegrowane zarzÄ…dzanie projektem (ang. Integrated Project nak, risk-driven iterative development stanowi pewnÄ… jego namiast-
Management)  zdefiniowanie procesów, które będą wyko- kę. Jeśli chodzi obszar  Zarządzania dostawcami , metoda XP po-
rzystywane w trakcie realizacji projektu, w zależności od je- zostaje względem niego raczej neutralna. Natomiast, w przypadku
go specyfiki, cyklu życia (np. proces estymowania, zarzą-  Ilościowego zarządzania procesem , implementacja obecnych w
dzania ryzykiem, inspekcji/przeglądów, testowania etc.); pla- tym obszarze praktyk, można uznać za skrajnie możliwą.
nowanie projektu w oparciu o wcześniej zdefiniowane pro-
cesy; przygotowanie środowiska projektowego (narzędzia, Inżynieria
sprzęt, manuale, support  wszystko, co jest niezbędne do Drugi zbiór obszarów procesowych modelu CMMI, zebranych
efektywnie wykonywanej pracy w ramach projektu); integra- wokół kategorii:  Inżynierii , również posiada wiele punktów
cja planu projektowego z wszystkimi innymi planami, które wspólnych z metodą XP. Znalazły się tutaj:
bezpośrednio go dotyczą (plany zapewnienia jakości, zarzą-
dzania konfiguracjÄ…, ryzykiem); " zarzÄ…dzanie wymaganiami (ang. Requirements Management)
" zarządzanie ryzykiem (ang. Risk Management)  analiza i  osiąganie wspólnego zrozumienia definiowanych wymagań
ocena ryzyka w projekcie; identyfikacja możliwych z
ródeł (klient  projekt); zarządzanie zmianami wymagań; śledze-
ryzyka; szacowanie prawdopodobieństwa jego wystąpie- nie poziomu ich implementacji oraz pokrycia testami; iden-
nia oraz wpływu na projekt; definiowanie poziomów ryzy- tyfikowanie wszelkich rozbieżności pomiędzy pracą projek-
ka; przygotowywanie planu działań zapobiegawczych; tu, a przyjętymi wymaganiami;
" ilościowe zarządzanie projektem (ang. Quantitative Project " rozwój wymagań (ang. Requirements Development)  zbie-
Management)  definiowanie mierzalnych celów projektu ranie wymagań od klienta; definiowanie wymagań produktu;
(np. pożądany poziom kosztów jakości, kosztów złej jakości, analiza i walidacja wymagań;
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-
5
nie akcji korekcyjnych w przypadkach odchyleń od przyję-
tych celów; stosowanie metod statystycznej analizy proce-
4
sów do śledzenia ich zachowań.
3
Metoda XP w pełni realizuje wymagania związane z kategorią
 Planowania projektu . Praktyki zwiÄ…zane z  zabawÄ… w planowa- 2
nie (ang. planning game);  krótkimi wydaniami (ang. short rele-
ases), przekładające się na planowanie poszczególnych wydań 1
oraz iteracji; estymowanie wielkości projektu poprzez szacowa-
nie pracy związanej z implementacją poszczególnych kart klien-
Obszar 1 Obszar 2 Obszar 3 etc.
ta (ang. user stories)  stanowią urzeczywistnienie zaleceń mode-
PROCES
lu CMMI w tym zakresie. Kolejny obszar   Monitoring i kontrola ,
jest również doskonale spełniony w metodzie XP m.in. poprzez Rysunek 3. Reprezentacja modelu CMMI. Reprezentacja ciągła
Software Developer s Journal 2/2008 www.sdjournal.org
29
WYDOLNOŚĆ
Inżynieria
oprogramowania
" rozwiązania techniczne (ang. Technical Solution)  ewaluacja rzędzia); definiowanie baseline ów; śledzenie tzw.  żądań
i wybór odpowiedniego projektu systemu (w oparciu o jego zmian (ang. change request)  sugestii modyfikacji produk-
wymagania); sporządzenie szczegółowego design u systemu tu roboczego, bądz
zgłoszenia wykrytych w nim defektów;
(opis architektury, projekt systemu); implementacja przyję- przyprowadzanie audytów konfiguracji;
tych rozwiązań; " zapewnienie jakości procesu i produktu (ang. Process and
" integracja produktu (ang. Product Integration)  integracja Product Quality Assurance)  obiektywna ewaluacja pro-
komponentów produktu w integralną całość; przygotowanie cesów w organizacji (raporty); przeprowadzanie audytów
środowiska integracyjnego; definiowanie procedur integra- projektowych/organizacyjnych; identyfikowanie i dokumen-
cyjnych (dokumentacja, kryteria); dostarczenie produktu; towanie niezgodności/odstępstw od zdefiniowanych pro-
" weryfikacja (ang. Verification)  sprawdzenie produktu, pod cesów w firmie; dostarczanie informacji zwrotnej członkom
kątem jego zgodności z przyjętą specyfikacją; wybór pro- zespołu projektowego oraz menedżerom; właściwe adreso-
duktów roboczych, które zostaną poddane procesowi we- wanie niezgodności audytowych oraz akcji korekcyjnych;
ryfikacji; przygotowanie środowiska umożliwiającego wery- " miary i analizy (ang. Measurement and Analysis)  definio-
fikację; metody weryfikacji: inspekcje/przeglądy artefaktów wanie metryk projektowych/organizacyjnych; sporządzenie
projektowych, testy; stworzenie procedur i kryteriów wery- procedur, określających jak zbierać metryki projektowe; wy-
fikacyjnych (dokumentacja); ewaluacja uzyskanych rezulta- korzystywanie narzędzi do zbierania metryk; analiza uzyska-
tów (raporty); nych rezultatów; podejmowanie działań korekcyjnych;
" walidacja (ang. Validation)  sprawdzenie, czy to, co zostało " analiza decyzyjna (ang. Decision Analysis and Resolution) 
zdefiniowane w wymaganiach, jest zgodne z oczekiwaniami zdefiniowanie kryteriów stosowania procesu analizy decy-
użytkownika; przeprowadzanie testów w środowisku rzeczy- zyjnej w organizacji; przygotowanie odpowiednich procedur
wistym naszego klienta, bÄ…dz
zbliżonym do niego; przygoto- (dokumentacja); wybór metod ewaluacji możliwych rozwią-
wanie środowiska umożliwiającego walidację (np. symulatory, zań; ocena ryzyka wybranych rozwiązań;
wykwalifikowani pracownicy, odpowiednie środowisko testo- " analiza przyczyn i działania prewencyjne (ang. Causal Ana-
we, narzędzia); stworzenie procedur i kryteriów walidacyjnych lysis and Resolution)  identyfikacja przyczyn wykrytych de-
(dokumentacja); ewaluacja uzyskanych rezultatów (raporty). fektów oraz wszelkich innych problemów, pojawiających się
w trakcie życia projektu; podejmowanie akcji prewencyj-
Dwa pierwsze obszary procesowe, dotyczÄ…ce zarzÄ…dzania wy- nych; weryfikacja poprawnego wykonania akcji.
maganiami, metoda XP odzwierciedla poprzez posługiwanie się
kartami klienta w definiowaniu i zarządzaniu wymaganiami oraz W tej kategorii o komplementarności można mówić jedynie w
jego aktywne zaangażowanie w trakcie całego developmen- przypadku obszaru związanego z zarządzaniem konfiguracją
tu. Klient jest obecny na każdym etapie cyklu życia projektu. oprogramowania. W metodzie XP kontrola zmian produktów
Uczestniczy w jego planowaniu, dokonuje priorytetyzacji funk- roboczych dokonuje się za sprawą praktyki kolektywnej wła-
cjonalności, a także odpowiada na wszystkie pytania programi- sności kodu (ang. collective ownership), krótkich wydań (ang.
stów. Obszar  Rozwiązania techniczne modelu CMMI jest po- small releases), a także ciągłej integracji (ang. continuous inte-
wiązany z praktyką metafory w obrazowaniu działania systemu gration). Należy zaznaczyć, iż kolektywna własność kodu mo-
(odpowiednik architektury), zasadą maksymalnej prostoty w de- że być nieco problematyczna w przypadku dużych systemów,
finiowaniu projektu systemu (ang. simple design), a także prak- które wymagają bardziej sformalizowanych kanałów komunika-
tyką refaktoryzacji kodu. Integracja produktu, wspierana jest cji, by skutecznie zapobiegać ewentualnym problemom związa-
przez praktykę ciągłej integracji (ang. continuous integration), nym z zarządzaniem konfiguracją oprogramowania. Pozostałe
obecną w podejściu XP. Komponenty systemu, integrowane są obszary procesowe, poza  Analizą decyzyjną , pozostają neu-
z dużą częstotliwością, nawet do kilku razy dziennie. W meto- tralne względem podejścia XP. Analiza decyzyjna, obejmująca
dzie XP, szczególnie mocno reprezentowane są dwa ostatnie ob- analizę i wspomaganie procesu podejmowania decyzji, jest ra-
szary z omawianej grupy:  Walidacja oraz  Weryfikacja . Wyko- czej mało prawdopodobna (skrajnie możliwa) na gruncie XP,
nywanie testów jednostkowych, akceptacyjnych, regresyjnych, choć nie wykluczona.
wspomaganych przez automatyzacjÄ™ procesu testowania, sta-
nowią  twardy rdzeń tej metody. Obszary te, dodatkowo wspie- Zarządzanie procesem
rane są przez praktykę programowania w parach (ang. pair pro- Wreszcie ostatnia grupa obszarów procesowych modelu CMMI,
gramming), która w niektórych przypadkach wydaje się być du- skupionych wokół kategorii  Zarządzania procesem . Znalazły
żo silniejszym narzędziem, aniżeli inspekcje kodu  ze względu się tutaj takie obszary jak:
na jej duży ładunek prewencyjny: wspólne programowanie zapo-
biega wprowadzaniu błędów do powstającego kodu, które nor- " koncentracja na procesie organizacyjnym (ang. Organiza-
malnie wykrywane są podczas inspekcji. tional Process Focus)  przeprowadzanie ocena dojrzało-
ści istniejących procesów w organizacji (zdefiniowanie za-
Wsparcie kresu, metod oraz kryteriów oceny); analiza zachowań pro-
Kolejny zbiór procesów, skupiony jest wokół kategorii:  Wspar- cesów pod kątem możliwości ich doskonalenia; planowanie
cia . Znajdują się tutaj: działań związanych z poprawą procesów organizacyjnych;
wdrażanie i ewaluacja nowych procesów w organizacji;
" zarzÄ…dzanie konfiguracjÄ… (ang. Configuration Management) " definicja procesu organizacyjnego (ang. Organizational
 identyfikacja produktów poddanych kontroli wersji; usta- Process Definition)  definiowanie procesów w organiza-
nowienie systemu zarządzania konfiguracją (procedury, na- cji; określenie ich wzajemnych relacji; definiowanie możli-
30
www.sdjournal.org
Software Developer s Journal 2/2008
Extreme Programming i CMMI
wych cyklów życia projektów (kaskadowy, spiralny, przyro- projekcie, czy też nową technologią, która jest wykorzystywana.
stowy etc.); ustanowienie kryteriów przykrawania procesów Podobnie rzecz się ma z drugim obszarem procesowym   In-
(ang. tailoring); ustanowienie ogólnodostępnego repozyto- nowacje i wdrożenia . Metoda XP jest metodą otwartą na wdra-
rium wszystkich procesów w firmie (ang. Process Assets Li- żanie nowych, innowacyjnych rozwiązań, zarówno w aspekcie
brary); a także miejsca przechowywania metryk; technologii jak i samego procesu tworzenia oprogramowania 
" szkolenia organizacyjne (ang. Organizational Training)  iden- mających wpływ na jakość dostarczanego produktu.
tyfikacja i analiza potrzeb szkoleniowych na poziomie ca-
łej organizacji; przygotowanie planu szkoleń (jego regular- Podsumowanie
na aktualizacja); wybór dostawców szkoleń (wewnętrzni, ze- Dyscyplina jest nieodzownym elementem wielu przedsięwzięć,
wnętrzni); umożliwienie pracownikom dostępu do materia- niekoniecznie informatycznych. Muzycy, sportowcy muszą pod-
łów szkoleniowych (wewnętrzne biblioteki, zakup potrzeb- dawać się wielogodzinnym treningom, żeby osiągnąć sukces.
nych książek, materiały video, płyty CD, e-książki); dostar- Jednak, czymże byłaby dyscyplina bez kreatywności? W pierw-
czenie szkoleń (szkolenia wyjazdowe, wewnętrzne organizo- szej części prezentowanego cyklu, zacytowana została książka
wane przez innych pracowników, e-learning); ewaluacja do- Jim Collins Good to Great (Collins J. 2001, New York: Harper-
starczanych szkoleń; Collins), gdzie mowa jest o dwóch czynnikach, które decydu-
" wydajność procesu organizacyjnego (ang. Organizational ją o sukcesie w biznesie  dyscyplinie i postawie przedsiębior-
Process Performance)  śledzenie zachowań procesów w czej (kreatywność). Jeżeli organizacja skupia się tylko i wyłącz-
organizacji; zbieranie i analiza metryk procesowych; spo- nie na dyscyplinie, rezultatem może być zbytnia biurokratyzacja
rządzanie na ich podstawie tzw. linii bazowych (ang. basli- i stagnacja jej procesów wytwórczych. Z kolei przyjmowanie sa-
ne), które będą wyznaczały możliwe odchylenia od standar- mej postawy przedsiębiorczości, może spowodować, iż począt-
dowych zachowań procesów; wykorzystywanie narzędzi sta- kowy entuzjazm, związany z powstaniem firmy, może nie zostać
tystycznej analizy procesów; podtrzymany w kolejnych latach jej funkcjonowania. Dobre or-
" innowacje i wdrożenia (ang. Organizational Innovation and ganizacje to takie, w których wymiar dyscypliny jest tak samo
Deployment)  doskonalenie istniejących procesów i stoso- obecny jak wymiar postawy przedsiębiorczej  na zasadzie rów-
wanych technologii w organizacji; zbieranie i analiza propo- nouprawnienia.
nowanych rozwiązań; uruchamianie projektów pilotażowych Celem prezentowanych artykułów nie była chęć wtłocze-
wdrażających te rozwiązania; ewaluacja rezultatów. nia wybranych praktyk agile owych do świata tradycyjnych me-
tod tworzenia oprogramowania. Chodziło raczej o znalezienie
Obszary te mają bodajże najmniej wspólnego z podejściem pewnego rodzaju balansu/równowagi pomiędzy dwoma, dość
Extreme Programming. Dzieje się tak, ponieważ metody agile o- odmiennymi sposobami tworzenia software u. Wiele punktów
we zorientowane są przede wszystkim na projekt i ludzi, którzy wspólnych, które w trakcie tej analizy się ujawniło, stanowi dość
w nim pracują. Szczegółowe definiowanie procesów i procedur silny impuls do wypracowania podejścia, łączącego w sobie,
na poziomie organizacji, z punktu widzenia podejścia XP, mają z jednej strony świat  lekkich metod, reprezentowanych przez
małe znaczenie. Z obszarów tych jedynie dwa pozostają czę- podejście określane mianem Extreme Programming; z drugiej 
ściowo komplementarne:  Szkolenia organizacyjne oraz  Inno-  tradycyjnych , których istotę oddaje model CMMI. Jest to wy-
wacje i Wdrożenia . Projekty agile owe, podobnie jak podejścia zwanie, przed którym stanęła dzisiaj inżynieria oprogramowania
strukturalne, definiują potrzeby szkoleniowe, organizują ludziom  wyzwanie, którego jednak nie sposób nie podjąć. Chodzi prze-
niezbędne szkolenia, czy to związane z pełnionymi rolami w cież o lepszą jakość tworzonego software u. Czyż nie? n
R E K L A M A