Przykład metody lekkiej — EXTREME PROGRAMMING

Drugą z metod lekkich, która została podobnie jak SCRUM poddana analizie z punktu widzenia przydatności do zarządzania projektami jak też dekompozycji do poziomu dobrych praktyk, była metoda programowania ekstremalnego XP (ang. Extreme programming) [67]. Jej dobór wynikał ze znacznej przydatności tej metody do zarządzania projektami, jak też jej reprezentatywności grupy metod lekkich. Metoda ta była odpowiedzią na dość proceduralne i formalne prowadzenie projektów z wykorzystaniem metod ciężkich [74]. Zamysłem głównego twórcy metody, Kenta Becka, było opracowanie metody zarządzania projektami informatycznymi bazującej na perspektywie programisty, a nie perspektywie klasycznego zarządzania. Tym samym metoda ta stanowi zestaw dobrych praktyk dotyczących sposobu realizacji projektów informatycznych. Poniżej zebrano dobre praktyki XP zagregowane w trzech grupach: realizacji procesów, zarządzania zespołem oraz wytwarzania dokumentacji.

Dobre praktyki — zarządzanie procesami

Dobre praktyki zarządzania procesami opierają się na prostych regułach odniesionych do czterech procesów projektowych: planowania, projektowania, kodowania i testowania. Koncentrują się na procesach: maksymalnego uproszczenia realizowanych zadań, bezpośredniej komunikacji członków zespołu i zapewnienia mechanizmów sprzężenia zwrotnego w ocenie powstających produktów.

Koncentrują się także na odwadze w formułowaniu wizji systemu oraz wspólnej odpowiedzialności za realizowane prace.

Maksymalne uproszczenia realizowanych zadań oznacza eliminację wszelkich zbędnych czynności podczas realizacji projektu oraz możliwie duże uproszczenie kodu źródłowego. Cechą charakterystyczną związaną z tą dobrą praktyką jest podejście refaktoryzacji, czyli poprawiania oprogramowania metodą małych przyrostów.

Druga dobra praktyka sugeruje położenie największego nacisku podczas realizacji zadań na bezpośrednią (werbalną) komunikację wszystkich członków zespołu. Zaleca się w tym celu krótkie spotkania operacyjne (podobnie jak w metodzie SCRUM), których celem jest porządkowanie bieżących spraw i zespołowe rozwiązywanie problemów.

Trzecia dobra praktyka dotyczy zapewnienia mechanizmu sprzężeń zwrotnych w procesach oceny powstających produktów. Dzięki takiemu podejściu możliwe jest szybkie poprawienie ewentualnych błędów z udziałem klienta. Podstawą dla takich procesów powinny być testy akceptacyjne, które klient przygotowuje wraz z testerami.

Kolejną dobrą praktyką jest wartościowanie odwagi w formułowaniu wizji projektu oraz podejmowaniu działań przyrostowych. Praktyka ta dotyczy także potrzeby odrzucania części wykonanej pracy. W przypadku, jeżeli system nie spełnia oczekiwań klienta albo klient te oczekiwania zmienił, należy podjąć decyzję o odrzuceniu części wytworzonego kodu.

Ostatni z głównych fundamentów metody XP opiera się na zasadzie wspólnej odpowiedzialności za realizowane prace. Zaleca się zatem, aby tworzony kod programistyczny był na tyle przejrzysty, aby inne osoby były w stanie wykorzystać ten kod w dalszych pracach. Przykład procedury postępowania z zastosowaniem dobrych praktyk przedstawiono na rys. 1.6.

Rys. 1.6 Realizacja projektu wg metody XP Źródło: opracowanie własne na podstawie [102]

Dobre praktyki — zarządzanie zespołem

Metoda XP zawiera także szereg dobrych praktyk związanych z zarządzaniem zespołem. O tym, że udział zespołu w podejmowaniu decyzji jest znaczny, zostało już powiedziane w poprzedniej części poświęconej dobrym praktykom odniesionym do procesów realizacji projektu. Dobre praktyki dotyczące organizacji zespołu sugerują uwzględnienie dwóch nadrzędnych ról: programisty oraz klienta. Nie mówi się zatem o żadnej złożonej strukturze organizacyjnej (jak to było w metodzie PRINCE2), ale o równorzędnych członkach zespołu. Każdy z nich ma prawo głosu przy podejmowaniu decyzji odnośnie realizacji określonych prac projektowych.

Należy zaznaczyć, że niezwykle ważne jest traktowanie klienta jako członka zespołu. Według dobrych praktyk klient powinien stale współpracować z zespołem. Rolą klienta jest specyfikowanie wymagań w stosunku do systemu poprzez przygotowanie odpowiedniej jego metafory dotyczącej wytwarzanego oprogramowania.

