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
- 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
Programowanie w parach
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”
Programowanie oparte na testach
Projektowanie przyrostowe
Role
- 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
