W Extreme Programming najistotniejszym elementem jest komunikacja między informatykami.

Aby zrozumieć powody, dla których narodziła się Extreme Programming (XP), należy sięgnąć pamięcią do początku lat 90. Wtedy właśnie na uczelniach i w przedsiębiorstwach zaczęto interesować się metodologią tworzenia systemów informatycznych. Rozwinięte wtedy, i stosowane dzisiaj, metodyki inżynierii oprogra- mowania próbowały w sposób systematyczny ująć proces, tj. podzielić go na fazy, określić sposób analizy i projektowania, ustandaryzować zapis, nawet określić role w zespole. Jednym słowem metodyki nakazują traktować proces konstrukcji systemu informatycznego tak samo, jak traktowane są procesy konstrukcji maszyn czy budynków.

Metodyki te wniosły wiele dobrego do inżynierii oprogramowania, ale nie rozwiązały problemów, które miały właśnie rozwiązać. Praktyka tworzenia systemów jest nadal inna. Głównym jej elementem jest pisanie kodu programu. Na drugim planie pozostaje rygoryzm analizy i projektowania oraz tworzenie dokumentacji. Praktyka ta pozwala na budowanie systemów może nie doskonałych, może nie w przewidzianym czasie i określonej jakości, ale takich, za które chcą płacić klienci.

Extreme Programming, zamiast zmienić ten stan rzeczy, stara się wyciągnąć z niego jak najwięcej korzyści. Określa ramy i daje podbudowę pewnych szeroko stosowanych praktyk, akcentując przede wszystkim użyteczność i zdrowy rozsądek bardziej niż formalną poprawność. Mówiąc ogólnie, XP nie tylko "dorabia ideologię" do istniejących praktyk, ale także proponuje rozwiązanie nowe, warte przynajmniej przedstawienia, przemyślenia i dyskusji.

Wyznaczniki XP

U podstaw XP tkwi zasada "czterech wartości", jak nazywają ją twórcy metody. Trzy z nich to: prostota, komunikacja, testowanie; czwarta zaś wynika z nich i określana jest mianem agresywności lub nieustraszoności (Aggressiveness/Fearlessness), która oznacza po prostu brak obawy przed zmianą dowolnej części systemu i dowolnego rozwiązania.

Dla zrozumienia filozofii Extreme Programming warto wiedzieć, że narodziła się ona w środowisku programistów Smalltalka. Język ten ma cechy, które tkwią u źródeł tej metody. Otóż Smalltalk jest dalekim potomkiem LISP-a, językiem, który jako pierwszy wspierał w pełni paradygmat obiektowy i do dziś uznawany jest za wzór "czysto obiektowego" podejścia. W Smalltalku wszystko jest obiektem - nawet tak wydawałoby się fundamentalne elementy programu, jak pętle i warunki. Język ten jest szeroko znany i wykorzystywany w USA, a w Europie, w tym także w Polsce, stosowany jest raczej w edukacji informatycznej. Standardowa biblioteka Smalltalka do dziś pozostaje niedoścignionym wzorem prostej konstrukcji i elastyczności. Warto też dodać, że programy pisane w Smalltalku charakteryzują się zwięzłością i czytelnością, co sprawia, że język ten bywa stosowany jako narzędzie specyfikacji (przy innym narzędziu implementacji).

Łatwiej teraz zrozumieć, dlaczego jednym z paradygmatów XP jest bardzo skąpa dokumentacja, jeżeli to konieczne, to na poziomie klasy lub metody. Dokumentacja techniczna, a także komentarze w kodzie są niepotrzebne, bo, zdaniem autorów metody, programy powinny być pisane w tak oczywisty sposób, żeby były czytelne dla każdego, kto do nich zajrzy. Zamiast więc czytać specyfikacje interfejsów, wystarczy spojrzeć w kod.

Nie tylko jednak dokumentację techniczną XP uznaje za zbędną. Również inżynierię wymagań, w tradycyjnym rozumieniu tego pojęcia, metoda uznaje za ciężar. Po pierwsze, wymagania zmieniają się (co, jak już trzydzieści lat temu pisał prof. Turski, jest nieusuwalną cechą rzeczywistości), a przy ich zbieraniu łatwo popełnić błąd. Tradycyjny cykl (analiza - projekt - implementacja) sprawia, że błąd w definiowaniu wymagań powoduje dramatyczne, "kaskadowe" skutki w kolejnych fazach - w skrajnym przypadku może okazać się, że podsystem musi być zmieniony.

