Programowanie ekstremalne

Programowanie ekstremalne

Cześć

   Tematyką ostatniego postu programistycznego był Scrum. Porozmawialiśmy sobie między innymi o tym, czy Scrum jest naprawdę zawsze potrzebny i czy nie jest trochę przereklamowany (aby przeczytać post, kliknij tutaj). Dzisiaj chciałbym zostać przy tej samej tematyce i omówić rzadko spotykane programowanie ekstremalne. Moją pierwszą myślą o programowaniu ekstremalnym były czasy studiów, gdzie niektórym studentom zdarzało się pisać się projekty „na szybko” i „byle jak” tylko żeby zdążyć z wymaganiami prowadzącego. Czy programowanie ekstremalne rzeczywiście jest szybkie, niedokładne ale skuteczne? Zapraszam.

Definicja

     Programowanie ekstremalne (XP) jest uważane za najbardziej radykalną formę zwinnego rozwoju oprogramowania, dlatego też nazywa się je “ekstremalnym”. Prawdopodobnie nie istnieje żadna inna metodologia tak zwinna jak XP, a już najmniej tradycyjne praktyki programistyczne. Programowanie ekstremalne wyraźnie różni się od innych podejść, takich jak „waterfall”, który według wynalazców XP ma wiele problemów. W połowie lat dziewięćdziesiątych XX wieku programiści Kent Beck, Ward Cunningham i Ron Jeffries postanowili zrewolucjonizować tradycyjne praktyki programistyczne i pójść w nowym kierunku.

Programowanie ekstremalne jest ukierunkowane na wymagania klienta. Na początku może się to wydawać oczywiste, ale tradycyjne tworzenie oprogramowania nie zawsze wychodzi naprzeciw potrzebom klienta. Sprawy stają się jeszcze trudniejsze, gdy wymagania te zmieniają się regularnie. XP stara się również zachęcać programistów do kreatywności i akceptuje błędy jako naturalną część procesu pracy. Podobnie jak inne metody zwinne, XP jest również oparte na procesach iteracyjnych. XP zrywa z praktyką realizowania dużego projektu od początku do końca za jednym zamachem i inwestowania wielu miesięcy pracy tylko po to, by potem stwierdzić, że produkt końcowy nie jest właściwy. Zamiast tego, praca jest ciągle testowana, dyskutowana i wypuszczana w krótkich cyklach. W ten sposób błędy mogą być szybko wykryte i wyeliminowane.

XP posiada bardzo przejrzyste ramy dla spełnienia wymagań. Opiera się on na wielu wartościach, zasadach i praktykach. Dodatkowo, ludziom przypisuje się konkretne role, dzięki czemu zadania są jasno delegowane.

Cel

     Twórcy programowania ekstremalnego uznali, że większość metod tworzenia oprogramowania ma jedną wspólną wadę – każda zmiana jest bardzo kosztowna. I rzeczywiście w praktyce można uznać, że większość błędów znalezionych w fazie utrzymania projektu zwykle kosztuje o wiele więcej, niż błąd znaleziony podczas tworzenia czy planowania. Głównym celem programowania ekstremalnego jest wyjście naprzeciw tym oczekiwaniom i próbuje obniżyć koszty zmiany wymagań poprzez stosowanie bardzo krótkich cykli iteracyjnych. Głównym założeniem tej metodyki jest to, że zmiana wymagań na pewno nastąpi i jest rzeczą nieuniknioną. Określenie stabilnego zestawu wymagań w przypadku programowania ekstremalnego jest niemożliwe. 

Wartości

  • Komunikacja. Wytwarzanie oprogramowanie bez komunikacji jest wręcz niemożliwe. Programowanie ekstremalne podkreśla wyznaczanie odpowiedniego rodzaju komunikacji promując dyskusję twarzą w twarz za pomocą białej tablicy lub innego mechanizmu rysowania.
  • Prostota. Należy odpowiedzieć sobie na pytanie „co jest najprostszą rzeczą, która będzie działać?”. Celem tego jest unikanie marnotrawstwa i robienia tylko absolutnie niezbędnych rzeczy, takich jak utrzymywanie projektu systemu tak prostego, jak to tylko możliwe, aby był on jak najłatwiejszy do utrzymania oraz wsparcia. Prostota oznacza również, że należy zająć się tylko tymi wymaganiami, które są znane, nie należy próbować przewidywać przyszłości. 
  • Feedback. Dzięki ciągłym oraz częstym informacjom zwrotnym na temat swoich poprzednich działań, zespoły mogą zidentyfikować obszary wymagające poprawy i poprawić swoje praktyki. Informacje zwrotne są również bardzo ważne w prostych projektach. Zespół, który buduje i projektuje system, zbiera informacje zwrotne na jego temat a następnie dostosowuje swój produkt do wymagań.
  • Odwaga. Kent Beck zdefiniował odwagę jako “skuteczne działanie w obliczu strachu”. Ta definicja pokazuje preferencję dla działań opartych na innych zasadach, tak aby rezultaty nie były szkodliwe dla zespołu. Potrzebujesz odwagi, aby poruszyć kwestie organizacyjne, które zmniejszają efektywność Twojego zespołu. Potrzebujesz odwagi, aby przestać robić coś, co nie działa i spróbować czegoś innego. Potrzebujesz odwagi, aby przyjąć informację zwrotną i działać zgodnie z nią, nawet jeśli jest ona trudna do przyjęcia.
  • Szacunek. Członkowie zespołu muszą się wzajemnie szanować, aby móc się ze sobą komunikować, przekazywać i przyjmować feedback, które są wyrazem szacunku dla wzajemnych relacji.

