Wykłady > Zarządzanie projektem w warunkach zmienności > XP - przykład metodyki zwinnej

3.3 XP - przykład metodyki zwinnej



Metodyka Extreme Programming - w skrócie XP - jest jedną z najbardziej znanych i najchętniej stosowanych metodyk z rodziny zwinnych. Metodyka ta zaproponowana przez informatyka Kenta Becka, oprócz cech charakterystycznych dla metodyk zwinnych, zawiera także dodatkowe zalecenia oparte na praktyce i wieloletnich doświadczeniach.
Główną cechą XP jest przyjęcie pozycji programisty i na tej podstawie budowanie takiego środowiska pracy i sposobu zarządzania, żeby pracował on maksymalnie efektywnie.

Metodyka XP określa dwanaście zasad, których należy przestrzegać.

Planowanie

Zasada ta określa, elementy, na które należy zwrócić szczególną uwagę w procesie planowania projektu. Według metodyki plan powinien zawierać określenie zakresu projektu, przy czym największą wagę należy przyłożyć do funkcjonalności kluczowych dla klienta. Dzięki temu najważniejsze oczekiwania biznesowe zostaną spełnione w pierwszej kolejności, a ewentualne opóźnienia wpłyną jedynie na funkcjonalności drugoplanowe. W planie znajdą się także daty zakończenia kolejnych iteracji i definicja produktów poszczególnej z nich. Na tym etapie formułowane są założenia techniczne dla projektu takie jak stosowane technologie, architektura sprzętowa itp.

Krótkie iteracje

Według XP oprogramowanie powinno być wytwarzane w krótkich i częstych iteracjach, aby jak najczęściej przedstawiać klientowi wyniki pracy i dyskutować ewentualne zmiany i poprawki. Zgodnie z poprzednią zasadą, w pierwszej kolejności wytwarzane są najistotniejsze funkcjonalności, więc klient ma szansę na najwcześniejszych etapach projektu wypowiedzieć się o przygotowywanym produkcie. Idealnym rozwiązaniem byłoby, gdyby klient od pewnego etapu mógł zacząć używać w biznesie oprogramowania będącego wynikiem kolejnej iteracji. Takie sytuacje zdarzają się jednak bardzo rzadko w rzeczywistych projektach, ponieważ wymagane jest wtedy także wdrożenie takiego systemu, co wiązałoby się z dodatkową pracą, którą należałoby wykonać. Jeśli jednak jest to możliwe, to informacja zwrotna na temat działającego faktycznie systemu jest najbardziej wartościowa dla projektu.

Metafory

Zasada ta mówi, że przy wytwarzaniu oprogramowania należy wypracować jednoznaczne słownictwo, które będzie stosowane. Często używane określenia są nieprecyzyjne i mogą prowadzić do zamieszania i nieporozumień, dlatego warto w niektórych przypadkach przejść na określenia nieco mniej techniczne, jednak bardziej intuicyjne. Ważną zasada jest, aby w projekcie używane określenia były jednoznaczne i zrozumiałe dla wszystkich.

Prosty projekt

Projekt opisujący realizowany produkt powinien być w założeniach maksymalnie prosty. W pierwszej fazie projektu powinien on obejmować tylko najważniejsze, kluczowe funkcjonalności. Zasada ta uzupełnia się z zasadą planowania w XP – plan skupiający się początkowo na najważniejszych wymaganiach determinuje także zakres projektu. Kolejną ważną cechą projektowania w przedsięwzięciu realizowanym w metodyce XP jest fakt, że projekt w trakcie realizacji zadania podlega zmianom i rozszerzeniom o dalsze moduły. Łatwiej zaprojektować nowe elementy składowe systemu, gdy mamy już pewien produkt bazowy, do którego można się odnieść. Takie podejście ciągnie za sobą jednak konieczność bardzo starannego przygotowania projektu. Mimo że z początku nie zajmujemy się całym systemem, to trzeba jednak przewidując zaprojektować rozwiązanie, żeby w przyszłości umożliwić rozszerzanie systemu. Powinien on obejmować zestaw interfejsów, schemat bazy danych i inne czynniki, od których uzależniony jest cały produkt.

Testowanie

