Ekstremalne programowanie

W tej lekcji omówimy ekstremalne programowanie, czyli w skrócie XP, które jest kolejną metodologią adaptacyjną.

Ekstremalne programowanie to metoda pochodząca z rozwoju oprogramowania. Została opracowana specjalnie dla projektów związanych z tworzeniem oprogramowania. Jednak mimo to, wiele z jej praktyk można z powodzeniem zastosować również w innych branżach. Wkrótce omówię te praktyki, ale najpierw skupmy się na podstawowych wartościach XP.

XP posiada pięć podstawowych wartości: prostotę, komunikację, informację zwrotną, szacunek i odwagę. Prostota polega na usuwaniu lub redukowaniu złożoności. Nie potrzebujemy skomplikowanych rozwiązań – wszystko powinno być tak proste, jak to możliwe. Jeśli coś jest proste i działa, to wystarczy. Nie potrzebujemy dodatkowych funkcji i marnotrawstwa.

Wartość komunikacji polega na zapewnieniu odpowiedniego poziomu komunikacji, aby każdy wiedział, co ma robić i co robią inni. Podobnie jak w Scrumie, w XP również prowadzimy codzienne spotkania, tzw. daily stand-up, co wspiera stałą komunikację w zespole.

Informacja zwrotna oznacza, że regularnie i wcześnie zbieramy opinie na temat naszej pracy. Wczesna informacja zwrotna pozwala na szybkie wykrywanie błędów, co ułatwia ich naprawę i przyspiesza rozwój produktu.

Szacunek oznacza zrozumienie, że każdy jest inny. Każda osoba ma swój styl pracy i nie powinniśmy oczekiwać, że wszyscy będą pracować w ten sam sposób. Ludzie powinni pracować jako zespół, pamiętając, że każdy jest odpowiedzialny za sukces projektu. W XP porażka projektu nie jest winą jednej osoby – jeśli projekt się nie uda, to odpowiedzialność ponosi cały zespół. Podobnie, gdy projekt zakończy się sukcesem, to jest to zasługa całego zespołu.

Odwaga polega na tym, że ludzie są zachęcani do dzielenia się swoją pracą i są gotowi przyjąć sugestie rozwiązań od innych. Nie powinni bać się krytyki, a ich praca jest widoczna i dostępna do oceny przez innych.

Zespół XP składa się z coacha, klienta, programistów i testerów. Coach pełni rolę mentora i jest odpowiednikiem Scrum Mastera w Scrumie. Klient dostarcza wymagania, ustala priorytety i nadaje kierunek projektowi – podobnie jak właściciel produktu w Scrumie. Programiści to osoby piszące kod, a testerzy odpowiadają za testowanie kodu.

Planowanie wydania, zamiast tworzenia szczegółowego planu, polega na określaniu, co zostanie dostarczone po kolejnych iteracjach. Regularne i małe wydania pozwalają na częstsze dostarczanie produktów i wcześniejsze uzyskiwanie informacji zwrotnej. Kolokacja, czyli wspólna praca zespołu w jednym fizycznym miejscu, wspiera lepszą komunikację i szybsze rozwiązywanie problemów.

Dążymy, aby członkowie zespołu byli specjalistami w swoich dziedzinach, ale też rozumieli, czym zajmują się inni. Wszyscy członkowie zespołu ponoszą odpowiedzialność za sukces lub niepowodzenie projektu – nikt nie jest jedynym właścicielem wyników.

Testy tworzone przez klienta pomagają programistom udowodnić, że oprogramowanie działa zgodnie z oczekiwaniami klienta. Wszyscy powinni pracować w zrównoważonym tempie, co oznacza, że nie powinni przepracowywać się, aby ich wydajność nie spadała z czasem.

Metafory służą jako wspólny język pomiędzy interesariuszami, ułatwiając zrozumienie wymagań. Przykładowo, pudełko płatków śniadaniowych może posłużyć za metaforę wymagań projektu, na którym zapisujemy kluczowe informacje.

Programowanie w parach, czyli wspólna praca dwóch programistów nad jednym elementem kodu, umożliwia szybkie wykrywanie błędów – jedna osoba pisze kod, a druga go sprawdza. Nasze projekty powinny być zaprojektowane możliwie najprościej, aby łatwo było je testować i zrozumieć. Jeśli coś jest zbędne, usuwamy to, co nazywamy refaktoryzacją.