Extreme Programming (XP) – nowy standard kodowania? 

Czym jest Extreme Programming (XP)?

Programowanie ekstremalne jest  kolejną metodyką wytwarzania oprogramowania, która wlicza się w zbiór wielu innych zwinnych podejść. XP opiera się na wartościach, zasadach i praktykach. Jego głównym celem jest umożliwienie małym i średnim zespołom developerskim dostarczania wysokiej jakości oprogramowania, z jednoczesnym dostosowaniem do zmieniających się wymagań biznesowych.

Tym, co odróżnia programowanie ekstremalne od innych podejść zwinnych, jest to, że Extreme Programming kładzie kluczowy nacisk na aspekty techniczne związane z rozwojem oprogramowania. XP dokładnie określa sposób pracy developerów, czego efektem jest dostarczanie wysokiej jakości oprogramowania w odpowiednim okresie czasu.

Ujmując krótko, Extreme Programming kładzie… ekstremalnie silny nacisk na dobre praktyki programowania.

Historia XP

Korzenie programowania ekstremalnego sięgają lat 90. ubiegłego wieku. Zapoczątkował je Kent Beck, znany również jako jedna z siedemnastu osób, które podpisały Agile Manifesto. Wszystko zaczęło się podczas realizacji projektu, w którym Kent Beck brał udział. Przez 3 lata rozwoju projektu nie udało się zrobić większego postępu. Beck jako osoba, która była nowa w zarządzaniu zespołem, zdecydował, że najlepszym pomysłem będzie nauczenie zespołu technik i praktyk, które zadziałały dla niego samego. Z sukcesem udało się wdrożyć praktyki takie jak programowanie w parach i TDD (Test-Driven Development). Bazując na tym doświadczeniu, Kent Beck w 1999 roku spisał praktyki, wartości i zasady programowania ekstremalnego w swojej książce “Extreme Programming Explained: Embrace Change”.

Extreme Programming a inne podejścia

Jak programowanie ekstremalnie różni się od tradycyjnych, niezwinnych metodologii? Programowanie ekstremalne jest częścią podejścia Agile, w którym ważne jest płynne wprowadzanie zmian. Zamiast trzymać się konkretnego, odgórnie ustalonego sztywnego planu, zespoły developerskie działają elastycznie.

Extreme Programming mocno się różni od tradycyjnych metodyk, takich jak na przykład Waterfall.

Programowanie ekstremalne vs Scrum

Ktoś mógłby zapytać: no dobrze, ale czy wszystkich powyżej opisanych możliwości nie daje już Scrum? Scrum to framework, który pomaga przecież zespołom rozwijać złożone projekty w sposób iteracyjny i nie narzuca tego, jak programiści wykonują pracę. Główna różnica polega na tym, że Extreme Programming, jak wspomniano, kładzie duży nacisk na dobre praktyki programistyczne.

Poza tym programowanie ekstremalne jest bezpośrednio związane z programowaniem, a Scrum można zastosować do dowolnego projektu, w którym sprawdzi się podejście iteracyjne.

Programowanie ekstremalne akceptuje wprowadzanie zmian do swoich komponentów (spotkań, artefaktów). Zespoły mogą, a nawet powinny dostosowywać artefakty zgodnie ze swoimi potrzebami. Z drugiej strony Scrum Guide stwierdza, że „Chociaż implementacja tylko części Scruma jest możliwa, rezultatem nie jest Scrum”. Scrum jest frameworkiem, który trzeba uzupełnić własnymi procesami i metodologiami. Oznacza to, że nie tylko jest możliwe użycie programowania ekstremalnego i Scruma jednocześnie, ale nawet jest to mocno rekomendowane.

Jak działa programowanie ekstremalne?

Programowanie ekstremalne opiera się na wartościach, praktykach i zasadach.

• Wartości wyznaczają zespołom cel. Działają jak nawigacja, która kieruje decyzjami na wysokim, abstrakcyjnym poziomie. Ze względu na abstrakcyjność tych wartości i ich generyczność, trudno jest uzyskać konkretne wskazówki. Przykładowo stwierdzenie, że „ceni się komunikację”, może być rozumiane bardzo szeroko (np. poświęcanie spotkań Daily na rozmawianie tylko o tematach niezwiązanych z potrzebami zespołu i klienta).
• Praktyki są w pewnym sensie przeciwieństwem wartości. Wartości są pojęciami ogólnymi, teoretycznymi, praktyki natomiast to już konkretne procesy, które definiują specyfikę tego, co należy wykonać. Praktyki pomagają zatem zespołom pielęgnować wartości. Przykład: Wartość: komunikacja. Praktyka: wymiana wiedzy w zespole.
• Zasady to wytyczne specyficzne dla danej domeny, które wypełniają lukę pomiędzy praktykami a wartościami.
  
  