Testy w XP są bardzo ważnym elementem projektu. Podejście Extreme Programming do testowania oprogramowania różni się od podejścia tradycyjnego – testy powinny zostać określone i zaplanowane przed rozpoczęciem implementacji, a nawet przed stworzeniem projektu. Pozwala to na przemyślenie zadania pod kątem spodziewanych problemów, zanim przystąpi się do wytwarzania oprogramowania. Po wczesnym zidentyfikowaniu potencjalnych słabych punktów tworzy się bardziej prawidłowy projekt, a co za tym idzie lepsze oprogramowanie, które w założeniach ma dużo mniej dziur. Ponadto wytworzony system będzie pisany w ten sposób, żeby przechodził testy, ponieważ od początku wiadomo, jakie testy będą przeprowadzone.

Refaktoring

Refaktoring, czyli poprawki kodu to czynnik bardzo ważny w systemach wytwarzanych przy użyciu metodyk przewidujących częste iteracje. Zazwyczaj kod pełen jest takich zbędnych elementów jak tymczasowe bloki, prowizoryczne rozwiązania i inne. Dlatego, żeby doprowadzić go do odpowiedniej jakości należy przeprowadzać działania refaktoringowe. Jakość kodu wyznaczona jest przez poziom zgodności z przyjętymi standardami kodowania, na które składają się konwencje nazewnictwa, sposób przetwarzania wyjątków, itp. Należy jednak zachować przy tym dużą ostrożność i poprawiać kod niewielkimi fragmentami, a następnie zatwierdzać poprawki pomyślnie przeprowadzonymi testami. Refaktoring jest bowiem niczym innym, jak zmianą działającego kodu.

Programowanie w parach

XP przewiduje, że kod wytwarzany jest w zespołach dwuosobowych pracujących przy jednym komputerze nad wspólnym zadaniem. Polega to na tym, że jeden z programistów pisze kod, a drugi kontroluje jego pracę i ewentualnie sugeruje poprawki. Programiści wymieniają między sobą doświadczenia i dzielą zadaniami. Dzięki temu wytworzony kod jest przemyślany, więc także prawdopodobieństwo, że zawiera on błędy jest wyraźnie zmniejszone. Jest to wynikiem tzw. efektu synergii, który sprawia, że efektywność pracy pary programistów jest wyższa niż suma ich efektywności z osobna. Co więcej, kalkulacje pokazują, że koszt zatrudnienia dwóch programistów do jednego zadania rośnie wolniej niż ich wydajność i jakość kodu, czyli jest to działanie bardzo opłacalne także z finansowego punktu widzenia. Programiści w trakcie pracy mogą zamieniać się miejscami, żeby obaj jednakowo wiele czasu spędzaniu na czynnym pisaniu kodu i analizie pracy partnera.

Wspólna własność kodu

Według tej zasady pary programistyczne nie są stałe przez cały czas trwania projektu, ale po zakończeniu poszczególnych etapów programiści zmieniają partnera i mogą zostać skierowani do innych fragmentów systemu. Dzięki temu każdy programista ma dobre  pojęcie o całości oprogramowania i zasadach jego funkcjonowania. Takie podejście sprawia, że wyeliminowane jest ryzyko utraty kluczowego członka zespołu projektowego, ponieważ każdy wszyscy mają mniej więcej tę samą wiedzę o produkcie i nie ma w zespole osób niezastąpionych. Extreme Programming przewiduje także możliwość modyfikacji kodu, któregoś ze współpracowników. Zgodnie z zasadami przyświecającymi metodykom zwinnym, lepiej od razu poprawić zauważoną usterkę w celu wytworzenia sprawnego oprogramowania, niż uruchamiać machinę biurokratyczną i czekać kilka dni na decyzję o zmianie w jednej linii kodu. Wymaga to jednak od programistów wysokiej odpowiedzialności. Wspólna własność to także wspólna odpowiedzialność za kod. Kod, który w dodatku mógł być modyfikowany przez wiele osób, nie ma jednego twórcy, a odpowiedzialność za niego spoczywa na całym zespole. Dlatego po wykryciu usterki wysiłki wszystkich koncentrowane są na jej naprawie, a nie poszukiwaniu odpowiedzialnego za jej spowodowanie. Buduje to jedność w zespole i zmniejsza stres kładziony na pojedynczego członka zespołu.

