Programowanie ekstremalne (Extreme Programming, XP) to zwinna metodyka deweloperska autorstwa urodzonego w 1961 roku Kenta Becka, inżyniera oprogramowania, jednego z sygnatariuszy Manifestu Agile. Metodyka została stworzona w celu wytwarzania oprogramowania, aczkolwiek wiele opisanych w podręczniku reguł i praktyk ma uniwersalny charakter. Kent Beck nie poświęca zbyt wiele uwagi kreatywności i innowacji – przedmiotem jego zainteresowania jest wysokiej jakości kod i oprogramowanie dostosowane do wymagań klienta. Paradoksalnie jednak, niemal każdy istotny komponent metodyki sprzyja również twórczemu myśleniu. 

Jaka jest geneza programowania ekstremalnego?

W 1996 roku Kent Beck został zaproszony w charakterze konsultanta i lidera projektu do współpracy w mocno zagrożonym projekcie systemu płacowego budowanego w koncernie motoryzacyjnym Chrysler. Na podstawie dramatycznej oceny sytuacji projektu zdecydowano się wstrzymać jego realizację i zacząć od nowa zgodnie z nowym, zaproponowanym przez współpracowników podejściem. Mimo że sam projekt Chryslera został wkrótce definitywnie zamknięty, to opracowana metoda zarządzania projektem utrzymała się i była dalej rozwijana przez jej twórców (Szpitter, 2018, Wyrozębski, 2021). 

Powstały dwie wersje metodyki, tj. XP (Beck, 1999) oraz XP2 (Beck i Andres, 2005). Dopracowana wersja metodyki opisana została w drugim wydaniu podręcznika, pt. Extreme Programming Explained: Embrace Change i różni się zasadniczo od wersji pierwszej. Elementy koncepcji inspirowane są pracami wielu uznanych osobowości świata zwinnego zarządzania projektami (Beck, 1999), m.in.: Jennifer Stapleton, Warda Cunnighama oraz Toma Gilba (o metodyce EVO, której twórcą był Tom Gilb, przeczytasz tutaj). 

Programowanie ekstremalne – dla kogo?

Metodyka XP ma przede wszystkim charakter metodyki wytwórczej. Opisuje ona zalecenia i praktyki związane z programowaniem, dlatego głównym obszarem jej zastosowania jest tworzenie oprogramowania. Podstawową zasadą XP jest wykonywanie wyłącznie takiej pracy, która jest niezbędna i konieczna w danym momencie oraz w sposób najprostszy z możliwych. Podejście to doprowadza programowanie do „ekstremum”, od czego wzięła nazwę omawiana metoda (Szpitter, 2018, Wyrozębski, 2021).

Czy programowanie ekstremalne sprzyja kreatywności zespołu projektowego?

W Extreme Programming kreatywność zespołu jest wspierana przez wartości, zasady, praktyki, ale w szczególności przez architekturę procesu wytwórczego.

Wartości Extreme Programming

Programowanie ekstremalne (w wersji XP2) opiera się na 5 wartościach. Większość z nich zaleca regularną i intensywną wymianę pomysłów, wiedzy i perspektyw. Ponadto, wspiera dokonywanie zmian w oprogramowaniu już w przebiegu projektu, co stwarza przestrzeń dla urzeczywistnienia kreatywności zespołu. A oto i wartości XP2:

• komunikacja (communication) – extreme programming przedkłada komunikację werbalną ponad inne formy komunikacji; komunikacja werbalna preferowana jest m.in. w czasie zbierania wymagań. Komunikacja werbalna sprzyja również spontanicznej wymianie pomysłów i wiedzy;
• prostota (simplicity) – programiści koncentrują się na pisaniu możliwie prostych i bezpośrednich rozwiązań (what is the simplest thing that could possibly work?);
• informacja zwrotna (feedback) – dzięki krótkim iteracjom produkt jest dostarczany wcześnie do klienta, można szybko reagować na zmianę i doskonalić rozwijane rozwiązanie;
• odwaga (courage) – odwaga oznacza tutaj dokonywanie najlepszych dla projektu wyborów, nawet jeśli wymagają one odrzucenia nieudanych rozwiązań lub zastosowania nowego podejścia – zespół, który obawia się wprowadzić zmiany blokuje bowiem innowacje; 
• szacunek (respect) – każdy członek zespołu jest ważny i wartościowy.