Feedback przybiera wiele form i może mieć różny zakres.

Kiedy programuje się w parach, komentarze drugiego developera są bezpośrednią informacją zwrotną. Podobnie opinie innych członków zespołu, w tym klienta, który również jest rozumiany jako członek zespołu. Testy są kolejnym źródłem cennego feedbacku. Jeżeli napisanie testów jest trudne i sprawia wiele problemów, oznacza to, że architektura lub zastosowane w projekcie rozwiązania są zbyt skomplikowane i wymagają uproszczenia.
Może dojść do sytuacji, gdy zespół będzie dostawał więcej feedbacku, niż jest w stanie obsłużyć. Wtedy istnieje ryzyko, że w natłoku spraw ważniejszy feedback zostanie pominięty przez zespół. Należy wówczas przeanalizować, dlaczego przychodzi tak wiele informacji zwrotnych i co trzeba naprawić.

• Odwaga – Kent Beck definiuje odwagę jako „Efektywne działanie w obliczu strachu”. Developer ma wiele powodów do obaw, a zarazem wiele możliwości do wykazania się zaangażowaniem. Potrzeba odwagi do mówienia prawdy, zwłaszcza nieprzyjemnej prawdy, przykładowo o nierzeczywistych estymatach. Udzielanie i przyjmowanie feedbacku również wymaga odwagi.
• Szacunek – podstawową zasadą programowania ekstremalnego jest to, że każdy dba o jakość kodu i angażuje się w swoją pracę. Żaden, nawet najnowocześniejszy stos technologiczny nie uratuje projektu, jeżeli nie ma w nim szacunku i troski.

Zasady

Zasady w programowaniu ekstremalnym zapewniają bardziej szczegółowe wskazówki niż wartości. Zasady klarują wartości i czynią je bardziej wyraźnymi, niwelując ich poziom jednoznaczności. Przykładowo, opierając się na wartości odwagi, można by stwierdzić, że wprowadzenie dużej zmiany w kodzie jest zalecane. Jednak wedle zasady małych kroków, duże zmiany są ryzykowne, dlatego wprowadzanie zmiany powinny być jak najmniejsze.

Ludzie – oprogramowanie jest tworzone dla ludzi przez ludzi. Jest to oczywisty, a często pomijany fakt. Jednak uwzględnianie mocnych i słabych stron człowieka i jego potrzeb jest ważne, pozwala bowiem tworzyć produkty, z których ludzie chcą korzystać. Środowisko pracy, które daje możliwości do osiągnięć i rozwoju, poczucie przynależności, jest miejscem, gdzie łatwiej jest uwzględnić potrzeby innych.

Ekonomia – zespoły developerskie w XP kierują się realiami ekonomicznymi podczas tworzenia oprogramowania, stale szacując ryzyko i potrzeby projektu. Na przykład najpierw zostanie wdrożona historyjka (User Story) pod względem wartości biznesowej, a nie pod kątem kwestii technicznych.

Wzajemna korzyść – stosując programowanie ekstremalne, unika się rozwiązań, które przynoszą korzyść jednej stronie kosztem drugiej. Na przykład obszerna dokumentacja i specyfikacja mogą pomóc komuś innemu zrozumieć dane zagadnienie, jednocześnie odciągając zespół od implementacji i opóźniając ją.

Obustronnie korzystnym rozwiązaniem jest np. zastosowanie automatycznych testów akceptacyjnych. Otrzymuje się natychmiastową informację zwrotną na temat implementacji, developerzy dostają precyzyjną specyfikację w kodzie, a użytkownicy szybciej uzyskują dostęp do funkcjonalności.

Podobieństwo – jeśli dane rozwiązanie działa na pewnym poziomie, może również działać na wyższym lub niższym poziomie. Na przykład zdobywanie wczesnego i stałego feedbacku jest ważne na różnych poziomach XP.

• Na poziomie developerów – programiści otrzymują informację zwrotną ze swojego kodu, stosując podejście Test First, polegające na napisaniu unit testów przed przystąpieniem do programowania.
• Na poziomie zespołu – narzędzie CI/CD pipeline buduje i testuje kod kilka razy dziennie.
• Na poziomie organizacji – iteracje tygodniowe i kwartalne pozwalają zespołom uzyskać feedback i w razie potrzeby usprawnić pracę.

