Czy można uprawiać sport ekstremalny siedząc przed komputerem? Zdania na ten temat są podzielone, ale jedno jest pewne: osoby praktykujące opisywaną w tym artykule metodykę nie boją się podejmować ryzyka, a poziom ich adrenaliny może osiągać naprawdę wysokie wartości.
Za pewne wielu osobom na myśl o zwinnym zarządzaniu projektami jako pierwszy przychodzi do głowy Scrum. Jest on rzeczywiście najbardziej popularną metodyką, ale istnieje też wiele innych, które miały swój udział w powstaniu Manifestu Agile. W tym artykule przedstawiam mniej znany sposób zwinnego wytwarzania oprogramowania – Programowanie Ekstremalne (ang. XP, eXtreme Programming).
Koncepcja programowania ekstremalnego została zapoczątkowana w 1996 roku przez współautora Manifestu Agile, Kenta Becka. Zakłada stosowanie 12 charakterystycznych praktyk, które w połączeniu ułatwiają realizację projektów informatycznych wysokiego ryzyka. Zwykle są to projekty małej lub średniej wielkości, obarczone częstymi zmianami wprowadzanymi przez klienta i dużą dynamiką. Termin „programowanie ekstremalne” ma na celu podkreślenie, że wszelkie praktyki, które dobrze sprawdzają się w inżynierii oprogramowania, w tym przypadku są doprowadzone do skrajnego poziomu. XP oparte jest na kilku wartościach:
- Prostota: będziemy robić to, co jest od nas wymagane, ale nic poza tym. Dzięki temu wartość produktu będzie zmaksymalizowana w czasie. Dlaczego klient miałby czekać i płacić za coś, co nie jest potrzebne?
- Komunikacja: będziemy codziennie ze sobą rozmawiać twarzą w twarz i pracować razem.
- Sprzężenie zwrotne (feedback): będziemy często demonstrować nasze oprogramowanie klientowi, wysłuchiwać jego uwag i nanosić wszelkie niezbędne poprawki.
- Szacunek: każdego członka zespołu będziemy doceniać i obdarzać szacunkiem. Ta zasada tyczy się również klienta.
- Odwaga: będziemy zawsze szczerzy w sprawie postępu naszej pracy i nie będziemy się niczego bać, bo zawsze będziemy działać razem i wspierać się jako zespół.
Dalej opisane zostały wybrane praktyki, stosowane w tym podejściu.
Tandem przed komputerem
Dwie osoby siedzące przed jednym monitorem komputera. To codzienny widok w zespole, który praktykuje programowanie w parach (ang. pair-programming). Zadaniem jednej osoby jest kodowanie, natomiast druga zajmuje się nawigowaniem, pomaga w wychwytywaniu błędów i doradza przy podejmowaniu decyzji. Role w parze przyjmowane są na zmianę, która następuje najczęściej co 1-2 godziny. Wskazane są częste rotacje pomiędzy parami. Każdy programista posiada inne umiejętności, którymi w sposób naturalny dzieli się ze swoim partnerem z pary. W ten sposób wiedza poszczególnych członków zespołu jest rozpropagowywana wśród wszystkich. Można pomyśleć, że taka metoda sprawia, że trzeba zatrudnić 2 razy więcej programistów. Jednak zalety tego rozwiązania są nie do przecenienia. Przy prawidłowym zastosowaniu tej techniki ryzyko powstawania błędów jest o wiele niższe. Kod staje się zrozumiały dla wszystkich, dzięki czemu w przyszłości szybko da się go modyfikować.
Co moje to i Twoje
Każdy członek zespołu ma prawo do modyfikacji dowolnego fragmentu kodu. Nieważne kto go napisał, kod jest zawsze wspólny. Może to brzmieć niebezpiecznie, ponieważ odpowiedzialność za kod się rozmywa. Ma to jednak potężną zaletę – duże przyspieszenie rozwoju systemu, a w projektach stosujących XP czas jest na wagę złota. Ułatwieniem dla tej praktyki jest standaryzacja kodu, czyli ustalenie stylu, formatowania i innych zasad, do których wszyscy programiści mają się stosować. Powoduje to lepszą czytelność i zrozumienie kodu nie tylko przez obecnych, ale również przyszłych członków zespołu. Przy tym wszelkie modyfikacje są stale integrowane z całym systemem, który jest aktualizowany kilka razy dziennie. Dzięki temu zarówno zespół, jak i klient są dobrze poinformowani o postępach projektu.
Najpierw postaw cel
Kolejną charakterystyczną praktyką jest TDD (Test-driven development). Polega na tym, że do każdej nowej funkcjonalności najpierw powstaje test, a dopiero później pisany jest wyłącznie taki kod, który spowoduje poprawne wykonanie się tego testu. Dzięki temu ściśle trzymamy się wymagań, a przy okazji kod jest od razu przetestowany, więc mamy pewność, że działa poprawnie. No, chyba że test był źle zaprojektowany i okazał się niewystarczający, ale to już zupełnie oddzielny problem.
Programista w dobrym stanie
Ważną cechą XP jest zakaz robienia nadgodzin, co opiera się na przekonaniu, że potrzebny jest balans pomiędzy życiem zawodowym i prywatnym. Każdy pracuje bardziej efektywnie, kiedy jest wypoczęty, najedzony i ma czas na przyjemności. Istnieje jeszcze więcej praktyk charakterystycznych dla XP. Zainteresowanych czytelników zachęcam do samodzielnego zgłębienia tematu.
Wszystko ma swoje dobre i złe strony
Programowanie Ekstremalne ma kilka poważnych wad, przez które być może nie jest tak bardzo popularne jak Scrum. Główne zarzuty, które są stawiane przez krytyków tej metody:
- XP ma prawo działać tylko w dobrze wykwalifikowanych i doświadczonych zespołach.
- Wymaga wprowadzenia zbyt drastycznych zmian w sposobie pracy.
- Brakuje mu struktury i porządnej dokumentacji.
- Za bardzo koncentruje się na kodzie, zamiast na projektowaniu.
- Sposób pracy wywołuje zbyt duży stres u programistów, co może powodować częstsze popełnianie błędów.
- Współwłasność kodu powoduje rozmycie odpowiedzialności.
XP vs Scrum
Na początku artykułu wspomniałam o Scrumie. Uważni czytelnicy na pewno wychwycili, że ma on wiele wspólnego z Programowaniem Ekstremalnym. Oba są podejściami zwinnymi i dzielą wspólne koncepcje iteracyjnego rozwoju oprogramowania, planowania iteracji i wydań kolejnych wersji systemu, codziennych spotkań, retrospekcji, wszystkich elementów procesu Agile. Istnieją między nimi subtelne różnice.
Charakterystyczny dla obu metodyk jest przebieg realizacji projektu w iteracjach. Podczas gdy w Scrumie mamy do czynienia ze sprintami, które trwają zwykle od 2 do 4 tygodni, to w XP rekomendowane są jak najkrótsze, tygodniowe iteracje
Z poprzednich akapitów artykułu można było wywnioskować, że XP narzuca pewne konkretne inżynierskie praktyki do zastosowania podczas realizacji projektu, w przeciwieństwie do Scruma, który daje zupełną dowolność w tej kwestii.
W zespole scrumowym występuje specjalna rola Product Ownera, kóry ma za zadanie maksymalizować wartość biznesową projektu. W XP jest to potraktowane jeszcze bardziej dosadnie. Wymagany jest nieustanny bezpośredni kontakt z klientem. Oznaczać to może jedną z dwóch sytuacji. Pierwszym pomysłem jest ciągła obecność w miejscu pracy programistów co najmniej jednej osoby z firmy zamawiającej oprogramowanie, która jest upoważniona do podejmowania decyzji. Drugim, częściej praktykowanym rozwiązaniem, jest umieszczenie całego zespołu projektowego u klienta. Istotną różnicą jest pełna kontrola klienta nad kolejnością wykonywanych zadań, programiści nie mają w tej sprawie nic do gadania, muszą się bezwzględnie stosować do priorytetów klienta.
Dość zaskakujący w XP może być brak zakazu wprowadzania zmian w trakcie rozpoczętej iteracji. Szok trochę mija, kiedy sprecyzujemy, że zmiana może dotyczyć jedynie zadania, które zostało wybrane do zrobienia, ale nad którym nie zaczęto jeszcze fizycznej pracy i jest zastępowane innym, pilniejszym zadaniem. Wtedy osiągana jest prawdziwa, maksymalna elastyczność. Nie powinno to powodować problemów, ponieważ zakładamy stałą orientację członków zespołu w postępach nad projektem, dzięki czemu mimo wprowadzenia zmiany, obędziemy się bez nieporozumień.
Podsumowanie różnic pomiędzy Scrumem i Programowaniem Ekstremalnym zostało umieszczone w Tabeli 1.
Tabela 1. Różnica pomiędzy Scrumem i Programowaniem EkstremalnymZwinność i podobieństwa obu metodyk sprawiają, że do pracy zespołu scrumowego można wdrożyć praktyki Programowania Ekstremalnego. Pełne wprowadzenie XP jest trudne, dlatego bardziej naturalnym i częstszym podejściem jest wybranie przez zespół części z nich, dopasowując je odpowiednio do własnych potrzeb. Przy poprawnie wykorzystanym potencjale tych dwóch metod, jest to świetne połączenie, które wpływa pozytywnie nie tylko na produktywność, ale też na atmosferę w zespole.
Studentka Informatyki na Politechnice Warszawskiej oraz Kognitywistyki na Uniwersytecie Warszawskim. Zaangażowana w działalność Koła Naukowego Zarządzania Projektami PMArt oraz Koła Naukowego Sztucznej Inteligencji Golem. Ma doświadczenie w realizacji projektów głównie w branży IT. Jej zainteresowania to sztuczna inteligencja i granie w planszówki.