Praktyki

     Początkowo w metodzie programowania ekstremalnego wyróżniono 12 praktyk, które podzielono na 4 obszary. Oto oficjalna lista 12 praktyk:
  • Metafora
  • Gra w planowanie
  • Małe wydania
  • Prosty projekt
  • Testowanie
  • Refaktoryzacja
  • Programowanie w parach
  • Kolektywna własność
  • Ciągła integracja
  • 40-godzinny tydzień pracy
  • Klient na miejscu
  • Standard kodowania

Jednak wraz z upływem czasu, praktyki zmieniły się od czasu ich wprowadzenia. W drugim wydaniu książki „Extreme Programming Explained Embrace Change” udoskonalono te praktyki. Oto moim zdaniem najciekawsze z nich:

Usiądźcie razem

     Ponieważ komunikacja jest jedną z pięciu wartości XP, a większość ludzi zgadza się, że rozmowa twarzą w twarz jest najlepszą formą komunikacji, każ swojemu zespołowi usiąść razem w tej samej przestrzeni bez barier dla komunikacji, takich jak ściany boksu.
 

Programowanie w parach

   Pair Programming oznacza, że całe oprogramowanie produkcyjne jest tworzone przez dwie osoby siedzące przy tej samej maszynie. Idea stojąca za tą praktyką jest taka, że dwa mózgi i cztery oczy są lepsze niż jeden mózg i dwoje oczu. Efektywnie uzyskuje się ciągłość przeglądu kodu i szybszą reakcję na dokuczliwe problemy, które mogą zatrzymać jedną osobę w miejscu. Zespoły, które stosują programowanie w parach, odkryły, że poprawia ono jakość i nie zajmuje dwa razy więcej czasu, ponieważ są w stanie szybciej rozwiązywać problemy i bardziej skupiają się na zadaniu, tworząc mniej kodu, aby osiągnąć to samo.
 

Cykl tygodniowy

    Cykl Tygodniowy jest synonimem iteracji. W przypadku programowania ekstremalnego, zespół spotyka się pierwszego dnia tygodnia, aby zastanowić się nad dotychczasowym postępem, klient wybiera historie, które chciałby dostarczyć w danym tygodniu, a zespół ustala, jak podejdzie do tych historii. Celem do końca tygodnia jest posiadanie działających, przetestowanych funkcjonalności, które realizują wybrane historie. Intencją tego okresu jest wyprodukowanie czegoś, co można pokazać klientowi w celu uzyskania informacji zwrotnej.

„Ten-minute build”

     Celem Ten-Minute Build jest automatyczne zbudowanie całego systemu i uruchomienie wszystkich testów w ciągu dziesięciu minut. Założyciele programowania ekstremalnego zasugerowali 10 minutowe ramy czasowe, ponieważ jeśli zespół ma build, który trwa dłużej niż ten czas, jest mniej prawdopodobne, że będzie on uruchamiany często, wprowadzając w ten sposób dłuższy czas pomiędzy błędami.
 

Programowanie oparte na testach

Zamiast podążać normalną ścieżką: napisz kod -> napisz testy -> uruchom testy
 
Praktyka programowania Test-First Programming podąża ścieżką:
 
Napisz nieudany test automatyczny -> uruchom nieudany test -> opracuj kod, aby test przeszedł -> uruchom test -> powtórz
 
Podobnie jak w przypadku „continuous integration”, programowanie Test-First skraca cykl informacji zwrotnej dla programistów, aby zidentyfikować i rozwiązać problemy, zmniejszając tym samym liczbę błędów, które są wprowadzane do produkcji.
 

Projektowanie przyrostowe

     Praktyka projektowania przyrostowego sugeruje, że wykonuje się trochę pracy z góry, aby zrozumieć właściwą, szeroką perspektywę projektu systemu, a następnie wchodzi się w szczegóły poszczególnych aspektów tego projektu, kiedy dostarcza się konkretne funkcjonalności. Takie podejście redukuje koszty zmian i pozwala na podejmowanie decyzji projektowych, kiedy jest to konieczne, w oparciu o najbardziej aktualne dostępne informacje.
 
