Scrum zdominował agile. Zdominował IT. Czasami do Scruma dodaje się Kanban. Często to, jak wygląda praca w Scrumie woła o pomstę. I niestety często jest to wynikiem Scrum Masterów, którzy bardziej niż usprawnianiem procesów i sposobów pracy zajmują się life coachingiem. I tu Scrum nie pomaga, jego szerokie ramy nie dają sztywnych wytycznych, jakich technik użyć by było szybciej i bardziej wartościowo. To, co dla zaprawionych w bojach SM jest wartością w Scrumie (bo jest wiele ścieżek/technik dotacia do celu), dla większości będzie przeszkodą, która może doprowadzić do zombie scruma, zwłaszcza, gdy komuś brakuje obeznania w tym, jak wygląda wytwarzanie oprogramowana.

Idealnym rozwiązaniem byłoby wejście w buty programisty czy testera, żeby poczuć ich problemy na własnej skórze. Nie zawsze jednak będzie na to czas i możliwość.

Co w takim razie?

Szukanie narzędzi i technik, i próbowanie sklecić ich w sensowną całość? Można. Chciałbym jednak opowiedzieć dziś o kompleksowym podejściu do wytwarzania oprogramowania, które może być stosowane równolegle ze Scrumem lub może go całkowicie zastąpić.

Extreme Programming, znane również jako XP, to metodyka wytwarzania oprogramowania, która została opracowana przez grupę programistów, w tym między innymi Kenta Becka i Warda Cunninghama, w latach 90. XX wieku. Metodyka ta jest często uważana za jedną z pierwszych metod zwinnych.

Xtreme Programming: zasady gry

XP zakłada, że wytwarzanie oprogramowania powinno odbywać się w sposób iteracyjny i inkrementalny, w skróconych cyklach, z naciskiem na ciągłą integrację i dostarczanie wartościowych rozwiązań. Brzmi znajomo?

CI ciągła integracja

Ciągła integracja to proces, w którym kod źródłowy jest ciągle łączony i testowany, aby zapewnić, że wszystko działa zgodnie z oczekiwaniami. Dzięki wczesnej integracji zapobiegamy problemom związanym z “niekompaktybilnością” kodu, np. gdy kilka osób pracuje nad dużą funkcjonalnością, może się zdążyć że mają inne nazwy klas, strukturę danych itd. I im dłużej każda z tych osób trzyma kod u siebie (lokalnie) tym większe prawdopodobieństwo, że rozminie się z rozwiązaniem stworzonym przez kogoś innego. Często zmiany kodu w jednym obszarze, mogą powodować problemy w innym. Nie dowiemy się tego, jeśli kod nie będzie często integrowany i testowany end-to-end. Niestety CD/CI, czyli continuous deployment/ continuous integration nie są jeszcze standardem, i zdziwicie się jak wiele firm nie ma kultury integrowania i deployowania kodu na koniec dnia, nie mówiąc już o robieniu tego na bieżąco – kilkakrotnie w ciągu dnia i automatycznie.

Inną techniką z której słynie XP jest programowanie w parach.

Programowanie w parach polega na tym, że dwóch programistów pracuje na jednym zadaniu, co pomaga w rozwiązaniu problemów i przyspiesza proces tworzenia oprogramowania. Z doświadczenia zauważyłam, że ta technika budzi najwięcej obaw, zarówno wśród programistów jak i menadżerów, chociaż z kompletnie innych powodów. Jeśli chodzi o menadżerów to koronnym argumentem jest, że programowanie w parach (pair programming) odbywa się… w parach 🙂Czyli, że dana funkcjonalność kosztuje dwa razy więcej, niż gdyby robiła ją jedna osoba. A drugi argument, to ten o mniejszym capacity, bo ta druga osoba nie może podjąć innego zadania. I te argumenty mają sens, ale nie w każdym przypadku. Jeśli mamy do czynienia z prostym (w znaczeniu jasnym, klarownym) zadaniem, to programowanie w parach jest stratą. Druga osoba nie dodaje wartości, nie przyspiesza rozwiązania problemu. I faktycznie wtedy mogłaby robić coś innego. Jeśli chodzi o programistów, to przede wszystkim niezrozumienie, kiedy pair programming ma sens. Często w grę wchodzą także ego i ambicje – że ktoś ma ich sprawdzać, że “co?!! ja nie dam rady?”. Dlatego warto pokazać, że w przypadku gdy zadanie jest złożone, sami intuicyjnie działają w trybie pair programming – siadają z kumplem i dyskutują, przeglądają wspólnie kod. Metoda ta tylko wprowadza porządek, wskazując, że to jest dobra praktyka i powinno się jej używać wtedy gdy mamy zagwozdkę. Pair programming działa też świetnie w przypadku onboardingu nowych członków zespołu, czy w ramach mentoringu i relacji junior-senior. Jednak technika ta ma trochę potencjalnych pułapek;