Zasady Extreme Programming

Programowanie ekstremalne (w wersji XP2) opiera się na 14 zasadach. Większość z nich sprzyja twórczemu myśleniu lub tworzy odpowiednie dla twórczego myślenia warunki. Wybrane z nich to:

1. nastawienie na człowieka (humanity) – równowaga między potrzebami poszczególnych uczestników zespołu a wymaganiami projektu; należy dbać o potrzeby członków zespołu, m.in.: o potrzebę bezpieczeństwa, rozwoju czy przynależności,
2. aspekty ekonomiczne (economics) – należy dbać o budżet projektu, np. w pierwszej kolejności rozwiązywać te problemy, które dostarczają największą wartość dla klienta,  
3. wzajemna korzyść (mutual benefit) – należy poszukiwać takich rozwiązań oraz podejmować takie działania, które zapewnią korzyści jednocześnie poszczególnym uczestnikom zespołu, zespołowi oraz oczywiście klientowi,
4. samopodobieństwo (self-similarity) – w procesie rozwoju oprogramowania należy myśleć w kategoriach samopodobieństwa, np. można spróbować skopiować strukturę rozwiązania danego problemu do nowego kontekstu (nawet jeśli wymagać to będzie zmiany skali), a schematy wszystkich cykli – dziennego, tygodniowego, miesięcznego – powinny być do siebie podobne;
5. poprawa (improvement) – doskonałość jest osiągana tylko przez nieustanne udoskonalanie rozwiązań, procesów, historii użytkowników oraz relacji międzyludzkich,
6. różnorodność (diversity) – zderzenie ze sobą zróżnicowanych punktów widzenia jest twórcze i prowadzi do wytworzenia innowacji,
7. refleksja (reflection) – metodyka wysoko ceni refleksyjne podejście do pracy, ujawnianie porażek i analizowanie ich przyczyn,
8. przepływ (flow) – prace programistyczne są wykonywane w sposób ciągły, nie odbywają się w odrębnych fazach, co oznacza, że nowy pomysły mogą zostać wprowadzone w życie w niemal każdym momencie,
9. okazje (opportunity) – należy nauczyć się dostrzegać problemy, ponieważ każdy problem jest okazją do nauki,
10. nadmiarowość (redundancy) –nadmiarowość pozwala uniknąć problemów z jakością;problemyo krytycznym znaczeniu dla rozwoju oprogramowania powinny być rozwiązywane na kilka różnych sposobów. Nawet, gdy jedno rozwiązanie zawiedzie, inne umożliwi uniknięcie całkowitej porażki.
11. niepowodzenia (failure) – testowanie nowych rozwiązań, nawet tych które mogą nie zadziałać, jest dopuszczalne – sprzyja twórczemu myślenia oraz wspiera procesy uczenia się;
12. jakość (quality) – nie należy obniżać standardów jakości produktu, nie przyspieszy to czasu dostarczenia prac, wręcz odwrotnie, może go wydłużyć, a termin zakończenia projektu uczynić mniej przewidywalnym.
13. małe kroczki (baby steps) – rozwijaj rozwiązanie krok po kroczku, unikaj dużych „susów”, czyli długich, wielotygodniowych iteracji.
14. zaakceptowana odpowiedzialność (accepted responsibility)– odpowiedzialność jest zawsze akceptowana przez uczestników zespołów, nie może zostać nadana.Jeśli ktoś jest odpowiedzialny za wykonywanie powierzonego zadania, musi również posiadać odpowiednie uprawnienia.

Praktyki Extreme Programming

Programowanie ekstremalne (w wersji XP2) wyróżnia 13 technik podstawowych (primary practices) oraz 11 praktyk uzupełniających (corollary practices). Cześć z nich może zostać wykorzystana do stymulowania kreatywności. Poniżej opisano techniki podstawowe w podziale na cztery ich kategorie.  