Ciągła integracja

Każdy dzień pracy przy projekcie wytwarzanym w metodyce XP powinien kończyć się integracją wszystkich elementów składowych systemu. Nawet jeśli funkcjonalności nie zostały ukończone, na koniec dnia kod powinien być w stanie pozwalającym na jego wspólne skompilowanie. Dzięki temu dokonywane jest wersjonowanie oraz identyfikowane są błędy. Konieczność integracji pozwala na wykrycie błędu, a jej wysoka częstotliwość na zlokalizowanie miejsca jego pochodzenia. Efektem tego jest szybkość procesu naprawczego, ponieważ uniknięte zostało integrowanie ogromnych systemów, w których niezgodności byłoby dużo trudniej zidentyfikować. XP mówi także o tym, że dopóki nie zostanie naprawiony błąd, żaden nowy moduł nie może zostać zintegrowany z głównym systemem. Dzięki temu unika się nakładania się błędów, które są wyjątkowo trudne w naprawie. Oczywiście pozostałe zespoły mogą kontynuować pracę, jednak nie mogą się zintegrować, czyli potencjalnie dodać nowych błędów, dopóki znane błędy nie zostaną rozwiązanie.

Czterdziestogodzinny tydzień pracy

Twórcy metodyki doszli do wniosku, że najbardziej wydajny jest zadowolony programista, czyli wypoczęty, posiadający życie prywatne, mający czas dla siebie. W związku z tym nadgodziny powinny zostać zminimalizowane, ponieważ wynagrodzenie za godziny nadliczbowe nie jest w stanie zrekompensować utraty wolnego czasu. Oczywiście zdarzają się sytuacje, kiedy trzeba zostać nieco dłużej w pracy, jednak gdy takie dni zdarzają się dłużej niż trzy do pięciu dni, wtedy należy przyjrzeć się organizacji pracy, bo to oznacza, że programista jest przeciążony. Czterdziestogodzinny tydzień pracy oznacza, że dzień pracy nie powinien trwać dłużej niż osiem godzin, jednak godziny pracy programistów nie muszą być sztywno określone. Każdy powinien pracować w godzinach najbardziej mu do tego dogodnych. Warto jednak, żeby umówić się na pewien przedział czasowy, kiedy wszyscy członkowie zespołu będą w biurze, żeby na przykład przeprowadzić spotkania. Jasno określona długość dnia pracy pozwala na dokładne przewidzenie pozostałego czasu jakim dysponuje kierownik projektu i identyfikację ewentualnych opóźnień, ponieważ nie można liczyć na dodatkowe, w pewnym sensie niejawne, godziny przeznaczone na realizację projektu.

Klient jest zawsze dostępny

Ta zasada XP jest nierzadko najtrudniejszą do spełnienia w projektach informatycznych. Mówi ona, że w każdej chwili, na każdym etapie realizacji projektu, istnieje możliwość konsultacji z klientem. Pod pojęciem klienta należy rozumieć starannie wybraną osobą lub osoby, które będą oddelegowane do współpracy z zespołem projektowym. Ważne jest, żeby osoby te rzeczywiście były zainteresowane projektem i poświęcały mu większość swojego czasu. Często organizacja klienta nie docenia ważności współpracy na etapie realizacji projektu. Klient powinien brać ważny udział w pracach fazy analizy przy określeniu najważniejszych z punktu widzenia biznesowego funkcjonalności systemu oraz w dalszych etapach, gdy niezbędne będą odpowiedzi na niejasności przy realizacji projektu, które pozwolą uniknąć niepotrzebnych postojów przy oczekiwaniu na odpowiedź oraz błędów merytorycznych w przypadku podjęcia złej decyzji bez konsultacji z klientem.

Standardy kodowania

Zasada dotycząca standardów kodowania bardzo ściśle wiąże się z zasadami dotyczącymi refaktoringu i pracą w parach. Przyjęcie jednolitych standardów kodowania pomaga programistom łatwe rozumienie się przy wytwarzaniu kodu. Przewidują oni niejako, co partner chce napisać, dlaczego i jaki będzie tego efekt. Ponadto standardy kodowania określają zasady dla refaktoringu. Wiadomo, jak kod powinien wyglądać i do jakiego stanu powinien dążyć. To właśnie standardy kodowania określają poziom jakości wytworzonego kodu. Dodatkową ważną zaletą stosowania wspólnych standardów jest niejawne komentowanie kodu. Osoba czytająca go w przyszłości łatwiej zrozumie treść w nim zawartą, jeśli na przestrzeni całego projektu podobne struktury będą realizowane w ten sam sposób.


