Programowanie ekstremalne (XP) przynosi rezultaty, ale czy jest odpowiednie dla Ciebie?

Jeśli termin „ekstremalne programowanie” kojarzy Ci się z igrzyskami X i sportami akcji, nie jesteś daleko od prawdy. Programowanie ekstremalne (XP) to w rzeczywiście dość ekstremalny sposób programowania. Podobnie jak inne zwinne metody tworzenia oprogramowania, XP wykorzystuje elastyczne, oparte na testach podejście do inżynierii oprogramowania. Ale w przeciwieństwie do innych metod, ekstremalne programowanie ma surowe zasady i wartości przewodnie, które określają sposób wykonywania pracy. 

Czym jest programowanie ekstremalne (XP)?

Ekstremalne programowanie to metoda zarządzania projektami Agile, która stawia na szybkość i prostotę dzięki krótkim cyklom rozwoju i mniejszej ilości dokumentacji. Strukturę procesu określa pięć wartości przewodnich, pięć zasad i 12 praktyk XP (które omówimy w dalszej części tego artykułu). 

Podobnie jak inne metody Agile, XP to metodologia tworzenia oprogramowania podzielona na sprinty. Struktury Agile opierają się na procesie iteracyjnym – struktura jest ukańczana i weryfikowana po każdym sprincie, udoskonalana w celu osiągnięcia maksymalnej wydajności i dostosowywana do zmieniających się wymagań. Podobnie jak inne metody Agile, XP pozwala programistom reagować na historie klientów, dostosowywać się do nich i wprowadzać zmiany w czasie rzeczywistym. Jednak XP jest znacznie bardziej zdyscyplinowana, ponieważ wykorzystuje częste przeglądy kodu i testy jednostkowe, aby szybko wprowadzać zmiany. Jest również bardzo kreatywna i oparta na współpracy, ponieważ na wszystkich etapach rozwoju priorytetowo traktuje pracę zespołową.

Programowanie ekstremalne a Scrum

Scrum to kolejny powszechnie stosowany rodzaj metodologii Agile, zarządzany przez Scrum Mastera. Podobnie jak w przypadku XP, Scrum wykorzystuje sprinty oparte na historiach użytkowników do opracowywania nowych funkcji produktu lub oprogramowania. Jednak XP jest bardziej sztywny niż Scrum, z surowymi zasadami i wytycznymi, które zachęcają do stałego kontaktu między programistami a klientem. Scrum można również wykorzystać w każdym procesie, który wymaga iteracji i informacji zwrotnych od klienta, podczas gdy programowanie XP ma tylko jedno zastosowanie.

Kto stworzył ekstremalne programowanie?

Początki XP sięgają późnych lat 90. XX wieku, kiedy to Kent Beck stworzył ją, aby zarządzać rozwojem systemu oprogramowania do obsługi płac dla Chryslera o nazwie projekt C3. Celem XP było (i nadal jest) usunięcie oporu przed zmianą kodu w projektach programistycznych. W bardziej tradycyjnych metodach tworzenia oprogramowania często nie ingeruje się w kod po jego napisaniu (z wyjątkiem debugowania). W przypadku XP kod jest analizowany tak dokładnie, że programiści mogą zdecydować się na jego całkowite przepisanie po jednej iteracji. 

Kiedy należy używać metodologii XP?

Ponieważ XP koncentruje się na tworzeniu oprogramowania, zazwyczaj używają go tylko zespoły inżynieryjne. Nawet w zespołach programistycznych działa tylko w określonych sytuacjach. Aby w pełni wykorzystać możliwości ekstremalnego programowania, najlepiej używać go, gdy: 

• Zarządzasz mniejszym zespołem. Ze względu na swój wysoce oparty na współpracy charakter XP najlepiej sprawdza się w mniejszych zespołach liczących mniej niż 10 osób. 

• Jesteś w stałym kontakcie z klientami. XP uwzględnia wymagania klientów w całym procesie tworzenia oprogramowania, a nawet polega na nich w zakresie testowania i zatwierdzenia.

