Z artykułu dowiesz się:
- Co to jest extreme programming
- Jakie są zasady programowania ekstremalnego
- Jak przebiega programowanie ekstremalne
- Czym różni się extreme programming od Scrum
- Jakie są zalety i wady XP
O co chodzi w extreme programming?
Programowanie ekstremalne (XP) jest jedną ze zwinnych metodyk, ale skoncentrowaną stricte na wytwarzaniu programowania, w przeciwieństwie np. do Scrum. Celem jest oczywiście dostarczenie programowania wysokiej jakości precyzyjnie dostosowanego do zmieniających się wymagań biznesowych. Kluczowa jest więc elastyczność pracy i natychmiastowa, właściwa reakcja na feedback, a język programowania jest drugorzędny. W extreme programming duży nacisk kładzie się na aspekty techniczne dotyczące rozwoju oprogramowania. Istnieją konkretne zasady, według których developerzy pracują, co pozwala utrzymać porządek w zespole i projekcie. Chodzi o dobre praktyki programowania.
W programowaniu ekstremalnym duże znaczenie ma umiejętne płynne wprowadzanie zmian – to, co już powstało, nie jest stworzone na zawsze. Zespół developerów ma ustalony pewien plan, który nie jest nie do ruszenia. W razie potrzeby, dla dobra projektu, można wprowadzać w nim zmiany. Elastyczność – to cecha, która wyraźnie wyróżnia XP spośród innych zwinnych metodyk zarządzania projektami. Właśnie dlatego jedną z kluczowych wartości extreme programming jest komunikacja zarówno wewnątrz zespołu, jak również na linii zespół – klient. Każdy feedback ma taką samą wartość i należy się bliżej przyjrzeć problemowi czy obszarowi, którego dotyczy. Źródłem cennego feedbacku są też testy. Czasem ich napisanie jest trudne, co wynika ze skomplikowanej architektury, która wymaga uproszczenia. Ponadto zdarza się, że zespół otrzymuje więcej feedbacków, niż jest w stanie obsłużyć. Jest wtedy ryzyko, że pominięty zostanie ten najważniejszy. Należy się wówczas zatrzymać i zastanowić, dlaczego tak się dzieje i z jakiego powodu napływa tak dużo informacji zwrotnych.
Przy programowaniu ekstremalnym trzeba przyjąć pewne wartości, bez których ta metodyka jest niemożliwa do wdrożenia. Po pierwsze prostota – robimy to, co jest od nas wymagane, klient ma płacić tylko za to, co jest potrzebne. Po drugie komunikacja – rozmawiamy ze sobą, konsultujemy pomysły i rozwiązania. Po trzecie feedback – otwarcie mówimy o swoich obawach i spostrzeżeniach. Inicjujemy rozmowę na temat tego, co wymaga poprawy i udoskonalenia, aby uniknąć kolejnych problemów na dalszych etapach projektowania. Po czwarte szacunek – każdy członek zespołu ma prawo wyrazić swoje zdanie, a pozostali mają obowiązek je przyjąć i zaakceptować. Po piąte szczerość i odwaga – jesteśmy otwarci, nie zostawiamy dla siebie cennych spostrzeżeń, które mogłyby mieć wpływ na rozwój naszej wspólnej pracy.
Jak łatwo można zauważyć, extreme programming to przede wszystkim współpraca, nie ma tutaj miejsca na indywidualne działania, to nie projekt realizowany w pojedynkę, a sztafeta, która ma jeden wspólny cel i do niego dąży. Właśnie dlatego niektórym trudno się odnaleźć w tej metodyce.
Żelazne zasady programowania ekstremalnego
Gdyby nie wprowadzone w programowaniu ekstremalnym zasady, najprawdopodobniej w zespole zapanowałby chaos. Zasady to porządek, oczywiście jeśli się ich trzymamy. W XP ważni są ludzie, zarówno Ci po stronie projektu, jak również Ci, dla których programowanie powstaje. Jeśli w zespole istnieje poczucie przynależności i wzajemny szacunek, łatwiej jest dostrzec człowieka również po drugiej stronie, a przecież programowanie jest tworzone przez ludzi dla ludzi. W programowaniu ekstremalnym unika się rozwiązań, które przynoszą korzyści jednej ze stron, ale kosztem drugiej. To zawsze jest relacja win-win. Przykładem może być stworzenie obszernej dokumentacji, aby lepiej przekazać specyfikę projektu drugiej osobie, odciążając tym samym inną, nikt w zespole nie pozostaje sam sobie.
To, co jest naprawdę ważne w programowaniu ekstremalnym, to proces udoskonalania. Nie chodzi o to, aby już na początku projektu dążyć do perfekcji, w zupełności wystarczy wdrożenie po prostu dobre. Potem, wraz z postępem projektowym pojawiają się nowe pomysły, zespół się uczy na żywym organizmie, dzięki czemu dostrzega te obszary, który wymagają szczególnej uwagi. Dzięki znajomości już istniejącego produktu developerzy są w stanie go doskonalić i zmieniać. Związana jest z tym metoda małych kroków. Kod jest pisany małymi partiami, a rozwój projektu odbywa się w krótkich iteracjach, nie są to długotrwałe fazy. W ten sposób łatwiej jest uniknąć ryzykownych zmian i wdrożeń, które mogą negatywnie wpłynąć na cały projekt.
W extreme programming stosuje się ponadto zasadę redundancji. Do rozwiązania krytycznego problemu stosuje się wiele taktyk, ponieważ nie istnieje jedna właściwa, która pozwoliłaby go zlikwidować. Właśnie dlatego, aby osiągnąć zamierzoną jakość, w zespole prowadzone są liczne testy i programowanie w parach.
Proces programowania ekstremalnego
Programowanie ekstremalne składa się z kilku procesów, które powtarzalne są iteracyjnie. Oznacza to, że takie same działania podejmowane są w identycznej kolejności tyle razy, aż do osiągnięcia zamierzonej jakości.
Pierwszy etap to planowania, wszystko przecież zaczyna się od „jakiegoś” planu. Developerzy spotykają się z klientem, który opowiada im o swoich celach, pomysłach, wymaganiach i oczekiwaniach. Otrzymuje on wycenę, a zespół tworzy release plan zawierający poszczególne etapy pracy. Potem następuje relatywna część, czyli projektowanie. Przy dobrym projekcie jest duża szansa, że do systemu zostanie wprowadzona logika i struktura, a to znacznie ułatwia pracę i pozwala uniknąć niepotrzebnej nadmiarowości. Trzeci etap to implementacja, czyli ten czas, kiedy naprawdę pisze się kod, wykorzystując przy tym dobre praktyki ekstremalnego programowania. Po implementacji przychodzi czas na testowanie, które obejmuje testy
automatyczne, jednostkowe i akceptacyjne przeprowadzane przez samego klienta. Dlaczego klient testuje oprogramowanie? To proste, aby sprawdzić, czy naprawdę spełnia jego oczekiwania, nikt nie chce kupować kota w worku. I na koniec słuchanie. To ten etap, kiedy zewsząd napływają feedbacki. Czasem jest ich niewiele, innym razem długa lista, w której można się pogubić. Im więcej informacji zwrotnych, tym najprawdopodobniej więcej niedoskonałości i defektów w projekcie.
XP a Scrum
Można by się zastanawiać, po co XP, skoro mamy Scrum, który cechuje się podobnymi założeniami. „Podobne” to nie „takie same”, a różnice pomiędzy tymi dwoma metodykami są znaczące. Przede wszystkim programowanie ekstremalne jest ściśle związane z procesem programowania, a Scrum można zastosować przy każdym projekcie, wszędzie tam, gdzie sprawdzi się podejście iteracyjne. To dowodzi, że XP powstało z uwzględnieniem specyfiki procesu tworzenia oprogramowania, nie jest metodyką uniwersalną i ściśle nawiązuje do pracy w zespole developerów, odpowiada na jej potrzeby, wyzwania i problemy. Znacząca różnica pomiędzy XP a Scrum polega więc na tym, że extreme programming kładzie duży nacisk na dobre praktyki programistyczne.
Co ciekawe, Scrum jest frameworkiem, który wymaga uzupełniania o własne metodologie. Nic więc nie stoi na przeszkodzie, aby Scrum połączyć z programowaniem ekstremalnym. Wiele zespół stosuje taki tandem i skutkuje to naprawdę doskonałymi efektami.
Jasna i ciemna strona extreme programming
No dobrze, ale właściwie dlaczego mam wybrać extreme programming, a nie Scrum czy Waterfall? Nie możemy uznać, że XP to jedyna słuszna metodyka zarządzania projektem w zespole developerów, ale z pewnością ma kilka znaczących plusów, które budują jego przewagę nad konkurencją.
Extreme programming zapewnia stabilność systemu, co jest następstwem stałego testowania i monitorowania procesu projektowego. Powstały kod jest łatwy do modyfikacji w przyszłości, co wynika z jego prostoty – wszystko maksymalnie upraszczamy. Co więcej, brak jest obszernej dokumentacji, która została zastąpiona historyjkami, jest ciekawiej i zdecydowanie bardziej przystępnie. Dzięki temu, że klient jest zaangażowany w projekt, a projektowanie to współpraca wielu jednostek, ostatecznie produkt końcowy spełnia początkowe oczekiwania i założenia. Klient otrzymuje to, czego potrzebuje, w najlepszej wersji. Przy programowaniu ekstremalnym pojawia się mniej błędów. Jest to możliwe dzięki małym krokom, co pozwala na lepsze i sprawniejsze kontrolowanie poszczególnych etapów. Zmiany i modyfikacje można wprowadzać szybciej i unikać tym samym rozrastania się błędu, który później trudniej jest zniwelować. XP wyróżnia ponadto transparentność, co z kolei jest związane ze stałą komunikacją, dzięki czemu każdy z członków zespołu jest na bieżąco z postępami w projekcie. Ale…
Programowanie ekstremalne ma również wady, które sprawiają, że nie każdy zespół decyduje się na takie podejście. Problemem może okazać się brak czystego obrazu rezultatu końcowego. Jeśli klient nie sprecyzuje, co dokładnie chce otrzymać, trudno jest stworzyć ostateczną wycenę i zaplanować prace w czasie. XP nie jest najlepszym wyborem, jeśli praca developerów odbywa się tylko w trybie zdalnym. To metodyka, która wymaga stałych spotkań, patrzenia w jeden monitor komputera, konsultacji w realu i burzy mózgów na każdym etapie projektu. Trudno jest mówić o tak ścisłej współpracy, jaką zakłada extreme programming, jeśli członkowie zespołu pracują zdalnie. Może się również okazać, że XP nie zda rezultatu, jeśli klient nie będzie wykazywał wystarczająco dużej chęci do współpracy i rozwoju produktu. On jest tutaj jednym z kluczowych czynników, bez niego projekt prowadzony w tej metodyce po prostu nie może się udać.
Na szczęście mamy dzisiaj wybór. Możemy żonglować metodykami zarządzania projektem, dopasowując je do konkretnych przedsięwzięć. Extreme programming wymaga dużego zaangażowania developerów nie tylko w samo projektowanie, ale i komunikację. To nie jest praca indywidualna, tutaj pracuje cały zespół i właśnie od tego, jak to robi, zależy powodzenie projektu. Ta metodyka sprawdzi się dobrze przy projektach, które z założenia mają się często zmieniać. Kluczowe jest też, aby możliwa była bliska współpraca z klientem. Wdrożenie XP w takich projektach jest na pewno ekstremalnie skuteczne.