Praktyka refaktoryzacji była pierwotnie wymieniona wśród 12 podstawowych, ale została włączona do praktyki projektowania przyrostowego. Refaktoryzacja jest doskonałą praktyką, którą można wykorzystać do utrzymania prostoty projektu, a jednym z najbardziej zalecanych zastosowań refaktoryzacji jest usunięcie duplikacji procesów.
 

Role

     Pomimo, że programowanie ekstremalne określa konkretne praktyki, których zespół powinien przestrzegać, oficjalnie nie ustala konkretnych ról dla ludzi w zespole. Jemniej jednak przyjęło się cztery najczęstsze role związane z programowaniem ekstremalnym: 
  • Klient. Programowanie ekstremalne jest silnie skoncentrowane na kliencie. W rzeczywistości, klient jest uważany za część zespołu i zawsze ma przynajmniej jednego przedstawiciela na miejscu (on-site customer). Klient definiuje wymagania dotyczące produktu, ale nie dyktuje, w jaki sposób cele mają być osiągnięte. Klient jest jedynie odpowiedzialny za ustalanie priorytetów w poszczególnych obszarach projektu. Do tego należy również jasne wyrażanie własnych życzeń. Rola klienta może być przejęta przez jedną osobę lub przez zespół różnych przedstawicieli klienta. W praktyce często zadania te wykonują menedżerowie produktu lub nawet pracownicy marketingu (ale zawsze zgodnie z celem projektu).
  • Programista. Ponieważ programowanie ekstremalne nie wymaga definiowania ról, każdy w zespole (z wyjątkiem klienta i kilku drugorzędnych ról wymienionych poniżej) jest nazywany programistą. Deweloperzy są odpowiedzialni za realizację historyjek zidentyfikowanych przez klienta. Ponieważ różne projekty wymagają różnej kombinacji umiejętności, a metoda programowania ekstremalnego opiera się na zespole funkcjonalnym zapewniającym odpowiednią kombinację umiejętności.
  • Menadżer. Menedżer jest łącznikiem pomiędzy deweloperami a klientami. Osoby na tym stanowisku łączą klientów i deweloperów oraz moderują spotkania. Robiąc to, menedżer upewnia się, że wszyscy przestrzegają wcześniej ustalonych zasad i ogólnych konwencji konstruktywnej dyskusji. W razie potrzeby menedżer przyjmuje również rolę mediatora. Rola ta jest czasami określana mianem trackera. Dzieje się tak dlatego, że do zadań kierownika należy śledzenie kluczowych wskaźników (takich jak czas, jaki każda osoba spędza nad projektem).
  • Trener. Jeśli zespół dopiero zaczyna stosować programowanie ekstremalne, można uznać za pomocne włączenie Trenera do swojego zespołu. Jest to zazwyczaj zewnętrzny konsultant lub ktoś z innego miejsca w organizacji, kto już wcześniej używał programowania ekstremalnego i jest włączony do zespołu, aby pomóc mentorowi innym członkom zespołu w zakresie dobrych praktyk.

Wady oraz zalety

ZALETY WADY
Bliski kontakt z klientem Dodatkowa praca
Brak zbędnych prac programistycznych Klient musi uczestniczyć w procesie
Stabilne oprogramowanie dzięki ciągłym testom Stosunkowo duże nakłady czasu
Unikanie błędów dzięki programowaniu w parach Stosunkowo wysokie koszty
Brak nadgodzin, zespoły pracują we własnym tempie Wymaga zarządzania wersjami
Zmiany mogą być wprowadzane w krótkim czasie Wymaga samodyscypliny
Kod jest jasny do zrozumienia Kod może być niezdatny do rozwijania

Podsumowanie

     Osobiście myślę, że programowanie ekstremalne na pewno nie jest metodyką z którą chciałbym stale pracować. Uważam, że lepsze zaplanowanie, częste spotkania i wyłączenie klienta z „zespołu” może w przyszłości dać lepszy efekt. Czasami może wydawać się, że „bezsensownymi” scrumowymi spotkaniami może marnować się czas, lecz w rzeczywistości ten stracony czas podwójnie zaowocuje w przyszłości. Poza tym szybkie wytwarzanie oprogramowania nie zawsze oznacza coś lepszego. Czasami szybkie metody nie nadają się do rozwijania czy ulepszania i kiedy przyjdzie nowe wymaganie jedynym rozwiązaniem będzie napisanie funkcjonalności na nowo, tracąc na tym czas. Na pewno warto być świadomy, że programowanie ekstremalne istnieje i zawsze można wynieść z niego coś pozytywnego, jak np. odwagę. Czy znacie jakieś komercyjne projekty, w których programowanie ekstremalne jest oficjalnie stosowane? Pochwalcie się!

Pozdrawiam serdecznie,
biegajacyprogramista.pl

Dodaj komentarz

eighteen − 14 =

Close Menu