• Masz elastyczny zespół, który potrafi przyjmować zmiany (bez urazy). Ze względu na swój charakter, programowanie ekstremalne często wymaga od całego zespołu wyrzucenia ciężkiej pracy. Istnieją również zasady, które pozwalają innym członkom zespołu wprowadzać zmiany w dowolnym momencie, co nie zadziała, jeśli członkowie zespołu mogą potraktować to osobiście.

• Dobrze znają techniczne aspekty kodowania. XP nie jest dla początkujących. Musisz być w stanie szybko pracować i wprowadzać zmiany.

Cykl życia XP

Cykl życia XP zachęca do ciągłej integracji, w której członek zespołu dokonuje integracji niemal nieprzerwanie, nawet co godzinę lub codziennie. Pełny cykl życia wygląda następująco:

• Pobierz niedokończoną pracę z historii użytkowników 

• Priorytetyzacja najważniejszych elementów 

• Rozpocznij planowanie iteracyjne  

• Uwzględnienie uczciwego planowania  

• Utrzymuj stałą komunikację ze wszystkimi interesariuszami i wspieraj zespół  

• Wydanie produktu  

• Otrzymywanie informacji zwrotnych 

• Wróć do etapu planowania iteracyjnego i powtórz w razie potrzeby.

5 wartości ekstremalnego programowania

Programowanie ekstremalne opiera się na wartościach. Zamiast używać zewnętrznych motywatorów, XP pozwala Twojemu zespołowi pracować w mniej skomplikowany sposób (koncentrując się na prostocie i współpracy nad złożonymi projektami), a wszystko to w oparciu o tych pięć wartości.

1. Prostota

Przed rozpoczęciem jakiejkolwiek pracy w ramach XP najpierw zadaj sobie pytanie: co jest najprostszą rzeczą, która również działa? Część „które działa” jest kluczowym wyróżnikiem – najprostsza rzecz nie zawsze jest praktyczna lub skuteczna. W XP najważniejsze jest, aby najpierw wykonać najważniejsze zadania. Oznacza to, że szukasz prostego projektu, który wiesz, że możesz zrealizować.

2. komunikacja

XP opiera się na szybkiej reakcji i skutecznej komunikacji. Aby praca przebiegała sprawnie, członkowie zespołu muszą być wobec siebie otwarci i szczerzy. Gdy pojawią się problemy, oczekuje się, że będziesz o nich mówić. Powodem tego jest to, że inni członkowie zespołu często mają już gotowe rozwiązanie. A jeśli nie, to wspólnie znajdziecie rozwiązanie szybciej niż działając w pojedynkę.

3. Informacje zwrotne

Podobnie jak inne metodyki Agile, XP uwzględnia historie użytkowników i informacje zwrotne bezpośrednio w procesie. XP koncentruje się na szybkim i prostym wykonywaniu pracy, a następnie udostępnianiu jej, aby uzyskać niemal natychmiastowe informacje zwrotne. W związku z tym programiści są w niemal ciągłym kontakcie z klientami przez cały czas trwania procesu. W XP często publikujesz nowe wersje, aby szybko i regularnie uzyskiwać statystyki. Po otrzymaniu informacji zwrotnej dostosowujesz proces, aby ją uwzględnić (zamiast projektu). Na przykład, jeśli informacje zwrotne pozwalają uniknąć niepotrzebnego opóźnienia, dostosowujesz proces tak, aby kilku programistów skróciło czas opóźnienia, zamiast dostosowywać projekt jako całość.

4. Odwaga

Metoda XP wymaga pewnej dawki odwagi. Zawsze oczekuje się od Ciebie przekazywania uczciwych informacji o postępach, co może narazić Cię na krytykę. Jeśli w XP nie dotrzymasz terminu, lider zespołu prawdopodobnie nie będzie chciał rozmawiać o tym, dlaczego tak się stało. Zamiast tego powiesz mu, że nie dotrzymałeś terminu, weźmiesz odpowiedzialność na siebie i wrócisz do pracy. 