Udoskonalenie –zgodnie z zasadą doskonalenia zespoły nie dążą do perfekcji we wstępnej fazie implementacji, ale do wdrożenia wystarczająco dobrego. Następnie stale się uczą i ulepszają produkt, dzięki feedbackowi od użytkowników.

Różnorodność – developerzy czerpią korzyści z różnorodności podejść, umiejętności i postaw. Jednak taka różnorodność często prowadzi do konfliktów.

Konflikty i nieporozumienia – są okazją do pojawiania się lepszych pomysłów, gdy wszyscy kierują się wartościami odwagi i szacunku. Odwaga jest niezbędna do wyrażania innego zdania, z szacunek do wyrażania go w sposób empatyczny. Wszystko to jest ćwiczeniem skutecznej komunikacji.

Refleksja – zespoły zastanawiają się nad swoją pracą i analizują, jak być lepszym. Extreme Programming daje ku temu wiele możliwości. Nie tylko w cyklach tygodniowych i kwartalnych, ale w każdej praktyce.

Przepływ – tradycyjne podejścia mają odrębne fazy, które trwają przez długi czas i pozostawiają niewiele przestrzeni dla feedbacku i możliwości korekty. Tworzenie oprogramowania w XP odbywa się w ramach aktywności, które trwają cały czas, w spójnym przepływie wartości.

Szansa – problemy są nieuniknione w procesie tworzenia oprogramowania, jednak każdy problem jest okazją do poprawy. Warto nauczyć się patrzeć na nie w ten sposób, żeby pozwalały na tworzenie kreatywnych rozwiązań, które również pozwolą zapobiegać ich powtórzeniu w przyszłości

Redundancja – zasada redundancji mówi, że jeżeli dany problem jest krytyczny, należy zastosować wiele taktyk, aby go rozwiązać. Nie ma jednej taktyki, która może zlikwidować krytyczne problemy. Rozwiązaniem, które proponuje programowanie ekstremalne, jest wyznaczenie kilku wskaźników jakości. Pomocne w osiąganiu zamierzonej jakości są: programowanie w parach, testy, ciągła integracja (CI).

Porażka – porażka nie jest stratą, jeżeli można z niej wyciągnąć wnioski i wiedzę. Podejmowanie decyzji i szybkie uczenie się, co nie działa, jest o wiele bardziej produktywne niż brak działania spowodowany niezdecydowaniem.

Jakość – często wydaje nam się, że musimy wybierać między jakością a szybkością.
Jednak jest całkowicie na odwrót – dążenie do poprawy jakości sprawia, że szybkość zespołu (team velocity) wzrasta.

Przykładem może być refaktoryzacja, która ułatwia zrozumienie i zmianę kodu. W rezultacie zmniejsza się prawdopodobieństwo wprowadzenia defektów do kodu, co pozwala szybciej dostarczyć większą wartość bez konieczności naprawiania błędów i rozumieć za co ten kod odpowiada.

Małe kroki – baby steps – duże zmiany są ryzykowne. Extreme Programming zmniejsza to ryzyko poprzez wprowadzanie zmian małymi krokami na wszystkich poziomach.

Developerzy piszą kod małymi partiami, korzystając z TDD (Test-Driven Development). Łączą swój kod z kodem z głównej gałęzi kilka razy dziennie, a nie tylko co kilka tygodni czy nawet miesięcy. Sam rozwój projektu odbywa się w krótkich iteracjach, a nie w długotrwałych fazach.

Przyjęta odpowiedzialność – w programowaniu ekstremalnym odpowiedzialność powinna być zaakceptowana, nigdy – przypisywana. Powinno towarzyszyć jej upoważnienie do podejmowania decyzji dotyczących tego, za co jest się odpowiedzialnym. To działa również w drugą stronę. Nie chcemy przecież, aby ludzie podejmowali decyzje, jeśli nie muszą się liczyć z ich konsekwencjami.

Przeczytaj również: Jaka jest rola testera w zespole scrumowym?

Role w programowaniu ekstremalnym

Według Kenta Becka doświadczony, czy inaczej – dojrzały zespół XP nie powinien opierać się na sztywno zdefiniowanych rolach. Należy pamiętać, że role mogą być pomocne dla poczatkujących zespołów. Z czasem mogą jednak przeszkadzać we współpracy.

Role i ich odpowiedzialności w kontekście programowania ekstremalnego:

Klient