1. Wydajność: Programowanie w parach może być mniej wydajne niż programowanie indywidualne, ponieważ wymaga czasu i wysiłku dwóch programistów do napisania kodu, który mógłby zostać napisany przez jedną osobę. Konieczność ciągłego dialogu i uzgodnień może spowolnić tempo pracy.

2. Różnice w umiejętnościach: Jeśli pary programistów mają różny poziom doświadczenia lub umiejętności, może to prowadzić do nierówności w pracy. Osoba o większej wiedzy i doświadczeniu może dominować nad mniej doświadczonym partnerem, co może prowadzić do frustracji i nierównomiernego podziału pracy.

3. Trudności komunikacyjne: Efektywne komunikowanie się jest kluczowe w programowaniu w parach. Jeśli dwie osoby nie potrafią skutecznie komunikować się i porozumiewać, może to prowadzić do srogiego konfligtu.

4. Zmęczenie i frustracja: Długotrwałe programowanie w parach może prowadzić do zmęczenia i frustracji, zwłaszcza jeśli dwie osoby mają różne style pracy lub różnice w podejściu do rozwiązywania problemów.

5. Ograniczona kreatywność: Niektóre osoby preferują pracę w samotności, ponieważ daje im większą swobodę w eksplorowaniu. Programowanie w parach może ograniczać indywidualną ekspresję i niezależność.

6. Konieczność kompromisów: Praca w parach wymaga ciągłego negocjowania i podejmowania kompromisów. Nie zawsze można realizować własne pomysły w pełni, ponieważ trzeba uwzględnić również pomysły i sugestie partnera.

Wady te nie występują we wszystkich przypadkach i mogą być łagodzone przez dobre zarządzanie, umiejętności komunikacyjne oraz odpowiednie dopasowanie partnerów programistycznych. Czy te wady przekreślają korzyści takie jak, zwiększona jakość kodu, możliwość wzajemnej nauki i szybsze rozwiązywanie problemów. Moim zdaniem nie. Kwestia wyważenia i odpowiedniego zaprojektowania pracy w tandemie i nie przesadzanie z używaniem tej techniki do rozwiązania każdego problemu.

Unit testy

Testowanie jednostkowe to praktyka polegająca na tworzeniu testów dla każdej jednostki kodu źródłowego, co pozwala na wczesne wykrywanie błędów i zapobieganie problemom. Najprościej i w wielkim skrócie;

W XP testy jednostkowe (unit testy) są tworzone przed napisaniem właściwego kodu i są integralną częścią procesu programowania. Programiści tworzą testy jednostkowe, które sprawdzają oczekiwane zachowanie kodu, a następnie implementują kod w taki sposób, aby testy były zaliczone. Testy jednostkowe są wykonywane często, zarówno na poziomie programisty, jak i na poziomie całego zespołu, aby zapewnić jakość kodu i szybką identyfikację błędów. Unit testy są automatyczne i sprawdzają poprawność działania pojedynczych jednostek kodu, takich jak funkcje, metody czy klasy (naprawdę małe części!).

Oto kilka kluczowych cech testów jednostkowych wg XP:

1. Automatyzacja: Testy jednostkowe są tworzone w taki sposób, aby można je było wykonywać automatycznie bez potrzeby interakcji człowieka. Dzięki temu są powtarzalne i mogą być wykonywane w każdej chwili, co ułatwia szybkie wykrywanie błędów.

2. Izolacja: Testy jednostkowe sprawdzają działanie jednostek kodu w izolacji od innych komponentów systemu. Oznacza to, że jednostka jest testowana niezależnie od swoich zależności, które mogą być symulowane lub zastąpione tzw. atrapami (mocks lub stubs).

3. Szybkość i szybka odpowiedź: Testy jednostkowe są napisane w taki sposób, aby były szybkie do wykonania. Ich celem jest jak najszybsze dostarczenie informacji zwrotnej na temat poprawności kodu, co pozwala na szybkie wykrycie i naprawę błędów.

4. Dokumentacja: Testy jednostkowe pełnią również rolę dokumentacji kodu. Przez analizę testów jednostkowych można zrozumieć, jak kod powinien być używany i jakie rezultaty powinien generować.

Ważne, żeby pamiętać że unit testy nie testują całej funkcjonalności i nie można powiedzieć, że skoro wykonane są unit testy to funkcjonalność jest przetestowana, gotowa do wdrożenia. 

Lećmy dalej z podstawami XP.

Refaktor, czyli małe zmiany

Refaktoryzacja czy refactoring. Zacznijmy od tego, że jest to proces i dlatego powinien odbywać się ciągle. Jeśli zaczniemy traktować refaktoryzacje, jako dodatkowe zadanie, to może zostać ona zaniedbana i doprowadzić do wygenerowania długu technologicznego. Celem refaktoru jest zwiększenie czytelności kodu, bez zmieniania jego zachowania;

1. Bezpieczeństwo: Refaktoryzacja jest bezpiecznym procesem, ponieważ nie powinna wpływać na działanie kodu w sposób niezamierzony. Wszystkie zmiany powinny być weryfikowane przy użyciu testów jednostkowych, aby upewnić się, że zachowane zostaje poprawne działanie systemu.

2. Małe kroki: Refaktoryzacja w XP polega na dokonywaniu małych, inkrementalnych zmian w kodzie. Zamiast próbować przeprowadzić ogromną restrukturyzację na raz, programiści wykonują serię małych zmian, każda z nich wprowadzającą niewielkie usprawnienia w kodzie.

3. Stała poprawa: Refaktoryzacja jest procesem ciągłym i powinna być praktykowana na bieżąco. Staraj się nie czekać na moment „idealny” do refaktoryzacji, ale regularnie dokonuj drobnych zmian mających na celu poprawę jakości kodu.

4. Użycie wzorców: Podczas refaktoryzacji często wykorzystuje się wzorce projektowe i dobre praktyki programistyczne. Refaktoryzacja może polegać na zastosowaniu odpowiednich wzorców, w celu uporządkowania kodu i poprawy jego jakości.

5. Współpraca zespołowa: Refaktoryzacja jest często wykonywana przez cały zespół programistyczny. Programiści mogą wzajemnie recenzować i poprawiać kod, dzielić się wiedzą i najlepszymi praktykami, aby stale doskonalić system.

A jak się ma refaktoryzacja do długu technologicznego? Refaktoryzacja jest procesem, który służy poprawie jakości kodu i ułatwieniu dalszego rozwoju, a dług technologiczny odzwierciedla skumulowane problemy i niedociągnięcia w kodzie, które prowadzą do trudności i ograniczeń w dalszym rozwoju systemu. Refaktoryzacja pomaga obronić się przed długiem technologicznym, który jest pokłosiem rozwiązań wprowadzanych na szybko kosztem jakości, zaniechań refaktoryzacji czy spychaniu w dół backloga “zadań technicznych” takich jak np. upgrade frameworka.

Planowanie i praca w iteracji