Jeśli jesteś liderem zespołu, Twoim obowiązkiem na początku procesu XP jest określenie oczekiwań dotyczących sukcesu i zdefiniowanie „wykonania”. Często nie przewiduje się porażki, ponieważ zespół koncentruje się na sukcesie. Może to jednak być przerażające, ponieważ nie zawsze wszystko idzie zgodnie z planem. Jeśli jednak w trakcie procesu XP coś się zmieni, oczekuje się, że zespół dostosuje się do nowej sytuacji. 

5. Szacunek

Biorąc pod uwagę, jak bardzo XP priorytetowo traktuje komunikację i uczciwość, sensowne jest, że szacunek jest ważny. Aby zespoły mogły skutecznie się komunikować i współpracować, muszą mieć możliwość wyrażania odmiennych opinii. Ale są sposoby, aby robić to w uprzejmy sposób. Szacunek to dobry fundament, który prowadzi do życzliwości i zaufania, nawet przy dużej dawce szczerości. W przypadku ekstremalnego programowania oczekiwania są następujące: 

• Wzajemny szacunek między klientami a zespołem programistów. 

• Wzajemny szacunek między członkami zespołu. 

• Uznanie, że każdy członek zespołu wnosi coś cennego do projektu.

5 zasad metodologii ekstremalnego programowania

Wartości ekstremalnego programowania to bardziej filozoficzne aspekty. Zasady natomiast to praktyczne zastosowania sposobu wykonywania pracy. Aby prowadzić efektywny zespół XP, potrzebne są oba te elementy. 

1. Planowanie

Na etapie planowania XP określasz, czy projekt jest opłacalny i czy najlepiej nadaje się do XP. W tym celu należy przyjrzeć się następującym elementom:

• Historie użytkowników, aby sprawdzić, czy są zgodne z wartością prostoty i upewnić się, że klient jest dostępny w trakcie procesu. Jeśli historia użytkownika jest bardziej złożona lub została stworzona przez anonimowego klienta, prawdopodobnie nie będzie ona odpowiednia dla XP.

• Wartość biznesowa i priorytet projektu, aby upewnić się, że projekt jest zgodny z zasadą „najpierw wykonuj najważniejsze zadania”. 

• Na jakim etapie rozwoju się znajdujesz. XP najlepiej sprawdza się na wczesnym etapie rozwoju i nie będzie działać tak dobrze w przypadku późniejszych iteracji.

Po potwierdzeniu, że projekt nadaje się do XP, ‌utwórz harmonogram wydań, ale pamiętaj, że powinny być one publikowane wcześnie i często, aby uzyskać informacje zwrotne. W tym celu:

• Podziel projekt na iteracje i stwórz plan dla każdej z nich. 

• Wyznacz realistyczne terminy i zrównoważone tempo. 

• Udostępniaj aktualizacje na bieżąco, aby umożliwić zespołowi zachowanie szczerości i przejrzystości. 

• Udostępniaj aktualizacje w czasie rzeczywistym, które pomogą zespołowi szybciej identyfikować, dostosowywać i wprowadzać zmiany. 

• Użyj narzędzia do zarządzania projektami, aby utworzyć tablicę Kanban lub oś czasu do śledzenia postępów w czasie rzeczywistym. 

2. Zarządzanie

Jednym z kluczowych elementów XP jest przestrzeń fizyczna. Purysta XP zalecają korzystanie z otwartego obszaru roboczego, w którym wszyscy członkowie zespołu pracują w jednym otwartym pomieszczeniu. Ponieważ XP to metoda oparta na współpracy, warto mieć przestrzeń, w której można się fizycznie spotkać. Jednak w dzisiejszych czasach nie zawsze jest to praktyczne. Jeśli pracujesz w zespole zdalnym, rozważ skorzystanie z platformy, która zachęca do asynchronicznej pracy w ramach współpracy zdalnej. W ten sposób wszyscy członkowie zespołu mogą kontynuować pracę nad projektem, nawet jeśli nie są fizycznie razem.