Zamiast tego XP proponuje uznać, że program jest i będzie wielokrotnie zmieniany. Określa się to mianem refactoring i pod tą nazwą kryje się to, co każdy zespół informatyczny zna z praktyki, czyli modyfikowanie kodu w miarę potrzeby.

Może wydawać się to trudne do zrealizowania w sytuacji, gdy modyfikacja ma być dokonana przez kogoś innego niż autor kodu. Jednakże XP zakłada kompletny brak "własności kodu" (code ownership). W tradycyjnym zespole istnieją osoby odpowiedzialne za dany fragment systemu i każda zmiana w tym elemencie wymaga angażowania autora. Jest to poniekąd uwarunkowane potrzebą przypisania odpowiedzialności konkretnej osobie (podręczniki zarządzania akcentują osobistą odpowiedzialność jako najlepszy sposób zapewnienia wysokiej jakości), a także faktem, że różni informatycy mają różne style pisania i "rozgryzanie" kodu tworzonego przez kogoś innego jest kłopotliwe i czasochłonne. Zamiast tego XP proponuje jednolity styl i zasady formatowania kodu oraz pełną swobodę modyfikacji fragmentu pisanego przez kogoś innego. Jeżeli kod jest prosty i czytelny dla każdego (a takie są fundamentalne założenia Extreme Programming), nie ma potrzeby, aby elementy były przypisane autorowi.