Techniki związane z planowaniem:

• cykl tygodniowy (weekly cycle) – polega na zastosowaniu jednotygodniowych iteracji. Cykl rozpoczyna się od spotkania poświęconego planowaniu, na którym omawiane są poczynione w projekcie postępy, wspólnie z klientami wybierane są historie do danej iteracji i rozbijane na zadania. Następnie szacowany jest czas potrzebny na wykonanie zadań i są one przydzielane programistom. W odróżnieniu od Scruma, niektóre zespoły XP tworzą kolejkę wszystkich zadań z iteracji, a każdy programista po zakończeniu bieżącego zadania zaczyna pracę nad następnym z kolejki – gwarantować to ma sprawiedliwy podział zadań pomiędzy członków zespołu.
• cykl kwartalny (quarterly cycle) – technika wykorzystywana do planowania długoterminowego. Jest to spotkanie, na którym omawiany jest projekt na ogólnym poziomie. Omawiane są motywy, czyli ogólne zagadnieniach z rzeczywistego świata, które pozwalają powiązać historie ze sobą. Niektóre zespoły stosują także retrospekcję używaną w zespołach scrumowych.
• bufor (slack) – technika ta polega na dodawaniu do każdego tygodniowego cyklu historii o niskim priorytecie. Na spotkaniu planistycznym historie te rozbijane są na zadania i włączane do iteracji, ale na sam jej koniec. W przypadku, gdy zespół natrafi na trudności, pominięcie buforowych historii nie uniemożliwi wytworzenia na koniec cyklu kompletnego, działającego oprogramowania – takiego, które działa, przechodzi testy i może zostać zaprezentowane użytkownikom.

Techniki związane z programowaniem:

• programowanie sterowane testami (test-first programming, test-driven development) – technika ta polega na przygotowywaniu w pierwszej kolejności testów jednostkowych, dostosowanych do działania planowanego kodu, a dopiero potem tworzeniu kodu, tak aby przeszedł te testy. Powstaje dzięki temu pętla z informacjami zwrotnymi, pomagająca zapobiegać usterkom.
• programowanie w parach (pair programming) – dwóch programistów w trakcie pisania kodu siedzi przy jednej stacji roboczej, przy czy jeden programista pisze kod, drugi to obserwuje, a jednocześnie obaj cały czas dyskutują o powstającym kodzie, co umożliwia ograniczenie liczby błędów a jednocześnie zwiększa szansę na innowację, gdyż jego członkowie omawiają różne pomysły i rozwiązania na bieżąco, nieustannie prowadząc „burzę mózgów”;

Techniki związane z integrowaniem kodu:

• dziesięciominutowy proces budowania (ten-minute build)  – technika ta polega na tworzeniu automatycznego procesu budowania całego kodu bazowego, wykonywanego w mniej niż dziesięć minut (proces obejmuje automatyczne uruchamianie testów jednostkowych i generowanie raportu z testów);
• ciągła integracja (continuous integration) – technika ta polega na częstym integrowaniu zmian z kodem współpracowników, dzięki czemu izolowane środowisko każdego programisty jest aktualne.

Techniki związane z zespołem:

• wspólne siedzenie (sit together) – członkowie zespołów pracują razem we wspólnej przestrzeni, co sprzyjać ma wymianie wiedzy i automatycznemu przyswajaniu informacji, tzw. komunikacji przez osmozę;
• informatywna przestrzeń robocza (informative workspace) – kształtowanie przestrzeni roboczej w taki sposób, aby zapewniało natychmiastowy dostęp wizualny do istotnych informacji na temat projektu, np. przy wykorzystaniu radiatorów informacji;

Techniki holistyczne:

• projektowanie przyrostowe (incremental design) – podejmowaniu decyzji projektowych w ostatnim sensownym momencie i tworzenie wolnego od powiązań kodu, składającego się z małych, niezależnych jednostek, co umożliwia nanoszenie zmian i rekonfigurowanie systemu, a jednocześnie pozostawia przestrzeń na twórcze zmiany;
• energiczna praca (energized work) – każdy członek zespołu jest zmotywowany, ponieważ ma wystarczająco dużo czasu i swobody, aby wykonywać swoją pracę, w tym rozwijać i stosować dobre nawyki, czy być twórczy;
• cały zespół (whole team) – zespół jest zgrany, posiada odpowiednią dynamikę i jest złożony z osób o komplementarnych kompetencjach.

Techniki uzupełniające – rzeczywiste włączenie klienta

Jedną z praktyk uzupełniających XP2, o których warto tutaj napisać, jest praktyka: rzeczywiste włączenie klienta (real customer involvement) (jest to nieco złagodzona praktyka pt. ciągły kontakt z klientem, znana z pierwszej wersji XP). Chodzi o to, aby klient rzeczywiście brał udział w procesie rozwoju produktu, przekazując zespołowi deweloperskiemu, możliwie na bieżąco, informację zwrotną na temat wytwarzanego oprogramowania. Jest to szczególnie ważne, ponieważ projekt w programowaniu ekstremalnym ma charakter ewolucyjny i adaptacyjny.

Metodyka Extreme Programming dąży do tego, aby oprogramowanie było jak najbardziej dopasowane do wymagań klienta. Klient ma nieustanny kontakt z produktem i w każdej chwili może zmienić swoją koncepcję, np. uwzględnić nowe, twórcze pomysły, ponosząc przy tym niewielkie koszty w stosunku do zmiany koncepcji w projekcie tworzonym tradycyjnymi metodami.

Programowanie ekstremalne – role w zespole projektowym

Chociaż XP2 wyróżnia i opisuje pewne role, w dojrzałych zespołach nie są one przypisane na stałe. Przypisanie do roli, w opinii Kenta Becka, utrudnia bowiem wykorzystanie maksymalnych możliwości zespołu – celem jest zachęcenie wszystkich do przyczyniania się do sukcesu zespołu (…) po zbudowaniu nowych, opartych na wzajemnym szacunku relacji między członkami zespołu, stałe role utrudniają pracownikom wykorzystanie wszystkich swoich możliwości (Beck i Andres, 2005, s. 81). Takie podejście pozwala każdemu z uczestników na realizację swojego kreatywnego potencjału, chociaż wymaga od zespołu dojrzałości.

Programowanie esktremalne – architektura procesu wytwarzania

W programowaniu ekstremalnym proces wytwarzania oparty jest bowiem na niezwykle krótkich, tygodniowych iteracjach, a czynności związane z planowaniem, analizowaniem i projektowaniem są zmieszane i wykonywane naprzemiennie po troszeczku przez cały czas trwania procesu wytwarzania oprogramowania: 

Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities—a little at a time—throughout development (Beck, 1999, s. 70). 

Wynika to m.in. z zasady przepływu, która rekomenduje, aby wszystkie czynności realizować możliwie równolegle, płynnie, bez podziału na odrębne etapy:

The practices of XP are biased towards a continuous flow of activities rather than discrete phases (Beck i Andres, 2005, s. 30).

Jeżeli już mówić o jakiejś strukturze, zgodnie z pozostałymi praktykami, ogólne motywy zagadnienia, historie użytkowników tworzone i omawiane są w cyklu kwartalnym (praktyka cykl kwartalny), natomiast praca wykonywana jest w ramach bardzo krótkich tygodniowych iteracji (praktyka cykl tygodniowy). Poszczególne zadania planuje się z tygodnia na tydzień, co stanowi skrajny przypadek tzw. podejmowania decyzji w ostatnim sensownym momencie. Ponadto, w programowaniu ekstremalnym, nie są̨ stosowane formalne przeglądy po zakończeniu prac, ponieważ zespoły nieustannie rozmawiają̨ o tym, co robią̨ i jak mogą̨ wprowadzić usprawnienia w trakcie pracy – refleksja i poprawa wbudowane są w proces pracy jako zasady (mówią o tym omówione wcześniej zasady refleksji i poprawy).