Podobnie jak w przypadku innych metod Agile, korzystaj z codziennych spotkań stand-up, aby sprawdzać postępy i zachęcać do ciągłej, otwartej komunikacji. Warto korzystać zarówno z cyklu tygodniowego, jak i kwartalnego. Podczas cyklu kwartalnego Ty i Twój zespół przejrzycie historie, które będą kierować Waszą pracą. Przeanalizujecie również proces XP, szukając luk lub możliwości wprowadzenia zmian. Następnie rozpocznie się cykl tygodniowy, który zawsze zaczyna się od spotkania z klientem. Klient wybiera historię użytkownika, nad którą programiści będą pracować w danym tygodniu. 

Jako menedżer lub lider zespołu skupisz się na utrzymaniu postępów w pracy, mierzeniu tempa, przydzielaniu członków zespołu do rozwiązywania pojawiających się błędów lub problemów oraz na zmianie procesu XP, aby dopasować go do bieżącego projektu i iteracji. Pamiętaj, że celem XP jest elastyczność i podejmowanie działań, więc Twoja praca będzie w dużym stopniu skoncentrowana na bieżącej pracy zespołu i będzie reagować na wszelkie zmiany.

3. Projektowanie

Kiedy dopiero zaczynasz pracę z metodologią XP, zacznij od najprostszych możliwych projektów, wiedząc, że późniejsze iteracje sprawią, że staną się bardziej złożone. Na tym etapie nie dodawaj wczesnych funkcjonalności, aby projekt był możliwie jak najbardziej podstawowy.

Zespoły stosujące metodologię XP często używają kart CRC (class-responsibility-collaboration), aby pokazać, jak współdziała każdy obiekt w projekcie. Wypełniając każde pole na karcie, uzyskasz wizualną interakcję wszystkich funkcji, które są ze sobą powiązane i wchodzą w interakcje. Karty CRC obejmują: 

• Klasa (zbiór podobnych obiektów)

• Obowiązki (związane z klasą)

• Współpracownicy (klasa, która wchodzi w interakcje z tą klasą)

Karty CRC są przydatne do stymulowania procesu i wykrywania potencjalnych problemów. Niezależnie od tego, w jaki sposób projektujesz, warto użyć systemu, który redukuje potencjalne wąskie gardła. W tym celu upewnij się, że proaktywnie szukasz zagrożeń. Gdy tylko pojawi się potencjalne zagrożenie, przydziel jednemu lub dwóm członkom zespołu zadanie znalezienia rozwiązania na wypadek, gdyby zagrożenie się urzeczywistniło.

4. Kodowanie

Jednym z bardziej unikalnych aspektów XP jest to, że pozostajesz w stałym kontakcie z klientem przez cały proces kodowania. To partnerstwo umożliwia testowanie i uwzględnianie informacji zwrotnych w każdej iteracji, zamiast czekać na zakończenie sprintu. Jednak zasady kodowania w XP są dość surowe. Niektóre z tych zasad to:

• Każdy kod musi spełniać standardy kodowania.

• Wykorzystanie testów jednostkowych do określenia wymagań i opracowania wszystkich aspektów projektu.

• Programowanie w parach – dwóch programistów pracuje jednocześnie na tym samym komputerze. Nie wydłuża to czasu pracy, a wręcz przeciwnie – pozwala skupić się na uzyskaniu wyników najwyższej jakości. 

• Używanie ciągłych integracji, aby dodawać nowy kod i natychmiast go testować.

• Tylko jedna para może aktualizować kod w danym momencie, aby ograniczyć liczbę błędów.

• Wspólna własność kodu – każdy członek zespołu może zmienić kod w dowolnym momencie.

5. Testowanie

