Programowanie ekstremalne Przekierowano ze strony: XP ang. eXtreme Programming, XP

XP
Metodyka
Zarządzanie projektami
Logo XP
Właścicielbrak
TwórcaKent Beck
Powstanie1999 r.
Aktualna wersjalistopad 2004 r.
Schemat procesu

Wiki poświęcona XP


Programowanie ekstremalne - to paradygmat i metodyka programowania mające na celu wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces.

Spis treści

Rozwój standardu

Podstawą ekstremalnego programowania jest synergia wynikająca ze stosowania rozmaitych praktyk, które same w sobie mają wiele zalet, lecz mogą być trudne w zastosowaniu. Łączne użycie tych praktyk ma zapewniać wyeliminowanie niedogodności każdej z nich.

Krytyka standardu ISO 9000 i modelu CMM zaowocowała powstaniem pod koniec lat 90-tych tzw. lekkich metodyk wytwarzania oprogramowania, wśród których największą popularność zyskało Programowanie Ekstremalne zaproponowane przez Kenta Becka. Podstawowe założenia zostały sformułowane, podczas jego pracy nad Chrysler Comprehensive Compensation System zwanym w skrócie C3. Podczas tych prac napisał, opublikowaną w 1999 r., książkę Extreme Programming Explained. Stroną, która służyła do wymiany poglądów na temat programowania ekstremalnego było z kolei pierwsze na świecie Wiki Portland Pattern Repository założone przez Becka i Warda Cunninghama.

XP wywołało spore poruszenie w końcu lat 90. i na początku 2000, skoro zostało szybko przyjęte w wielu środowiskach skrajnie różnych od tego w jakim powstało. Obecnie, podobnie jak inne metody zwinne, XP wciąż ewoluuje, proces rozwoju nie stanął ani na chwilę. Metody te przyswajają coraz więcej wiedzy i doświadczeń, aby korzystać z innych, nowych praktyk. W drugiej edycji książki Becka, z listopada 2004, pięć lat po pierwszym wydaniu, Beck dodał więcej wartości i praktyk.

Zastosowanie

Ekstremalne programowanie to zdefiniowana metodyka tworzenia oprogramowania. Jest dobrym przykładem lekkiej metodyki, przyjaznej zarówno klientowi, jak i programistom. Zestaw specyficznych dla XP praktyk, choć różniących się od metod znanych z tradycyjnej inżynierii oprogramowania, ma za zadanie osiągnięcie tych samych celów. Są one ukierunkowane na różne obszary aktywności w procesie tworzenia oprogramowania. Zdaniem twórcy XP metodyka ta składa się z czterech wartości: komunikacja, prostota, informacja zwrotna i odwaga oraz 12 praktyk:
  • gra planistyczna
  • krótkie okresy wydania kolejnych wersji
  • metafora
  • prosty projekt systemu
  • testowanie przed kodowaniem
  • refaktoryzacja
  • programowanie w parach
  • współwłasność kodu
  • ciągła integracja
  • brak nadgodzin
  • udział klienta w zespole
  • standard kodowania


Powyższe wartości opisują cel, który przyświeca Ekstremalnemu programowaniu: tworzenie oprogramowania o wysokiej jakości za pomocą prostych środków, przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na potrzeby klienta oraz odważnym podejmowaniu trudnych decyzji. Praktyki Programowania Ekstremalnego stanowią swoistą implementację tych wartości. Pomimo pozornej dowolności w doborze, są one ściśle związane ze sobą i wspólnie realizują założone cele metody.

Opis

W celu uniknięcia wielu problemów związanych z porównywaniem wyników wymienione powyżej praktyki XP poszeregowano w czterach obszarach, opisujących proces XP.

Planowanie i definiowanie