Oprócz tych dwóch głównych ról, dobrą praktyką jest powołanie ról pomocniczych, takich jak tester (którego zadaniem jest przygotowanie skryptów testowych podczas rozmów z klientem), osoby czuwającej nad poprawnym przebiegiem prac i pomagającej rozwiązywać problemy (ang. coach) (odpowiednik Mistrza Młyna w metodzie SCRUM) oraz osoby odpowiedzialnej za analizę postępów prac i monitorowanie przebiegu projektu (ang. tracker) [85].

Dobrą praktyką charakterystyczną dla metody XP PROGRAMMING jest programowanie parami.

Utworzenie par wpływa na jakość wytwarzanego oprogramowania, gdy podczas programowania jedna osoba (zwana autorem) tworzy kod, a druga (recenzent) go weryfikuje. Praca parami ma również wymiar integracyjny. Warto nadmienić również, że metoda XP zakłada wymienność osób w ramach par.

Dobre praktyki — Wytwarzanie dokumentacji

Dobre praktyki związane z dokumentacją zawarte w metodzie XP sugerują brak wytwarzania dokumentacji. Stosowanie procesów refaktoringu, upraszczania kodu i programowanie parami powinny zapewnić czytelny i przejrzysty kod programu (uzupełniony dokumentacją w formie komentarzy). Jedyne dokumenty, jakie zaleca się w metodzie XP, to małe, zazwyczaj pojedyncze kartki służące spisaniu oczekiwań klienta podczas gry planistycznej. Nie stanowią one jednak scalonej formy dokumentacji.

Wybór dobrych praktyk

Po dokonaniu analizy metody XP można przystąpić do zestawienia tych dobrych praktyk, które mogą być istotne z punktu widzenia podejmowanych decyzji przez kierownika projektu informatycznego i które mogą przyczynić się wyodrębnienia zagregowanych zmiennych decyzyjnych.

Wybrane dobre praktyki zestawiono w tabeli 1.8, prezentując także kontekst ich zastosowania.

Tab. 1.8 Dobre praktyki wg metody XP

DOBRA PRAKTYKA UZASADNIENIE

Rozpoczęcie pracy od wymagań klienta Pozwala na włączenie klienta do pracy zespołu oraz na szybką weryfikację przez klienta wykonanych działań.

Zastosowanie programowania parami Pozwala na dzielenie się wiedzą oraz wzajemną kontrolę tworzonego kodu programowego.

Realizowanie zadań w oparciu o testy Pozwala na realizację tylko tych funkcjonalności, które są niezbędne.

Planowanie krótkich przebiegów, zaczynając od najprostszych działań

Pozwala na częstą weryfikację wytwarzanego oprogramowania oraz na rozwijanie produktu projektu informatycznego oddolnie.

Zawieranie dokumentacji w kodzie w formie komentarzy

Pozwala na tworzenie przejrzystego kodu, czytelnego dla pozostałych członków zespołu.

Tworzenie metafory systemu Pozwala na przełożenie oczekiwań klienta w sposób zrozumiały dla wszystkich.

Źródło: opracowanie własne na podstawie [85,102]

Ocena metody

Dobre praktyki zawarte w metodzie XP podkreślają znaczenie programisty w procesach wytwarzania i zarządzania projektem. Oznacza to, że koncentrują się one na procesach wytwórczych celem ich maksymalnego uproszczenia. Jeżeli założymy, że ograniczone jest także wytwarzanie dokumentacji, pojawia się pytanie, w jaki sposób zarządzać projektem w tak ograniczonych warunkach. Odpowiedzią na tak postawione pytania jest wskazanie, że możliwe jest to pod warunkiem odpowiedniego poziomu dojrzałości zespołów realizujących projekty z wykorzystaniem dobrych praktyk metody XP oraz w sytuacji niewielkich projektów realizowanych z zastosowaniem tych praktyk.

Ważne staje się podkreślenie znaczenia roli klienta. Klient i jego rola w procesach wytwarzania oprogramowania była oznaczana wielokrotnie w uprzednio omawianych dobrych praktykach. W tym przypadku jednak klient jest przeciwstawiony programiście i wskazane jest środowisko współpracy obu partnerów. Środowiskiem tym są: metafora systemu oraz małe wydania produktów wytwarzanego systemu informatycznego. Podkreśla się także znaczenie dobrych praktyk dotyczących komunikacji partnerów projektowych. Oznacza to, że porządkując role w zespole i traktując je z pespektywy programisty lub klienta można tworzyć metafory systemu i małe wydania produktów. Takie podejście oznacza także, że można tworzyć odpowiednie warunki dla procesów zarządzania projektami. Ten widziany z perspektywy XP ogranicza liczbę ról, ale jednoczenie dostarcza odpowiednie mechanizmy komunikacji.

Analiza dobrych praktyk XP wskazuje również na możliwości analizy stanu projektu poprzez jego ocenę w pespektywie małych wydań systemu. Jeżeli duży system może być wytwarzany w oparciu o znaczną liczbę małych iteracji, to proces wytwarzania może być w całości kontrolowany na poziomie klienta i wytwórcy. Stąd też procesy kontroli projektu, stanu dostawcy i klienta wskazują na stan wykorzystania dobrych praktyk zarządzania projektem.