W ramach XP testy należy przeprowadzać na każdym etapie. Cały kod musi przejść testy jednostkowe, zanim zostanie wydany. Jeśli podczas tych testów zostaną wykryte błędy, należy utworzyć nowe, dodatkowe testy, aby je naprawić. Na późniejszym etapie skonfigurujesz tę samą historię użytkownika, nad którą pracowałeś, w teście akceptacyjnym. Podczas tego testu klient sprawdza wyniki, aby zobaczyć, jak dobrze udało Ci się przełożyć historię użytkownika na produkt.

Czym jest 12 praktyk ekstremalnego programowania?

Aby jeszcze bardziej udoskonalić proces, XP wykorzystuje również zestaw 12 praktyk. Opierają się one na Manifeście Agile, ale zostały dostosowane do potrzeb XP:

1. Gra w planowanie: planowanie w XP służy do kierowania pracą. Wynikiem planowania powinno być określenie, co chcesz osiągnąć i w jakim terminie oraz co zrobisz dalej.

2. Testy klienta: po zakończeniu pracy nad nową funkcją klient opracowuje test akceptacyjny, aby określić, jak bardzo jest ona zbliżona do pierwotnej historii użytkownika.

3. Małe wersje: XP wykorzystuje małe, rutynowe wersje, aby uzyskać statystyki w trakcie całego procesu. Często wersje trafiają bezpośrednio do klientów, choć mogą być również testowane wewnętrznie.

4. Prosty projekt: system XP został zaprojektowany z myślą o prostocie – będziesz produkować tylko to, co jest konieczne i nic więcej. 

5. Programowanie w parach: cały proces programowania jest realizowany przez parę programistów, którzy siedzą obok siebie. W ekstremalnym programowaniu nie ma miejsca na pracę w pojedynkę.

6. TDD (ang. Test-Driven Development): programowanie ekstremalne opiera się na informacjach zwrotnych, dlatego wymaga intensywnego testowania. W krótkich cyklach programiści publikują automatyczne testy, a następnie natychmiast reagują.

7. Refaktoryzacja: na tym etapie zwracasz uwagę na drobne szczegóły kodu źródłowego, usuwając duplikaty i upewniając się, że kod jest spójny. W rezultacie powstają dobre, proste projekty.

8. Wspólna odpowiedzialność: każda para programistów może zmienić kod w dowolnym momencie, niezależnie od tego, czy go stworzyła. W XP kod jest tworzony przez zespół, a praca każdego członka jest zgodna z wyższymi standardami zbiorowymi.

9. Ciągła integracja: zespoły XP nie czekają na ukończone iteracje, lecz integrują się w sposób ciągły. Często zespół XP dokonuje integracji kilka razy dziennie.

10. Zrównoważone tempo: intensywność pracy w XP wymaga ustalenia zrównoważonego tempa. Zespoły powinny zdecydować, ile pracy mogą wykonać w ten sposób dziennie i tygodniowo, i wykorzystać to do ustalenia terminów pracy.

11. Metafora: metafora jest dosłownie metaforą. Jest ona ustalana przez zespół i używa języka do opisania, jak zespół powinien funkcjonować. Na przykład jesteśmy mrówkami pracującymi jako kolektyw, aby zbudować mrowisko. 

12. Standard kodowania: zespoły XP przestrzegają jednego standardu. W ten sam sposób, w jaki pisarze muszą przyjąć głos marki, aby brzmiał tak, jakby zawsze pisała ta sama osoba, programiści XP kodują w ten sam, ujednolicony sposób, tak aby brzmiał jak napisany przez jednego programistę.

Intensywne, ale skuteczne

Na tym etapie prawdopodobnie już wiesz, że ekstremalne programowanie jest, cóż, ekstremalne. Proces jest rygorystyczny i wysoce ustrukturyzowany, ale wyniki mogą być tego warte. Unikalny proces tworzenia oprogramowania w XP, który obejmuje informacje zwrotne od klientów i intensywne, wspólne programowanie, skutkuje wysokiej jakości oprogramowaniem. 

Usprawnij planowanie i zarządzanie XP dzięki narzędziu do zarządzania pracą, które aktualizuje się i dostosowuje w czasie rzeczywistym, tak jak Twoja praca.