XP porusza także aspekt planowania. Co ciekawe w XP mówi się o planowaniu gier. Dlaczego “gra”? Bo ma to podkreślić, że praca ma być ciekawa, przyjemna, ma sprawiać radość. Chociaż ja uważam, że fajnie brzmi otwarcie planningu słynnym “Let’s play a game”, co raczej nie zapowiada szampańskiej zabawy dla wszystkich uczestników gry ]:-)

Do brzegu. Tu jest kolejna zbieżność ze Scrumem. Planowanie gry polega praktycznie na tym samym co sprint planning i zawiera elementy takie jak daily scrum czy review. Zbieramy programistów, interesariuszy i wszystkich, którzy mają jakiś wkład do wniesienia i ustalamy: cele, funkcje i priorytety. Planowanie odbywa się iteracyjne i jest inkrementalne i zazwyczaj trwa jeden lub dwa tygodnie. A główne zasady planowania gry to:

1. Wartość dla użytkownika: Nacisk kładziony jest na dostarczenie wartości użytkownikowi. Tworzenie gry opiera się na zrozumieniu potrzeb i oczekiwań użytkowników oraz skupieniu się na tworzeniu funkcji i elementów, które przynoszą największą wartość.

2. Zwinne podejście: Zespół programistyczny pracuje w krótkich okresach, zwanych iteracjami, podczas których tworzone są funkcje gry o najwyższym priorytecie. Po każdej iteracji odbywa się przegląd i planowanie kolejnej.

3. Maksymalizowanie feedbacku: Planowanie gier w XP zakłada częste zbieranie feedbacku od użytkowników lub innych interesariuszy. Dzięki temu zespół programistyczny może dostosować priorytety i kierunek rozwoju gry na podstawie rzeczywistych informacji zwrotnych.

4. Zespół wielofunkcyjny: Angażujemy cały zespół programistyczny, a nie tylko programistów. W zespole mogą znajdować się programiści, projektanci gier, testerzy i inni specjaliści. Wszyscy są zaangażowani w proces planowania i mają możliwość wnoszenia swojego wkładu.

5. Estymacja i priorytetyzacja: Zespół programistyczny dokonuje estymacji czasu i zasobów potrzebnych do zrealizowania poszczególnych funkcji. Na podstawie tych estymacji i wartości dla użytkownika, priorytetyzowane są zadania, aby zapewnić dostarczenie najważniejszych funkcji w pierwszej kolejności.

6. Monitorowanie postępu: Zespół programistyczny monitoruje postęp prac, dostarczając regularne aktualizacje na temat wykonanych i planowanych funkcji. To umożliwia kontrolę nad harmonogramem, dostosowanie priorytetów i identyfikację ewentualnych opóźnień.

Wartości.

XP jak na porządną zwinną metodykę przystało także kładzie nacisk na wartości, bez których używanie narzędzi proponowanych przez XP jest bardzo trudne. Praktyki XP mają na celu umacnianie i promowanie wartości, takich jak komunikacja, prosta konstrukcja, testowanie, zwinność i odwaga. Jedno bez drugiego nie może istnieć i działać zdrowo.

Różnice między XP a Scrumem.

W XP znajdziecie wiele podobieństw do Scruma, myślę że jeśli dobrnęliście do końca tego wpisu to zastanawiacie się gdzie są różnice. Otóż są całkiem znaczące;

1. Zakres: Scrum skupia się głównie na zarządzaniu produktem, podczas gdy XP skupia się bardziej na technicznych praktykach programistycznych.

2. Proces: Scrum ma bardziej formalną strukturę procesową, opartą na zdefiniowanych rolach, spotkaniach i artefaktach, takich jak Scrum Master, Product Owner, Daily Scrum, Sprint Planning, Sprint Review i Sprint Retrospective. XP ma bardziej elastyczną strukturę procesową i koncentruje się na ciągłej integracji, krótkich iteracjach, parowaniu programistów i testach jednostkowych. Nie definiuje także formalnych ról, ale zazwyczaj zachęca do równoważonego zaangażowania całego zespołu programistycznego.