Proces planowanie w przypadku ekstremalnego programowanie wygląda zgoła inaczej niż w przypadku ciężkich metod programowania. W ich przypadku horyzont planowania jest zazwyczaj stosunkowo odległy, podczas gdy XP stawia sobie cele na najbliższą przyszłość. XP przyświeca przekonanie, że odległe plany są mnie prawdopodobne w realizacji. W tym obszarze wymienić można trzy praktyki:
  • Gra planistyczna - element zastępujący typową fazę planowania obecną w metodykach klasycznych. Podczas gry planistycznej zespół określa zakres funkcjonalności, jaka powinna zostać zaimplementowana w najbliższym wydaniu systemu, oraz określić priorytety poszczególnych funkcji. Efektem gry jest lista funkcji, które są najbardziej wartościowe dla klienta, z oszacowaniem czasu realizacji i przydzielonymi wykonawcami.
  • Metafora - nieformalny opis systemu, jego zachowania i środowiska w którym będzie pracował. Jej głównym odbiorcą jest klient, dla którego powinna być zrozumiała. Ten sposób opisu jest zbliżony do narracyjnej specyfikacji wymagań znanej z metodyk przedstrukturalnych. Metaforę tworzą wspólnie wszyscy interesariusze. Stanowi ona pomost między klientem i programistami, dlatego powinna posługiwać się językiem zrozumiałym dla obu stron.
  • Udział klienta w zespole - obecność klienta oznacza jego zainteresowanie przedsięwzięciem, okazjonalny udział w spotkaniach i ścisłe określenie wymagań. Programowanie Ekstremalne zakłada znacznie ściślejszą współpracę klienta z zespołem wykonawców. Przedstawiciel klienta jest członkiem zespołu nie tylko nominalnie, ale realnie: na bieżąco i stale uczestniczy w przedsięwzięciu, posiada pełną wiedzę dziedzinową i jest w stanie podjąć wszelkie decyzje projektowe, w tym planistyczne.

Projektowanie

Projektowanie w XP jest ściśle związane z programowaniem. Projekt powstaje tuż przed kodowaniem i powinien obejmować tylko tę funkcjonalność, która właśnie ma zostać zaimplementowana. Kod programu jest także jedynym dokumentem projektowym.
  • Prostota projektu - regułą, na której opiera się projektowanie w XP, jest tworzenie najprostszych działających rozwiązań. Dobry projekt, to taki z kolei, który przechodzi pomyślnie wszystkie testy jednostkowe i funkcjonalne, nie ma redundancji logicznych oraz zawiera najmniejszą możliwą liczbę komponentów niezbędnych do realizacji wymaganej funkcjonalności.

Kodowanie

Kodowanie jest najważniejszą czynnością w Programowaniu Ekstremalnym. Dotychczas, w miarę rozwoju klasycznych metod inżynierii oprogramowania, było ono stopniowo zaniedbywane. Do tej pory, w miarę rozwoju klasycznych metod inżynierii oprogramowania, było ono stopniowo zaniedbywane. Proces ten wraca teraz jednak do źródeł i z powrotem koncentruje uwagę na kodowaniu.
  • Częste wydania - samo wydanie to działający produkt realizujący określone funkcje. W poszczególnych wydaniach funkcjonalność jest rozwijana i uzupełniana aż do osiągnięcia stanu docelowego. Programowanie Ekstremalne zakłada częste tworzenie wydań, co 1 – 3 tygodnie. W tym czasie system jest wzbogacany o implementacje, a następnie system musi przejść testy funkcjonalne.
  • Refaktoryzacja - zmiana struktury kodu bez zmiany realizowanej przez niego funkcjonalności. Refaktoryzacja w XP opiera się na wzorcach projektowych, czyli standardowych metodach realizacji powszechnie spotykanych zagadnień projektowych.
  • Współwłasność kodu - praktyka wedle której, każdy programista może zmienić, uzupełnić, dopisać dowolny fragment kodu, także napisany przez inną osobę. Takie podejście bez postawienia wymagania, aby system zawsze przechodził pomyślnie przez testy, może mieć negatywne skutki. Niemniej jednak praktyka ta bardzo upraszcza procedurę wprowadzania zmian. Ponadto zaletą tej praktyki, poza uniezależnieniem się od fluktuacji pracowników, jest realne poczucie efektu synergii oraz integracja zespołu.
  • Ciągła integracja - częste wydania systemu wymagają, aby każda nowa funkcja była szybko integrowana z resztą systemu. XP zakłada, że integracja jest przeprowadzana co kilka godzin, nie rzadziej niż raz dziennie.
  • Brak nadgodzin - praktyka o raczej socjalnym charakterze, ale ponieważ dotyczy programistów, została zakwalifikowana jako praktyka programistyczna. Jest ona często postrzegana jednoznacznie jako przyjazna wyłącznie programistom, natomiast klient nie odnosi z niej żadnej korzyści. Jest to mylne założenie, gdyż w zgodzie z nim informatycy pracują wydajniej i skuteczniej, niż gdyby pracowali dłużej, tym samym częściej podlegając zmęczeniu.
  • Standard kodowania - skuteczne wdrożenie zasady współwłasności kodu wymaga, aby wszyscy programiści czuli się jego współautorami, aby łatwo czytali go i rozumieli oraz aby potrafili go modyfikować. Wprowadzenie standardu kodowania jest koniecznym krokiem w tę stronę. Standard kodowania nie musi być dokumentem, ale powinien być normą.