Najlepiej byłoby, gdyby na miejscu był prawdziwy klient / Product Owner, który odpowiadałby na pytania, ustalał priorytety dla historyjek lub współpracował przy testach akceptacyjnych.

Developerzy

W zespołach XP programiści wykonują estymaty dostarczenia zadań (tasks) i historyjek (User Story), piszą testy i zajmują się implementacją.

Trener (Coach)

Posiadanie osoby pełniącej tę rolę w podejściu XP nie jest wymagane. Taką rolę w zespole może pełnić osoba, która ma już doświadczenie w programowaniu ekstremalnym. Zadaniem trenera jest upewnienie się, że zespół stosuje dobre praktyki, przemieniając je potem w nawyki i nie wracając do starych sposobów tworzenia oprogramowania.

Tracker

Jest to osoba, która zajmuje się śledzeniem postępu zespołu oraz rozmawia z każdym developerem. Konsultacje z każdym członkiem zespołu pozwalają na identyfikację blockerów, wąskich gardeł oraz znalezienie sposobów na ich rozwiązanie. Do obowiązków Trackera należy również prezentowanie metryk, pokazujących w jaki sposób radzi sobie zespół, jaka jest jego prędkość (velocity), i wykresów spalania (burndown charts). Często w celu prowadzenia takich metryk korzysta się z już gotowych rozwiązań, typu tablica scrumowa czy kanbanowa, które automatycznie obliczają statystyki.

Procesy w programowaniu ekstremalnym

Programowanie ekstremalne obejmuje 5 procesów, które są powtarzane iteracyjnie:

• Planowanie – pierwszy etap, kiedy klient spotyka się z zespołem developerskim i przedstawia swoje wymagania w postaci historyjek (User Stories), aby opisać pożądany rezultat. Zespół następnie wycenia historyjki i tworzy release plan podzielony na iteracje potrzebne do dostarczenia wymaganej funkcjonalności, część po części. Jeżeli niektóre historyjki nie mogą zostać wycenione, to można wprowadzić tzw. “Spike”, oznacza to, że potrzebny jest dalszy research i, często, rozbicie zadania na mniejsze historyjki.
• Projektowanie – jest to relatywnie część procesu planowania. Jednak może być przeniesiona do osobnego procesu, aby podkreślić ważność tego kroku. Jest to związane z jedną z głównych wartości XP, mianowicie z prostotą. Dobry projekt wprowadza logikę i strukturę do systemu, pozwalając uniknąć niepotrzebnej złożoności i nadmiarowości.
• Implementacja – podczas tego procesu faktycznie pisze się kod, stosując konkretne praktyki XP, takie jak: ustalone standardy pisania kodu, Pair Programming czy Continuous Integration.
• Testowanie – to podstawa programowania ekstremalnego. Jest to aktywność, która obejmuje zarówno testy jednostkowe, testy automatyczne, jak i testy akceptacyjne przeprowadzone przez klienta. Testy klienta są wykonywane w celu sprawdzenia, czy system spełnia początkowe wymagania.
• Słuchanie – polega na ciągłej komunikacji i feedbacku. Klienci i project managerowie są zaangażowani w opisanie logiki biznesowej i jej oczekiwanej wartości dla biznesu.

Plusy i minusy Extreme Programming

Programowanie ekstremalne można zastosować w każdym projekcie rozwoju oprogramowania, jednak należy rozważyć dobre i złe strony tego podejścia i różnice pomiędzy innymi frameworkami zwinnymi.

Zalety programowania ekstremalnego

Użycie XP może być korzystne i pomaga skrócić czas i zmniejszyć koszt rozwoju oprogramowania:

• Stabilność – otrzymujemy stabilny, dobrze działający system dzięki refaktoryzacjii stałemu testowaniu.
• Czysty, zwięzły kod – jest łatwy do czytania i do zmiany w przyszłości, jeżeli zajdzie taka potrzeba. Pomaga w tym zwłaszcza wspomniana wcześniej prostota.
• Zredukowana dokumentacja – obszerne pliki z wymaganiami są zastępowane historyjkami.
• Rezultat spełniający oczekiwania –zaangażowanie klienta w proces rozwoju i testowania może bezpośrednio wpłynąć na rezultat. Gwarantuje spełnienie założeń i wymagań biznesowych, przez co klient otrzyma dokładnie to, czego potrzebował.
• Brak nadgodzin – maksymalna redukcja lub kompletny brak nadgodzin jest możliwa dzięki krótkim iteracjom pozwalającym skupić się na konkretnych wymaganiach i dostarczaniu tego, czego klient faktycznie oczekuje. Im dłuższa iteracja, tym większe ryzyko, że wymagania nie zostaną właściwie zrozumiane i będzie trzeba poświęcić dodatkowy czas na poprawienie rozwiązania, które np. tworzyło się na ich podstawie przez kilka tygodni.
• Mniej błędów – Pair Programming pozwala na dostarczenie produktu lepszej jakości, który posiada mniej błędów. Jednocześnie współpraca pomiędzy developerami może wpłynąć pozytywnie na rozumienie założeń i ich pewność co do wymagań.
• Transparentność – ciągła komunikacja zapewnia wysoki poziom przejrzystości i odpowiedzialności oraz pozwala całemu zespołowi być na bieżąco z postępami i zmianami w projekcie.
• Szybkość dostarczania produktu – minimalistyczne, iteratywne podejście do rozwoju oprogramowania przekłada się na to, że bardzo szybko mogą zostać dostarczone gotowe, zdatne do użytku elementy. Dodatkowo – zaimplementowane zostaną tylko niezbędne funkcjonalności.

Wady programowania ekstremalnego

Z drugiej strony, programowanie ekstremalne posiada wiele wad, które trzeba wziąć pod uwagę przy wyborze tego podejścia do projektu:

• Rozmyty efekt końcowy – bardzo często w trakcie trwania projektu klient nie ma jeszcze czystego obrazu (clear picture) końcowego rezultatu. Brak takiej wizji sprawia, że jest prawie niemożliwe wykonanie dokładnych estymat zakresu wymaganej pracy, kosztu oraz czasu.
• Niejasne wymagania – dokumentacja może być niedostateczna oraz nie zawierać jasnych i przejrzystych wymagań i specyfikacji. Prowadzi to często do rozszerzenia zakresu projektu.
• Większy wpływ czynnika ludzkiego – Pair Programming wymaga więcej czasu i nie zawsze przynosi oczekiwane rezultaty. Może się tak dziać ze względu na niezgodności charakterów.
• Próg wejścia – szybkie odejście od tradycyjnych metodyk rozwoju oprogramowania do programowania ekstremalnego wymaga znaczących zmian strukturalnych.
• Ograniczenia związane z pracą zdalną – programowanie ekstremalne działa najlepiej w przypadku zespołów i klientów pracujących na miejscu (on-site), gdyż wymaga
  prowadzenia spotkań face to face. Ogranicza to użycie XP w zdalnych zespołach rozproszonych.
• Więcej spotkań – częste spotkania z klientami zwykle zajmują sporo czasu, który mógłby zostać przeznaczony na właściwą implementację.
• Stres – czasami klienci nie mają czasu, chęci czy doświadczenia, żeby brać udział w rozwoju produktu. Biorąc pod uwagę naglące terminy, może to generować stres – zwłaszcza gdy zespół nie otrzymuje wartościowego feedbacku albo gdy nieposiadająca żadnej lub minimalnej wiedzy na temat procesów osoba próbuje zarządzać developerami.

Kiedy użyć programowania ekstremalnego?

Programowanie ekstremalne sprawdzi się w zespołach, w których:

• Funkcjonalność systemu, nad którym pracują, będzie się zmieniać co kilka miesięcy.
• Stale zmieniają się wymagania lub współpracuje się z klientem, który nie do końca wie, czego oczekuje od systemu.
• Chce się ograniczyć ryzyko związane z projektem i uniknąć napiętych terminów.
• Zespół developerski jest mały (najlepiej od 2 do 12 osób).
• Możliwa jest bliska współpraca z klientem.
• Możliwe jest zastosowanie testów jednostkowych, automatycznych i funkcjonalnych.

Podsumowując…

Programowanie ekstremalne sprawdzi się w projektach, w których często zmieniają się wymagania. Może się to wiązać z większą liczbą spotkań, koniecznością zaangażowania klienta celem uzyskania informacji zwrotnej oraz potrzebą wprowadzenia zmian w strukturze zespołu. Jeśli jednak współpraca i ciągły rozwój są priorytetem dla twojego zespołu, to warto spróbować programowania ekstremalnego. To wysoce elastyczne podejście opiera się na ciągłym feedbacku od klientów, przewiduje błędy, jakie mogą pojawić się po drodze i wymaga współpracy developerów ze względu na techniki programowania w parach. Programowanie ekstremalnie nie tylko zapewnia dostarczenie produktu przynoszącego wartość dla biznesu, ale także zwiększa produktywność zespołów developerskich.