3. Skala: Scrum jest bardziej skalowalny i można go stosować do zarządzania zarówno małymi, jak i dużymi projektami, a także do zarządzania projektami o różnym zakresie. XP jest bardziej skoncentrowane na małych zespołach programistycznych i może być mniej odpowiednie dla większych projektów.

4. Techniczne praktyki: XP skupia się na technicznych praktykach programistycznych, takich jak testy jednostkowe, programowanie w parach, ciągła integracja, proste projektowanie i refaktoryzacja. Scrum nie narzuca konkretnych technicznych praktyk, ale może być stosowany w połączeniu z technikami i narzędziami, takimi jak DevOps czy Continuous Integration czy właśnie XP

5. Planowanie: Scrum skupia się na planowaniu na poziomie sprintów i iteracji, ustalając cele i priorytety na podstawie backlogu produktu. XP również ma iteracyjne podejście do planowania, ale bardziej skupia się na elastyczności i dostosowywaniu planów w oparciu o feedback i zmieniające się wymagania.

XP jest uważane za jedną z najbardziej skutecznych i elastycznych metod wytwarzania oprogramowania, szczególnie w przypadku projektów wymagających szybkiej reakcji na zmieniające się warunki. XP używane jest np w Spoitify. Czy jest lepsze od Scruma? Jest inne. Często łatwiejsze do wprowadzenia, bo nie ingeruje w nazwy stanowisk i strukturę organizacji, przez to mentalnie bezpieczniejsze dla managementu. Z drugiej jednak strony XP “jest bardziej techniczne”, i wymaga od programistów uzgodnienia jakie są ich WoW, jak będą pisać kod, jakich zasad się trzymać i jak je weryfikować. Bez ogarniętych ludzi w zespole, którzy zjedli zęby na developerce może być ciężkie w realizacji.

Jak wykorzystać XP w pracy SM?

Co XP może dać Scrumowi? Jakość w kodzie i zasady jak ją utrzymać. Wprowadzenie testów jednostkowych, programowania w parach, refaktoryzacji jako procesu, CD/CI i prostego projektowania to podstawy, z których praktycznie zawsze warto korzystać. Jak będzie to wyglądać w praktyce?

Gdy zespół zaczyna pracę nad zadaniem zaczyna od pisania unit testów i dopiero wokół nich buduje kod. Można umówić się tak, że inna osoba pisze testy a inna buduje w okół nich funkcjonalność. Dzięki temu usprawniamy przepływ wiedzy w zespole, ale też trochę robimy team building 😉 

Rafaktor można także potraktować jako część pracy nad jakimś zadaniem. Czyli jeśli mamy nową funkcjonalność to możemy założyć w wycenie czas na drobne poprawki w miejscach, gdzie nowy kod “spotyka się” ze starym. Innym sposobem jest pomniejszenie capacity zespołu, tak aby w każdym sprincie był czas na refaktoryzacje. Żeby zwiększyć widoczność można po prostu do każdego sprintu dodawać zadanie “Refaktor X” i wymienić co i jak zmieniamy. 

Proste projektowanie wpisuje się doskonale w dzielenie dużych funkcjonalności na mniejsze i tworzeniu lekkich, prostych i przejrzystych rozwiązań bez pozłacania i robieniu funkcjonalności “na zaś”. 

Ostatnią rzeczą będzie CD/CI. Jeśli chcemy mieć potencjalnie możliwy do wdrożenia produkt, to praktyki i automatyzacja ciągłej integracji i deploymentu będą pomocne. Dzięki temu kod będzie częściej testowany a tworzone rozwiązanie bardziej niezawodne.

Ufff. To było dużo słów, a mam wrażenie, że tylko liznęłam temat. Jeśli jednak po przeczytaniu tego zachęciłam Was do zapoznania się z XP to super. Uważam, że w świecie złego Scruma i SM będących wróżkami z magiczną różdżką kołczingu, XP to powrót do korzeni tego, co ważne w zwinności.

Niech agile będzie z wami!

Anja