Extreme Programming jest bardzo dobrym przykładem metodyki zwinnej. Stosuje on praktycznie wszystkie postulaty Manifestu Agile na przestrzeni wielu aspektów zarządzania projektem. Stawia na dużą swobodę jeśli chodzi o proces wytwarzania oprogramowania, przy jednoczesnym nacisku na jakość oprogramowania i jego zgodność z oczekiwaniami klienta. W tym miejscu jeszcze raz warto opisać różnicę między oczekiwaniami klienta, a wymaganiami na system. Klient podejmuje decyzję o rozpoczęciu projektu w wyniku pewnych potrzeb, które chciałby, żeby projekt zaspokoił. Dlatego zadowolenie klienta osiąga się dostarczając mu produkt, który będzie mu przydatny i odpowiadał na jego potrzeby. Nie zawsze w fazie określenia wymagań udaje się przekazać informacje o faktycznych potrzebach klienta, dlatego dokument specyfikacji wymagań nie jest najważniejszy i nienaruszalny podczas realizacji projektu. Najważniejsze jest zadowolenie klienta, który będzie używał dostarczonego mu produktu. XP odchodzi także od sztywnych ram nakładanych przez inne metodyki, podchodząc do zagadnienia projektu z szacunkiem dla jego wykonawcy. Postawienie osi metodyki na osobie programisty pozwala tak określić otaczające go środowisko, żeby osiągnął on maksymalną wydajność przy wysokim zadowoleniu z pracy.
Model Extreme Programming ( XP ) został opracowany po to, aby ułatwić właściwa organizację pracy niewielkich zespołów zajmujących się projektami informatycznymi. Bardzo ważna jest liczebność zespołów. Dziesiątka jest najbardziej rozsądną liczbą programistów biorących udział w projekcje XP. Nie należy uruchamiać projektu z większą liczbą programistów. Bardzo ważnym elementem jest stworzenie odpowiednich warunków pracy programistom, tak aby mogli w sposób bezpośredni komunikować się ze sobą. Jedno duże pomieszczenie z małymi boksami wokoło i potężnymi maszynami na stołach w środku to najlepsze środowisko dla Extreme Programming. W ten sposób cały zespół programistów widzi, co się dzieje, łatwo można zestawiać pary, każda z nich może korzystać z energii innych par, które programują w tym samym czasie. Model XP rozwiązuje problemy inaczej, czasami nawet sprzecznie z powszechnie akceptowanymi zasadami, nowościami w Extreme Programming są: umieszczenie wszystkich działań we wspólnym miejscu, zapewnienie, by wszystkie one były maksymalnie sprawdzone, zapewnienie, by działania praktyczne wspomagały się wzajemnie w możliwie najwyższym stopniu.
Extreme Programming nie wprowadza formalizmu do procesu wytwarzania oprogramowania. Projekty prowadzone tą metodyką przypominają raczej pracę grupy zapaleńców nad wspólnym wynalazkiem, niż wielką biurokratyczną machinę obudowaną oficjalnymi dokumentami i kontraktami. Twórcy XP twierdzą, że ich metodykę można przyjąć praktycznie dla każdego projektu informatycznego bez względu na jego rozmiar i złożoność. Jednak doświadczenie uczy, że pojedyncza osoba kierownika projektu od pewnego poziomu złożoności systemu nie jest w stanie dobrze kontrolować dość luźno zorganizowanej grupy ludzi. W takich sytuacjach albo dojdzie do naturalnej biurokratyzacji pracy poprzez wprowadzenie do projektu obiegu dokumentów z komunikatami w związku z ilością wymienianych informacji albo projekt całkowicie wyrwie się spod kontroli i zacznie prowadzić się sam w oparciu jedynie o odpowiedzialność członków zespołu projektowego.









Przejdź dalej



Wykłady > Zarządzanie projektem w warunkach zmienności > XP - przykład metodyki zwinnej