Ekstremalne programowanie (XP) to zwinna metodologia rozwoju oprogramowania. Podobnie jak inne zwinne metodyki, XP ma swoje unikalne narzędzia, procesy i role. Twórca XP, amerykański programista Kent Beck, nie wynalazł nic całkowicie nowego, lecz wziął najlepsze praktyki zwinnego rozwoju i wzmocnił je do ekstremum, stąd nazwa Ekstremalne programowanie.
Autor metodologii, Kent Beck, kierował projektem Chrysler Comprehensive Compensation System pod koniec lat 90., gdzie po raz pierwszy zastosował praktyki XP. Udokumentował swoje doświadczenia i stworzony koncept w książce “Ekstremalne programowanie wyjaśnione”, opublikowanej w 1999 roku. Książka ta doczekała się kolejnych, które szczegółowo opisują praktyki XP. Wśród współautorów rozwoju metodologii znajdują się Ward Cunningham, Martin Fowler i inni.
W przeciwieństwie do innych zwinnych metodologi, XP jest wykorzystywany wyłącznie w rozwoju oprogramowania. Nie może być stosowany w innych branżach ani w życiu codziennym, jak Scrum, Kanban czy Lean.
Celem XP jest radzenie sobie z nieustannie zmieniającymi się wymaganiami dla produktu oprogramowania oraz podnoszenie jakości rozwoju. Dlatego XP jest odpowiedni dla skomplikowanych i niepewnych projektów.
XP obraca się wokół czterech podstawowych działań: kodowania, testowania, projektowania i słuchania. Dodatkowo, Ekstremalne programowanie ma podstawowe wartości: prostotę, komunikację, informację zwrotną, odwagę i szacunek.
13 Praktyk Ekstremalnego Programowania
1. Cały Zespół
Wszyscy uczestnicy projektu korzystający z XP pracują jako jeden zespół. Zespół ten musi obejmować reprezentanta klienta, najlepiej prawdziwego użytkownika końcowego znającego się na biznesie. Klient ustala wymagania dotyczące produktu i priorytetyzować funkcjonalność. Analitycy biznesowi mogą wspierać klienta. Z perspektywy wykonawców zespół obejmuje programistów, testerów, czasami trenera prowadzącego zespół oraz menedżera dostarczającego zasoby.
2. gra planistyczna
Planowanie w XP odbywa się w dwóch etapach: planowanie wydania i planowanie iteracji.
- Planowanie Wydania: Zespół programistyczny spotyka się z klientem, aby określić pożądane funkcje na następne wydanie, zazwyczaj w ciągu 2 – 6 miesięcy. Ponieważ wymagania klienta są często niejasne, programiści je wyjaśniają i dzielą na zadania, które można zrealizować w ciągu jednego dnia lub szybciej. Klient musi zrozumieć środowisko operacyjne, w którym produkt będzie działał.
Zadania są zapisywane na kartach, a klient je priorytetyzuje. Programiści następnie szacują czas potrzebny na każde zadanie. Gdy zadania są opisane i oszacowane, klient przegląda dokumentację i zatwierdza rozpoczęcie prac. Dla sukcesu projektu kluczowe jest, aby klient i zespół programistyczny działali na tych samych zasadach: klient wybiera naprawdę niezbędną funkcjonalność w ramach budżetu, a programiści odpowiednio dostosowują wymagania klienta do swoich możliwości. - Planowanie Iteracji: Przeprowadzane co dwa tygodnie, czasami rzadziej lub częściej. Klient jest obecny, aby określić funkcjonalność dla następnej iteracji i wprowadzać zmiany w wymaganiach produktu.
3. Małe Wydania
Wydania XP są częste, ale z ograniczoną funkcjonalnością. To podejście ułatwia testowanie i utrzymanie operacyjności systemu i zapewnia klientowi funkcjonalność o wartości biznesowej w każdej iteracji.
4. Testy Klienta
Klient określa zautomatyzowane testy akceptacyjne w celu sprawdzenia funkcjonalności produktu. Zespół pisze te testy i wykorzystuje je do testowania kodu.
5. Kolektywne Właścicielstwo Kodu
W XP każdy programista może modyfikować każdą część kodu, ponieważ kod nie należy do autora, lecz do całego zespołu.
6. Ciągła Integracja
Nowe części kodu są integrowane z systemem natychmiast — zespoły XP wydają nową wersję co kilka godzin lub jeszcze częściej. Ta praktyka zapewnia, że wpływ ostatnich zmian na system jest widoczny natychmiast. Jeśli nowa część kodu coś psuje, identyfikacja i naprawienie błędu są znacznie łatwiejsze.
7. Standardy Kodowania
W przypadku kolektywnego właścicielstwa kodu, przyjęcie wspólnych standardów kodowania jest kluczowe, aby kod wyglądał tak, jakby był napisany przez jednego profesjonalistę. Zespoły mogą opracować własne standardy lub przyjąć istniejące.
8. Metafora Systemu
Metafora systemu to porównanie z czymś znanym, aby stworzyć wspólną wizję w zespole. Typowo osoba opracowująca architekturę i postrzegająca system w całości wymyśla metaforę.
9. Zrównoważone Tempo
Zespoły XP pracują z maksymalną wydajnością, utrzymując jednocześnie zrównoważone tempo. Ekstremalne programowanie zniechęca do nadgodzin i promuje 40-godzinny tydzień pracy.
10. Rozwój Napędzany Testami (TDD)
Jedna z najtrudniejszych praktyk w XP. Programiści piszą testy przed napisaniem kodu, który ma być testowany. To podejście zapewnia, że każdy kawałek funkcjonalności jest w pełni pokryty testami. Gdy programiści zatwierdzają kod, testy jednostkowe uruchamiają się natychmiast, i wszystkie testy muszą przejść, co zapewnia, że zespół zmierza w dobrym kierunku.
11. Programowanie w Parze
Wyobraź sobie dwóch programistów pracujących przy jednym komputerze nad jednym kawałkiem funkcji. Ta praktyka to programowanie w parze, najbardziej kontrowersyjna praktyka w XP. Przysłowie “dwie głowy są lepsze niż jedna” dobrze ilustruje jej istotę. Spośród dwóch rozwiązań problemu wybierane jest najlepsze, kod jest natychmiast optymalizowany, a błędy wychwytywane są zanim wystąpią, co skutkuje czystym kodem rozumianym przez obu programistów.
12. Prosty Projekt
Prosty projekt w XP oznacza robienie tylko tego, co jest potrzebne teraz, bez próby przewidywania przyszłej funkcjonalności. Prosty projekt i ciągła refaktoryzacja tworzą efekt synergii — gdy kod jest prosty, łatwiej go zoptymalizować.
13. Refaktoryzacja
Refaktoryzacja jest ciągłym procesem poprawy projektu systemu w celu spełnienia nowych wymagań. Obejmuje usuwanie duplikacji kodu, zwiększanie spójności i redukcję sprzężeń. XP nakłada obowiązek ciągłej refaktoryzacji, więc projekt kodu zawsze pozostaje prosty.
Zalety i Wady XP
XP jest kontrowersyjne i często krytykowane przez tych, którzy nie zdołali go wdrożyć. Jednak jego korzyści są oczywiste, gdy zespół w pełni wykorzystuje przynajmniej jedną praktykę XP.
Korzyści z dążenia do XP obejmują:
- Zadowolenie Klienta: Klienci otrzymują produkt, którego potrzebują, nawet jeśli na początku nie mają jasnej wizji.
- Elastyczność: Zespół szybko wprowadza zmiany w kodzie i dodaje nową funkcjonalność dzięki prostej strukturze kodu, częstemu planowaniu i wydaniach.
- W niezawodność: Kod zawsze działa dzięki ciągłemu testowaniu i ciągłej integracji.
- Łatwość Utrzymania: Zespół może łatwo utrzymać kod, ponieważ jest pisany według jednego standardu i nieprzerwanie refaktoryzowany.
- Wydajność: Szybkie tempo rozwoju dzięki programowaniu w parze, braku nadgodzin i zaangażowaniu klienta.
- Wysoka Jakość Kodu
- Minimalizacja Ryzyka: Ryzyko rozwoju jest zredukowane, ponieważ odpowiedzialność jest sprawiedliwie rozłożona, a projekt nie jest zagrożony przez odejście lub przybycie członków zespołu.
- Efektywność Kosztów: Koszty rozwoju są niższe, ponieważ zespół skupia się na kodzie, a nie na dokumentacji i spotkaniach.
Pomimo zalet, XP nie zawsze działa i ma kilka słabości:
- Zaangażowanie Klienta: Sukces zależy od zaangażowania klienta, co może być trudne do osiągnięcia.
- Nieprzewidywalne Terminy: Trudno przewidzieć koszty czasowe projektu, ponieważ pełna lista wymagań jest nieznana na początku.
- Zależność od Poziomu Umiejętności: XP w dużej mierze zależy od poziomu umiejętności programistów i najlepiej działa w przypadku doświadczonych profesjonalistów.
- Opór Zarządzania: Zarządzanie często sprzeciwia się programowaniu w parze, kwestionując potrzebę opłacania dwóch programistów zamiast jednego.
- Koszt: Częste spotkania z programistami mogą być kosztowne dla klientów.
- Zmiany Kulturowe: Wdrożenie XP wymaga znacznych zmian kulturowych.
- Brak Struktury: Brak struktury i dokumentacji XP sprawia, że nie nadaje się do dużych projektów.
- Wymagania Niefunkcjonalne: Wymagania funkcyjne są trudne do opisania jako historie użytkowników w zwinnych metodykach.
Zasady XP
W swojej pierwszej książce Kent Beck nakreślił następujące zasady XP: prostota, komunikacja, informacja zwrotna i odwaga. W kolejnej edycji dodał piątą zasadę — szacunek.1. Prostota
Rozwój XP zaczyna się od najprostszego rozwiązania, które spełnia obecne potrzeby funkcjonalne. Członkowie zespołu biorą pod uwagę tylko to, co trzeba zrobić teraz i nie wprowadzają funkcjonalności, która może być potrzebna w przyszłości.
2. Komunikacja
Komunikacja w XP odbywa się na żywo, a nie przez dokumentację. Zespół aktywnie komunikuje się ze sobą i z klientem.
3. Informacja zwrotna
Informacja zwrotna w XP jest wdrażana na trzy sposoby:
- Informacja zwrotna systemu: Dzięki stałemu testowaniu modułów.
- Informacja zwrotna od klienta: Klient jest częścią zespołu i uczestniczy w tworzeniu testów akceptacyjnych.
- Informacja zwrotna od zespołu: Podczas planowania, dotycząca szacunków czasu rozwoju.
4. Odwaga
Niektóre praktyki XP są tak nietypowe, że wymagają odwagi i stałej samokontroli.5. Szacunek
Szacunek w XP oznacza szanowanie zespołu oraz szacunek do samego siebie. Członkowie zespołu nie powinni wprowadzać zmian łamiących kompilację, testy modułowe, ani spowalniających pracę kolegów. Każdy członek dąży do najwyższej jakości kodu i projektu.
Wdrożenie XP i Przepływ Pracy
Kent Beck zaleca wdrażanie XP w celu rozwiązywania problemów projektowych. Zespół wybiera najpilniejszy problem i rozwiązuje go przy użyciu jednej z praktyk XP. Następnie przechodzi do następnego problemu, korzystając z innej praktyki. Takie podejście zapewnia, że problemy motywują do przyjęcia XP, a zespół stopniowo opanowuje wszystkie narzędzia metodologii.
Aby wprowadzić XP w istniejącym projekcie, stopniowo przyjmuj jego praktyki w następujących obszarach:
- Testowanie: Zespół tworzy testy przed napisaniem nowego kodu i stopniowo refaktoryzuje stary kod.
- Projektowanie: Zespół ciągle refaktoryzuje stary kod, zazwyczaj przed dodaniem nowej funkcjonalności.
- Planowanie: Zespół musi ściśle współpracować z klientem.
- Zarządzanie: Menedżerowie zapewniają, że wszyscy członkowie zespołu przestrzegają nowych zasad.
- Rozwój: Rozpocznij od organizacji stanowisk roboczych do programowania w parach i zachęcaj pary do programowania przez większość czasu.
Przykład Przepływu Pracy z Wykorzystaniem XP
Kto Korzysta z XP
Według badania VersionOne z 2016 roku, tylko 1% zwinnych firm stosuje XP w czystej postaci. Kolejne 10% korzysta z hybrydy Scrum i XP.Chociaż XP nie jest najczęściej stosowaną metodologią, jego praktyki są wykorzystywane przez większość firm stosujących zwinne metodologie. Na przykład, Pivotal Software, Inc. przypisuje swój sukces XP.
Pivotal Software, Inc.
Pivotal Software, Inc. rozwija analitykę biznesową opartą na dużych zbiorach danych i świadczy usługi doradcze. Ich produkty są używane przez korporacje takie jak Ford, Mercedes, BMW, GAP, Humana, duże banki, agencje rządowe i firmy ubezpieczeniowe.
Pivotal opowiada się za zwinnych metodologiami jako niezbędnymi dla nowoczesnego rozwoju. Spośród zwinnych wariantów wybrali XP, metodologię korzystną zarówno dla klientów, jak i zespołów programujących. Ich dzień roboczy zaczyna się od spotkań codziennych i kończy o 18:00 — bez nadgodzin. Pivotal korzysta z gier planistycznych, programowania w parach, ciągłego testowania, ciągłej integracji i innych praktyk XP.
Czego Przeczytać, aby Zrozumieć XP
- “Ekstremalne programowanie wyjaśnione”, “Planowanie Ekstremalnego Programowania”, “Rozwój napędzany testami” autorstwa Kenta Becka: Książki te, napisane przez twórcę XP, dostarczają szczegółowego zrozumienia metodologii i jej zalet.
- “Refaktoryzacja: Poprawa Projektu Istniejącego Kodu” autorstwa Martina Fowlera: Książka współautora XP wyjaśniająca zasady i techniki refaktoryzacji.
- “Ekstremalne Programowanie Zastosowane: Gra na Wygraną” autorstwa Kena Auer i Roya Millera: Praktyczny przewodnik po praktykach XP z przykładami.
Narzędzia do Wdrażania XP w Zespołach
Redmine
Darmowy, otwarty menedżer zadań z takimi funkcjami jak wsparcie dla wielu projektów, elastyczne zarządzanie zadaniami, wykresy Gantta, śledzenie czasu, zarządzanie dokumentacją i tworzenie zadań za pośrednictwem e‑maila.
Basecamp
Prosta, przyjazna użytkownikowi usługa do współpracy przy projektach, obejmująca menedżera zadań, tablice wiadomości, wbudowany czat, przechowywanie plików i kalendarz.
Jira
Robustna usługa zaprojektowana dla twórców projektów zwinnych, łącząca śledzenie błędów i narzędzia do zarządzania projektami z wieloma funkcjami i opcjami synchronizacji.
Worksection
Bezpieczna usługa do pracy projektowej, umożliwiająca ustalanie zadań i kontrolę procesów, śledzenie korespondencji, dostosowywanie filtrów, śledzenie czasu i finansów oraz zarządzanie plikami.
Wnioski
Ekstremalne programowanie to zwinna metodologia skupiająca się na produkcji wysokiej jakości, funkcjonalnego kodu przy prostszej architekturze. Jej celem jest redukcja niepewności w projektach i elastyczna reakcja na zmieniające się wymagania produktu.
XP jest wyłącznie dla rozwoju oprogramowania i nie może być dostosowane do innych branż.
Jest jedną z najtrudniejszych metodologii do wdrożenia z powodu trzynastu praktyk. Jednakże praktyki te są szeroko stosowane w zwinnych projektach, co dowodzi ich skuteczności.
Autorzy zalecają stopniowe opanowywanie praktyk XP podczas rozwiązywania problemów projektowych. Jeśli dostrzegasz korzyści, kontynuuj w tym samym duchu. Nie ma obowiązku wdrażania XP w sposób absolutny. W końcu zwinne metodologie powinny być elastyczne w zastosowaniu — dostosowując się do potrzeb konkretnego zespołu projektowego.