Extreme Programming odwraca też tradycyjne podejście do kwestii ponownego użycia. Podręczniki inżynierii oprogramowania akcentują fakt, by tworzyć rozwiązania elastyczne i uniwersalne po to, aby w przyszłości można je było zastosować do podobnych problemów. Zamiast tego XP daje regułę YAGNI (you're NOT gonna need it), w myśl której nie należy tworzyć nic "na zapas". Twórcy metody argumentują, że w niewielu przypadkach elastyczność jest rzeczywiście potrzebna. Jeśli jednak jest potrzebna, to nie ma problemu - po prostu zmienia element, który trzeba "uelastycznić".

Po pierwsze, komunikacja

Kluczowe różnice między tradycyjnym podejściem a XP dotyczą organizacji procesu i zespołu. W nowej metodzie najistotniejszym elementem jest komunikacja między informatykami. Najbardziej chyba wyrazistym elementem odróżniającym XP od tradycyjnego podejścia jest programowanie w parach. "Stwierdziliśmy, że postęp jest szybszy, można pracować dłużej bez tracenia z oczu celu, a jakość jest wyższa. Zwykle pisaniem kodu zajmuje się ta osoba, która lepiej ÇczujeČ określony fragment programu. Druga osoba - obserwator - wyławia błędy (literówki, formatowanie, nazwy metod) i zwykle to ona patrzy na dany element szerzej, w kontekście celów biznesowych jakim on służy" - mówią twórcy tej metody.

XP umożliwia przemieszczanie informatyków między zespołami. Praktyka ta, zdaniem twórców metody, zapewnia dystrybucję wiedzy i doświadczenia w przedsiębiorstwie, przeciwdziała wąskiej specjalizacji (autorzy akcentują, że nie można być dobrym autorem komponentów niskopoziomowych, nie mając do czynienia z użytkową stroną systemu). Przy braku jednoosobowej odpowiedzialności za kod i stosowaniu wspólnych standardów i konwencji programistycznych taka rotacja jest możliwa, a nawet łatwa.

Kolejnym elementem poprawionej komunikacji w zespołach stosujących Extreme Programming jest przebywanie w jednym miejscu i czasie. Izolowane pokoje dla informatyków, zalecane przez podręczniki zarządzania projektem informatycznym, a także chętnie stosowane przez najlepsze firmy software'owe są błędem - zdaniem autorów XP. Ci zakładają, że bliskość osób współpracujących pozwoli na lepszą wymianę myśli w zespołach.

Istotnym, wręcz fundamentalnym wyznacznikiem XP jest częsta (przynajmniej codzienna) synchronizacja źródeł programu i tworzenie z niej gotowego produktu. Taki "wewnętrzny" produkt jest następnie testowany (testowanie posunięte do przesady to jeden z trzech kluczowych elementów metody), a błędy są usuwane natychmiast przez osobę, która w danej chwili wykryła błąd (pamiętajmy, że to zespół, a nie programista, jest odpowiedzialny za kod). Każda klasa tworzona przy użyciu XP powinna mieć test modułu (unit test), który jest w stanie automatycznie i szybko zweryfikować, czy po ewentualnej modyfikacji podstawowa funkcjonalność klasy została zachowana.

I wreszcie bardzo ważna rzecz: w myśl XP nie wolno zmuszać informatyków do pracy dłuższej niż standardowy tydzień roboczy. Autorzy argumentują, że dłuższy nie oznacza bardziej produktywny, zaś negatywne konsekwencje braku życia prywatnego nie są warte wątpliwych korzyści z wydłużonych godzin pracy.

Na koniec merytorycznego opisu Extreme Programming warto dodać, że twórcy metody zdają sobie sprawę, że reguły są o tyle dobre, o ile przechodzą przez weryfikację w praktyce. Akcentują nie tyle ścisłe stosowanie się do tych czy innych szczegółowych elementów XP, ile raczej fakt jak najintensywniejszej komunikacji w zespole i testowanie "do upadłego".

Fundamentalne pytania

Extreme Programming wzbudza wiele emocji z jednego, zasadniczego powodu. Otóż wielu informatyków - można by nawet powiedzieć, że pokolenie informatyków - włożyło wiele wysiłku w doprowadzenie informatyki do miejsc, gdzie dziś jest budownictwo, elektronika czy mechanika. Dziedziny te charakteryzuje zorganizowany cykl produkcyjny - na przykład podczas budowy mostu najpierw tworzy się dokumentację założeń, a potem projekt, według prawideł sprawdzonych przez lata. Następnie stawia się most, który musi spełniać wiele standardów bezpieczeństwa, a potem dokonuje się wszechstronnych testów konstrukcji. Informatyka co prawda nie dorosła jeszcze do takiego stadium, ale wiele osób pracowało i nadal pracuje nad tym, żeby tak się stało.

Tymczasem entuzjaści XP uznają, że inżynieria oprogramowania jest zasadniczo różna od np. inżynierii lądowej. Twierdzą, że konstrukcja systemów informatycznych nie poddaje się takiej organizacji i standaryzacji jak inne dziedziny inżynierii. I zamiast mnożyć na razie nieskuteczne wysiłki w celu uczynienia jej taką, lepiej sprawić, by zespoły zaczęły dostarczać takie wyniki, jakich się od nich oczekuje. Nie ma znaczenia, czy ich działanie będzie wzorem z punktu widzenia reguł organizacji i zarządzania, jeżeli tylko dostarczają dobre systemy w założonym czasie i budżecie.

Gdyby paradygmaty rządzące XP przenieść na budowę mostu, należałoby od razu wpuścić na plac budowy kilka zgranych ekip składających się z nie wyspecjalizowanych rzemieślników. Te zaś, według swojego uznania i standardów, postawiłyby przęsła mostu, potem pomyślałyby o konstrukcji jez-dni. Gdyby podczas prób obciążeniowych okazało się, że któryś z filarów jest za słaby, ta ekipa, która byłaby akurat wolna, obok dobudowałaby szybko drugi filar.

Oczywiście taki sposób postępowania byłby absurdalny z punktu widzenia inżynierii lądowej. Ale twórcy XP twierdzą, że problemy, z którymi mierzy się informatyka, nie są problemami klasy "postawić kolejny most", a "opracować technologię budowy konstrukcji łączących". Tym samym podejście rutynowe nie stosuje się do nich.

Moda czy metoda?

Metoda XP dzieli środowisko informatyków. Po jednej stronie znajdują się, co oczywiste, jej autorzy i grupa entuzjastów. Można wśród nich znaleźć znaczące postacie, np. Robert Martin, prezes firmy Object Mentor, i autor znanej metodyki obiektowej Martin-Odell. Argumentuje on: Jesteśmy zwolennikami dwóch zasad: 1) Tworzenia oprogramowania szybko 2) Tworzenia go dobrze. Nasze doświadczenie wskazuje, że kluczowym elementem osiągnięcia tych dwóch niezgodnych celów jest mały, oparty na architekturze proces, taki jak XP.

