Obszar projektowania i kodowania

W XP w zasadzie nie istnieje pojęcie projektowania w oderwaniu od programowania (wyjątkiem jest metafora - opis architektury systemu, oczywiście w języku zrozumiałym dla wszystkich). Każda para programistów (XP zakłada pracę parami), podejmując się realizacji danej opowieści użytkownika, odpowiada jednocześnie za jej zaprojektowanie, implementowanie i przetestowanie.

Ze względu na to, że zakres całego systemu jest nieznany, XP zaleca prostotę projektu (nie projektować struktur pod funkcje, które być może nigdy nie zostaną zaimplementowane). Prosty projekt - wg XP - to taki, który realizuje założoną funkcjonalność, a jednocześnie nie ma redundancji logicznych, jest czytelny i możliwie zwięzły.

System obudowywany stopniowo nowymi funkcjami z czasem przestaje być prosty, dlatego stosuje się refaktoryzację. Polega ona na przebudowie programu, usuwaniu redundancji, czyszczeniu kodu - ale bez zmiany jego funkcjonalności i przy spełnieniu tych samych testów.

Cały kod jest wspólną własnością całego zespołu - każdy może go uzupełniać i poprawiać. Wymaga to oczywiście stosowania standardu kodowania i zachowania pewnych rygorów, jednak dzięki temu wprowadzanie zmian i poprawek jest łatwiejsze. Aby obniżyć koszt integracji, system jest kompilowany w całości przynajmniej raz dziennie, za co odpowiadają specjalizowane narzędzia.

Po zaimplementowaniu kilku, kilkunastu nowych funkcji, nowa wersja systemu jest przekazywana użytkownikowi. Szybka odpowiedź klienta pozwala tak pokierować pracami, aby powstał system spełniający jego potrzeby, a nie tylko zakontraktowane wymagania.

Obszar testowania

Testowanie w XP jest wykonywane w dwojaki sposób: na poziomie testów jednostkowych, przez każdego programistę, oraz poprzez testy akceptacyjne, przez przedstawiciela klienta. Charakterystyczne, że oba rodzaje testów powstają przed implementacją. Przypadki testowe wraz z kodem stanowią jedyny zapisany artefakt przedsięwzięcia realizowanego zgodnie z XP.

XP w praktyce

Jak łatwo się domyślić, programiści przyjęli nowe metodyki umiarkowanie ciepło, menedżerowie projektów - z chłodną rezerwą, a naukowcy - z zainteresowaniem. Niestety, początkowe wrażenia szybko przekształciły się w mity, które trudno obalić. Dyskusja o tym, czym jest, a czym nie jest XP, trwa do dzisiaj - bez większych nadziei na zakończenie.

Jedno z najpoważniejszych nieporozumień dotyczących XP ma źródło w prowokującej nazwie, rozumianej jako programowanie ekstremalnie chaotyczne. Wiele organizacji, które - mówiąc eufemistycznie - zostałyby sklasyfikowane na poziomie 1 modelu CMM, ogłasza z dumą, że stosują XP. XP zaś to nie brak procesu; przeciwnie - oznacza jedną z bardziej zdyscyplinowanych metodyk, która ekstremalnie poważnie podchodzi do zagadnień jakości oprogramowania i wymaga stosowania określonych praktyk. Dlatego lekceważące uśmieszki na ustach niektórych krytyków XP świadczą najczęściej o ich niewiedzy, a nie rzeczywistych złych doświadczeniach w stosowaniu tej metodyki.

Krytycy czasem jednak mają rację, ponieważ okazuje się, że trudno o jednoznaczną i miarodajną ocenę XP. Dlaczego? Bo XP nie zawsze oznacza to samo.

Pierwszy raport z wdrożenia XP, słynny już projekt C3 z 1998 r. - poligon doświadczalny Kenta Becka - pozostał jednym z niewielu "czysto" ekstremalnych. Zestaw praktyk XP, choć gorąco broniony przez Becka, okazuje się trudny do wdrożenia w całości. Dlatego wiele kolejnych projektów jest ekstremalnych zaledwie w większym lub mniejszym stopniu, co znacznie utrudnia jakiekolwiek porównania czy oceny. Oznacza to również, że wyniki badań czy inne raporty, w konkretnej sytuacji, mogą mieć niewielką lub nie mieć żadnej wartości. Pozostaje zdać się na eksperyment i intuicję.

Mimo to istnieje wiele raportów z wdrożenia XP. Oprócz całej metodyki badaniom poddawano także pojedyncze praktyki, przede wszystkim programowanie parami - najbardziej charakterystyczny i jednocześnie najbardziej egzotyczny element metodyki. Podstawowy, oparty na intuicji zarzut to konieczność poświęcenia pracy dwóch osób na zadanie, które mógłby wykonać jeden programista. Wprawdzie opublikowane wyniki badań pokazują, że narzut dodatkowej pracy waha się od ok. 50 do 80%, jednak nie uwzględniały one efektu ciągłej inspekcji, a co za tym idzie - spodziewanej poprawy jakości kodu. W praktyce programowanie parami jest stosowane jedynie przy implementacji trudniejszych fragmentów systemu, większość systemu jest natomiast tworzona w tradycyjny sposób. Taki kompromis wydaje się rozsądny, ponieważ pozwala wykorzystać zalety tej praktyki w najważniejszych fragmentach, jednocześnie zmniejszając nakłady tam, gdzie ryzyko błędu jest niewielkie. Poza tym zdarzają się osoby, które nie potrafią programować parami - wywołuje to u nich agresję i obniża wydajność. W takiej sytuacji - abstrahując od przyczyn - również lepiej wyłączyć taką osobę z pracy w parach, niż ryzykować konflikt.

Kolejna wątpliwość związana z XP to niemal całkowity brak dokumentacji (jedynie kod źródłowy i przypadki testowe), a co za tym idzie - potencjalne problemy w fazie po wdrożeniu oprogramowania. Problemy te mogą się pojawić, jeżeli XP jest stosowane niewłaściwie. Cykl "życia" XP to właściwie nie kończący się okres utrzymywania systemu: tworzenie nowych funkcji przebiega równolegle z poprawianiem błędów w istniejącej wersji. Projekt XP "żyje" tak długo, jak długo są w nim wprowadzane zmiany, bo tylko w ten sposób "dokumentacja" utrzyma się w pamięci (niestety, często ulotnej) programistów. Rotacja programistów i przejrzystość kodu mają temu zapobiec - i to wystarcza w odniesieniu do niewielkich systemów i budujących je zespołów. Nie są znane przypadki zastosowania XP w realizacji większych projektów i prawdopodobnie właśnie problem z dokumentacją stanowi barierę przy skalowaniu tej metodyki. Rozwiązaniem może być wprowadzenie ograniczonego dokumentowania, czego zresztą XP nie zakazuje.