Testowanie

Programowanie Ekstremalne posiada dwa rodzaje testów:
  • jednostkowe - są pisane i wykonywane przez programistów w celu stwierdzenia, czy dany fragment kodu daje poprawne wyniki
  • funkcjonalne - służą stwierdzeniu, czy funkcjonalność wymagana przez klienta została zaimplementowana poprawnie


Zasadą testowania w XP jest testowanie zgodnie z ludzką naturą, czyli pozostawiając pisanie kodu jako najważniejszą czynność procesu, choć w ścisłym związku z testowaniem.

Warto zaznaczyć, że tworzenie i wykonywanie testów jest czynnością żmudną, dlatego zwykle jest ona odkładana na koniec procesu. Gdy brakuje czasu, faza testowania jest często skracana. Jednak testowanie jest zbyt ważne, aby można je pominąć lub zredukować, dlatego XP proponuje rozpoczęcie testowania przed kodowaniem, a następnie utrzymywania i aktualizacji zestawów testowych w miarę postępu prac programistycznych.

Programowanie parami

Jednym z filarów, na których oparto metodykę Programowania Ekstremalnego, jest uznanie kodowania za kluczową czynność procesu rozwoju oprogramowania. Programowanie parami jest z kolei najbardziej znaną, ale i kontrowersyjną praktyką XP. To nowatorskie podejście zyskało już sobie liczne grono entuzjastów, jednak wciąż spotyka się z wyrazami krytyki.

Na czym polega ta praktyka? Programiści piszą w parach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w parze zamieniają się rolami co kilkadziesiąt minut. Ta technika umożliwia wyłapanie wielu błędów oraz wzajemną naukę. Kod, którym zajmuje się tylko jedna osoba, ma tendencje do stawania się całkowicie niezrozumiałym dla kogokolwiek innego niż autor, więc dodatkowy programista zwiększa jakość kodu. Nie jest jasne, czy sumarycznie łączna wydajność pracy przy takiej metodzie jest wyższa, taka sama, czy niższa niż w tradycyjnym programowaniu indywidualnym. Na pewno programowanie parami w znaczny sposób ułatwia komunikację po-między członkami zespołu.

Warto zaznaczyć, że programowanie parami może być skuteczne wyłącznie przy spełnieniu następujących warunków:
  • obowiązuje standard kodowania, co pozwala uniknąć trywialnych sporów
  • wszyscy programiści są wypoczęci i zmotywowani, co znacznie zmniejsza prawdopodobieństwo powstawania konfliktów oraz pomaga skupić się na celu
  • programiści najpierw tworzą testy jednostkowe, co podwyższa jakość tworzonego kodu
  • metafora jako używana jako podstawa do budowania nazewnictwa oraz komunikacji między partnerami w parze
  • projekt zawiera najprostsze rozwiązania, które realizują założoną funkcjonalność


Wady i zalety

Zalety:
  • Koniec z pisaniem dokumentacji – liczy się komunikacja ustna.
  • Można zapomnieć o standardach specyfikowania wymagań i tym podobnych uciążliwościach – potrzebny jest tylko kod programu i przypadki testowe.
  • Zbędne stają się punkty funkcyjne Albrechta – wystarczy odpowiednia rozmowa z klientem w formie tzw. gry planistycznej.
  • Niepotrzebne są inspekcje bowiem zastępuje je programowanie parami (jedna osoba pisze kod, a druga na bieżąco kontroluje pracę partnera).
  • Bardzo krótkie wydania (nawet 1-miesięczne) zmniejszają ryzyko przedsięwzięcia.


Wady:
  • Brak dokładnej specyfikacji.
  • Konieczna stała dostępność przedstawiciela klienta.
  • Wspólna "własność" kodu - każdy może zmieniać dowolny fragment systemu.
  • Metoda jest efektywna gdy wszyscy pracownicy są zaangażowani.
  • Brak struktur i procedur dokumentacyjnych.
  • Wymaga zmiany kulturowej w organizacji w celu wdrożenia.
  • Może prowadzić do trudnych negocjacji kontraktowych.
  • Może spowodować wzrost zakresu działań, ze względu na brak opisanych wymagań i potrzeb.
  • Wymaga prowadzenia stałych spotkań, w pewnych odstępach czasu, przy jednoczesnych dużych wydatkach dla klienta.


Zobacz też

Bibliografia

ostatnia modyfikacja 20 sierpnia 2016 r.