Tom DeMarco, niekwestionowany autorytet w dziedzinie zarządzania procesem tworzenia programowania, jest równie entuzjastyczny: "Ruch zwany Extreme Programming jest, moim zdaniem, najciekawszym trendem w tworzeniu oprogramowania. Skupia się na rzeczywistych problemach: talencie, dyscyplinie bez dogmatu, pracy zespołowej, podejmowaniu ryzyka (...) Myślę, że XP będzie odpowiedzią następnego pokolenia na bezsensowną biurokrację projektową opartą na CMM lub innych metodykach rodem z opasłych tomisk".

Krytycy, choć nie tak utytułowani, mają bardzo poważne argumenty. Przede wszystkich, ich zdaniem, XP nadaje się do drobnych projektów i niewielkich zespołów, ale zawodzi w przypadku większych przedsięwzięć. Ponadto zaniedbanie inżynierii wymagań i solidnego projektowania zaowocuje chaosem. Jeden z aspektów XP wzbudza szczególnie wiele sprzeciwów: menedżerowie informatyki twierdzą, że posadzenie dwóch osób przy jednej stacji roboczej obniży wydajność, zamiast ją podwyższyć, i przyczyni się do jeszcze większych braków kadrowych w firmach.

Warto zauważyć, że XP nie akcentuje profesjonalnego przygotowania członków zespołu. Przeciwnicy metody, wskazując na ten fakt, twierdzą, że obiecuje ona sukcesy w oderwaniu od rzeczywistego, merytorycznego przygotowania informatycznego, popartego głębokim zrozumieniem fundamentów tej nauki oraz problemów, które tworzony system ma rozwiązywać.

Miażdżącej krytyce poddał XP je- den z uczestników listy dyskusyjnej OBJECTS, zamieszkały na stałe w USA i obserwujący z bliska tamtejsze zespoły: XP obiecuje dobre lub nawet wspaniałe rezultaty w sytuacji kompletnego rozgardiaszu oraz niezdolności do artykulacji wymagań i planowania. Nie jest więc zaskakujące, że XP ma tylu konwertytów, że jest widoczne na konferencjach (...) iż niektórzy "łowcy głów" zaczynają szukać ludzi do projektów z XP oraz że nowy kult tworzy swoją konferencję i księży. W końcu samopomazany papież kościoła XP wydał już biblię. Przywodzi to na myśl twórcę scientologii, który trafnie zauważył, że duże pieniądze w Stanach najłatwiej robi się na religii.

Tak odległa od praktyk inżynierskich metoda, jak Extreme Programming, mogła narodzić się wyłącznie w Ameryce, gdzie skuteczność ceniona jest ponad poprawność i systematyczność. Jeden z krytyków na łamach listy OBJECTS trafnie zauważył, że XP jest dla informatyki tym, czym książki takich autorów, jak Dale Carnegie, Zig Ziglar i Anthony Robbins, są dla biznesu. Zarówno XP, jak i wspomniane pozycje promują światopogląd streszczający się w zdaniu: "Wystarczy bardzo chcieć, wierzyć w to, co się robi oraz współdziałać z innymi i można osiągnąć wszystko".

Są jednak w Extreme Programming praktyki, których sensowności nie kwestionuje praktycznie nikt. Zalicza się do nich przede wszystkim solidne testowanie, unikanie ścisłej specjalizacji członków zespołu, brak nadgodzin, poprawienie komunikacji w zespole, częste integracje produktu. Jeżeli więc nawet XP nie zyska powszechnej akceptacji jako całość, to można oczekiwać, że doprowadzi do rozpowszechnienia tych właśnie pożytecznych praktyk.

--------------------------------------------------------------------------------

Więcej o XP:

http://www.xprogramming.com fundamentalna lektura dla każdego, kto chce poznać podstawy XP

http://www.extremeprogramming.org przystępny samouczek XP, także lista przedsiębiorstw stosujących metodę

http://objectmentor.com firma Object Mentor promująca XP

http://www.ict.pwr.wroc.pl/ftp/pub/listy-dyskusyjne/objects archiwum listy OBJECTS, warto sięgnąć do archiwum z grudnia 1999 r. oraz maja i lipca 2000 r.; uwaga: serwer "cierpi" na problem roku 2000 i np. archiwum z maja 2000 r. jest w pliku 1900-05.txt.Z

Kent Beck: Extreme Programming Explained. Wydawnictwo Addison-Wesley 1999; ISBN 0201616416 - tzw. Biblia XP