WYŻSZA SZKOŁA ZARZĄDZANIA I BANKOWOŚCI
W KRAKOWIE

Wydział Informatyki

• PRACA DYPLOMOWA

• Mateusz Bilski

Wspomaganie zarządzania projektem w oparciu o metodykę Extreme Programming - implementacja narzędzia fleXPlanner

Promotor:

dr inż. Wiesław Byrski

Konsultant:

mgr inż. Jacek Kołodziej

KRAKÓW 2007

Wstęp..................................................................................................................................... 4

Rozdział 1. Filozofia Extreme Programming........................................................................ 5

1.1. Historia powstania.............................................................................................. 5

1.2. Przykłady zastosowań metodyki........................................................................ 7 1.3. Ekonomiczne korzyści stosowania praktyk XP............................................... 13

Rozdział 2. Wartości, zasady i praktyki Extreme Programming........................................ 17

2.1. Wartości............................................................................................................ 17

2.1.1. Komunikacja...................................................................................... 17

2.1.2. Prostota.............................................................................................. 19

2.1.3. Sprzężenie zwrotne.............................................................................20

2.1.4. Odwaga.............................................................................................. 22

2.1.5. Szacunek............................................................................................ 22

2.2. Zasady............................................................................................................... 23

2.2.1. Ekonomia........................................................................................... 23

2.2.2. Wspólna korzyść................................................................................ 23

2.2.3. Doskonalenie..................................................................................... 24

2.2.4. Jakość................................................................................................. 24

2.2.5. Zasada małych kroków...................................................................... 25

2.3. Praktyki……………......................................................................................... 25

2.3.1. Wspólne środowisko pracy................................................................ 25

2.3.2. Proces planowania............................................................................. 26

2.3.3. Cykl tygodniowy/kwartalny.............................................................. 29

2.3.4. Testy.................................................................................................. 30

2.3.5. Refaktoryzacja kodu.......................................................................... 33

2.3.6. Programowanie w parach.................................................................. 33

2.3.7. Stały kontakt z klientem.................................................................... 34

2.3.8. Projektowanie przyrostowe............................................................... 35

2.3.9. Ciągła integracja................................................................................ 35

2.3.10. Wspólny kod.................................................................................... 36

Rozdział 3. Implementacja narzędzia FleXPlanner............................................................ 37

3.1. Założenia aplikacji fleXPlanner............................................................ 37

3.2. Zastosowane technologie….................................................................. 38

3.3. Zaimplementowane funkcjonalności.................................................... 41

Podsumowanie.................................................................................................................... 48

Bibliografia......................................................................................................................... 49

Spis rysunków i tabel......................................................................................................... 50

Wstęp

W dzisiejszych czasach sukces ogromnej większości organizacji jest uzależniony od stosowanego oprogramowania. Zapotrzebowanie na wydajny i pozbawiony błędów software powoduje, że dziedzina inżynierii oprogramowania stale się rozwija. Deweloperzy muszą odpowiadać na rosnące oczekiwania klientów, często zmieniających swoje wymagania, terminy realizacji oraz budżety przeznaczone na rozwój informatyczny. Coraz większą popularność zdobywają lekkie metodyki tworzenia oprogramowania takie jak Scrum, Feature Driven Development i omawiane w tej pracy Extreme Programming. Programowanie ekstremalne zakłada porzucenie założeń modelu kaskadowego (klasycznego), które kiedyś mogły wydawać się pomocne, natomiast w dzisiejszych realiach stanowią już tylko przeszkodę w skutecznej produkcji oprogramowania.

Celem pracy jest wykonanie wstępnego projektu, implementacja oraz przeprowadzenie testów i wdrożenie aplikacji wspomagającej proces wytwarzania oprogramowania w oparciu o metodykę XP. Aplikacja fleXPlanner będzie wspomagać takie elementy procesu tworzenia oprogramowania jak: komunikacja w zespole projektowym, podział projektu na iteracje, formułowanie zadań dla członków zespołu oraz zgłaszanie błędów występujących w tworzonym oprogramowaniu. Wymienione elementy zostały wybrane, ponieważ mają krytyczne znaczenie w metodyce XP, a ich sprawne działanie znacznie wpływa na jakość zarządzania projektem. Realizowany program zostanie oparty na modelu RIA (Rich Internet Application), czyli będzie łączył możliwości dużych aplikacji desktopowych z lekkością i łatwością dostępu strony WWW.

W rozdziale pierwszym oprócz historii powstania XP, zostały pokazane, w oparciu o przykłady, korzyści ekonomiczne i technologiczne wynikające z odpowiedniej adaptacji założeń opisywanej metodyki.

Rozdział drugi przedstawia zestaw podstawowych praktyk stosowanych przez zespoły XP. Opisuje także główne zasady i wartości, których znajomość jest konieczna do zrozumienia i poprawnego ich zastosowania.

W rozdziale trzecim przedstawiono założenia aplikacji fleXPlanner, technologie, które zostały użyte przy jej stworzeniu, oraz dokładny opis działania zaimplementowanych funkcjonalności.

Rozdział 1.

Filozofia Extreme Programming

1.1. Historia powstania

W 1996 roku Kent Beck otrzymał telefon z korporacji Chrysler z propozycją zbadania wydajności systemu do obsługi płac - Chrysler Comprehensive Compensation System (C3). Beck był cenionym fachowcem, pisał prace i wykładał na temat optymalizacji programów w języku Smalltalk. Okazało się, że nie chodzi o zwykłe zadanie optymalizacyjne. Program, który to w założeniu miał do roku 1999 obsłużyć rozdzielanie wypłat dla 87,000 pracowników, nie zwracał nawet poprawnych wyników.

W okresie Wielkanocy roku 1996 ówczesna wiceprezes korporacji Chrysler, Sue Unger, przyjęła propozycje Becka i zgodziła się na rozpoczęcie prac od nowa z mniejszym zespołem.

Do nowego zespołu zwerbowano Rona Jeffriesa [5], który został pierwszym w historii trenerem XP. Martin Flower, konsultant analityczny w firmie Chrysler, był odpowiedzialny za analizę i testowanie nowego systemu. Bob Coe, pracujący przy poprzedniej implementacji projektu, pozostał kierownikiem projektu.

Po skompletowaniu zespołu Beck przeprowadził serię wywiadów z pracownikami nowego zespołu. Podczas ich trwania formowały się pierwsze założenia nowej metodyki, takie jak trzytygodniowe iteracje, w ramach których zespół miał realizować scenariusze. Realizacja pierwszej iteracji miała umożliwić wypłatę przynajmniej jednego wynagrodzenia.

Kent Beck zebrał wszystkie znane mu, a przede wszystkim skuteczne, praktyki inżynierii oprogramowania. Po zakończeniu rozmów z członkami zespołu potrafił już sformułować podstawowe założenia XP.

Tworzony system miał być:

• zawsze gotowy do wdrożenia

• pod stałym nadzorem klienta

• testowany automatycznie

• realizowany w krótkich cyklach iteracyjnych

Była to tylko ogólna wizja metodyki, którą nowy zespół musiał wprowadzić w życie i sprawdzić jej skuteczność. Jednym ze sposobów na szybki rozwój i integrację zespołu było wprowadzenie, jako jednej z obowiązkowych praktyk, programowania w parach.

Spisano listę scenariuszy, opierając się na głównych założeniach systemu. Następnie zorganizowano całodniowe spotkanie z klientem, na którym zostały wybrane scenariusze niezbędne do osiągnięcia podstawowej funkcjonalności. Weszły one w skład pierwszej, trzytygodniowej iteracji.

Beck obiecał kierownictwu Chryslera, że C3 zostanie ukończony w terminie, czyli w styczniu 1997 roku. Jednak pod koniec 1996 roku okazało się, ze zespół nie dotrzyma obiecanego terminu. System obliczał poprawnie wypłaty, jednak w plikach wynikowych program zwracał błędne dane.

System C3 otrzymał wymagane certyfikaty w marcu 1997 i został wdrożony w kwietniu tego samego roku. Funkcjonował do 1 lutego 2000 roku. Został wycofany z powodu zmian technologicznych, a także przemian w samym Chryslerze, który został wykupiony przez inna korporacje - Daimler-Benz.

Pomimo krótkiego okresu użytkowania system Chrysler Comprehensive Compensation był sukcesem finansowym i technologicznym. Dodatkowo był tani w utrzymaniu i miał dużą niezawodność. Okazało się, że posiada on niezwykle małą ilość usterek w porównaniu do innych systemów podobnej wielkości. [2]

1.2. Przykłady zastosowań metodyki

Firma: Acxiom

Zespół: managerzy, analitycy biznesowi, deweloperzy, testerzy i redaktorzy techniczni

Aplikacja: Campaign Managment Database [3]

Czas: 3 lata

• Na podstawie ogromnych baz danych i w oparciu o narzędzia do wspomagania budowy oprogramowania Forte OO Acxiom stworzył aplikacje do wspomagania kampanii.

• Zespół składał się z 10 programistów, którzy stworzyli system w ciągu 3 lat, przy czym w 2 ostatnich, kluczowych latach rozwoju oprogramowania stosowano metodykę XP.

• Acxiom postawił na prostotę projektu. Wcześniej firma stosowała design, który brał pod uwagę późniejsze iteracje oprogramowania. To nie było dobre podejście. Odkryto, że dzięki szablonom i dobrej komunikacji w zespole, firma może stworzyć fleksyjną i łatwą w modyfikacji aplikację dźwiękową.

• Refaktoryzacja ogrywała bardzo ważna rolę w rozwoju systemu. Było oczywiste, że jeżeli zespół obawiał się zmiany i poprawek pewnych części kodu, to prowadziło to do coraz większej niepewności działań.

• Testy jednostkowe nie były łatwe do zaimplementowania, gdyż oprogramowanie Forte nie miało wbudowanego komponentu do testowania. Zespół stworzył swój własny framework testowy i z powodzeniem z niego korzystał. W późniejszym czasie firma zmieniła technologie na Jave i zaczęła używać popularnego JUnit.

• Kluczem do XP według firmy Acxiom jest wspólny cel dla programisty, jak i dla całego zespołu. Przekonano się, że wszyscy uczestnicy projektu muszą wierzyć w skuteczność praktyk XP, bo inaczej nie spełniają one swojego zadania. Jeżeli chociaż jedna osoba będzie przeciwna i oporna na nowe metody to wyraźnie obniży efektywność całego zespołu. XP skupia się na pracy całego zespołu i wspólnych pomysłach dalszego rozwoju tworzonego systemu.

• Kiedy firma zaczęła wdrażać metodykę XP, niektórzy programiści nie byli z tego zadowoleni. Twierdzili, że ma ona negatywny wpływ na ich styl pracy i równocześnie obniża jej efektywność. Okazało się, że ich cześć kodu miała najwięcej usterek i sprawiała najwięcej problemów. Nie programowali oni w parach, więc projekt ich podsystemu był dużo gorszy niż par programistów, którzy stale uczyli się od siebie i rozwijali swoje umiejętności. Dwóch deweloperów o średnich umiejętnościach pracujących razem daje lepsze rezultaty niż jeden zdolny, który pracuje sam.

• Programiści z Acxiom przekonali się, że praca w parach nie zmniejsza kreatywności i nie spowalnia rozwoju, a wręcz przeciwnie, ma ogromny wpływ na samodoskonalenie. Zwiększa także chęć podejmowania nowych wyzwań przez członków grupy.

Firma: Rob Mee, niezależny konsultant

Zespół: 3 deweloperów

Aplikacja: Shipping Tariff Calculation System [3]

Czas: 3 miesiące

• Tariff System to podsystem bardzo dużego projektu tworzonego za pomocą Smalltalk/GemStone dla międzynarodowego lidera w transporcie kontenerów.

• Wykorzystując techniki XP, Tariff System w ciągu 3 miesięcy i przy współpracy trzyosobowego zespołu przerodził się z koncepcji w pełni funkcjonalny i stosowany system. Efekt końcowy okazał się być niezwykle stabilny i łatwy w utrzymaniu.

• Na początku projektu zespół postanowił korzystać z kilku fundamentalnych praktyk XP: zawsze programuj w parach, użyj najprostszego projektu, korzystaj agresywnie z refaktoryzacji kodu i pisz dużo testów jednostkowych. Wszystkie te praktyki dawały bardzo dobre efekty.

• Praktyka, która z początku wydawała się bardzo wyszukana i naciągana, dawała dużo satysfakcji i przyspieszała prace. Było to pisanie testów przed pisaniem kodu. Zespół odczuł, że taki system programowania pozwala im bardziej skupić się na wprowadzaniu projektów w życie i przyspieszyć prace.

• Kolejną praktyką, z której zespół korzystał od samego początku, było zbieranie scenariuszy wymagań od klienta. Zespół miał mieszane uczucia, co do takiego sposobu ciągłej współpracy ze zleceniodawcą. Jako ludzie skupieni na programowaniu, nie byli przyzwyczajeni do ciągłej negocjacji i spotkań. Ważniejsze było jednak to, że musieli stale pomagać przyszłym użytkownikom w formułowaniu zadań, które byłyby trafne i niedwuznaczne. Pod koniec projektu zdano sobie sprawę, że do zespołu XP potrzebna jest osoba, która będzie tylko i wyłącznie odpowiedzialna za kontakt z klientem i będzie do tego odpowiednio predysponowana.

• Wynikiem dużego nacisku i wkładu w pisanie testów, było stworzenie przez zespół własnego języka, który opisywał w prosty sposób skomplikowane obiekty. Dzięki temu kod testowy był czytelniejszy, a tworzenie instancji obiektów do testowania stało się dużo prostsze. Programiści stworzyli gramatyki dla dziesięciu głównych klas swojego systemu.

Firma: Sabre Airline Solutions [2]

Zespół: 240 developerów, 25 osób na stanowiskach kierowniczych i w księgowości, 35 osób odpowiedzialnych za testowanie i konfiguracje

Zadanie: Ujednolicenie pracy trzynastu odrębnych zespołów projektowych.

• Brad Jansen z Sabre Airline Solutions otrzymał zadanie ujednolicenia pracy trzynastu zespołów wchodzących w skład jednej organizacji. Zdecydował, że jego główną strategią będzie stosowanie Extreme Programming.

• Zorganizowano dla każdego zespołu tygodniowe szkolenie z odpowiednio wytypowanym trenerem XP. 13 zespołów w 13 tygodni. Następnie zaczęto stosować praktyki XP, lecz w dalszym ciągu odbywało się to pod okiem ekspertów. Pod koniec szkoleń Jensen doszedł do wniosku, że lepszym rozwiązaniem będzie wyszkolenie jednego zespołu, który następnie przeszkoliłby pozostałe.

• W projektach, które dobrze odpowiadają specyfice XP, zespół korzysta ze wszystkich praktyk. Najlepiej sprawdza się to przy implementacji systemów w języku Java i z bardzo dobrze zmotywowanym zespołem. Jeżeli zachodzi potrzeba adaptacja starego kodu napisanego w innych językach (Np. C++), zespół korzysta z reguł XP osadzonych w procesie kaskadowym. Pod koniec rozwoju takiego projektu następuje faza testów oprogramowania. Bard podkreśla, że podczas przerabiania takich systemów, nie są w stanie zachować prostoty projektu, gdyż sam proces produkcji takiego programu jest bardzo skomplikowany. Trudniejsze jest też pisanie testów, co powoduje dużą ilość błędów. Deweloperzy stosują więc, na początku i końcu cyklu tworzenia aplikacji, proces kaskadowy.

• Korzyści płynące z korzystania metodyki XP są ogromne. W jednym z projektów, o których wspomina wicedyrektor, nie wykryto od 2 lat żadnego defektu. Systemy, które są adoptowane w starszych technologiach również utrzymują bardzo niski poziom błędów. Są to mniej więcej 2 błędy na tysiąc linijek kodu. Jansen porównuje to z wynikiem konsorcjum Bangalore SPIN, w którym zgłasza się przeciętnie 8 defektów na tysiąc linii kodu.

• Porównanie rozwoju oprogramowania sprzed i po wprowadzeniu XP, pokazuje wzrost wydajności o 40%.

• Docelowo około 80-90% deweloperów przyjmuje techniki XP bez oporów, 10-20% zachowuje sceptycyzm, a około 5% nigdy ich nie akceptuje. Na początku wprowadzania nowych reguł rozkład ten był wyrównany, gdyż pracownicy nie wiedzieli, jakie korzyści niesie ze sobą zmiana starych przyzwyczajeń.

• Bardzo poważnie traktuje się udział klienta w cyklu tworzenia oprogramowania. Klienci współpracują w ramach organizacji zarządzającej produktami. Z każdym zespołem współpracuje jeden przedstawiciel zleceniodawcy. Jak podkreśla Jansen, jedno oprogramowanie może służyć kilku liniom lotniczym, dlatego do zadań kierownika produktu należy dbanie o interesy każdej z nich. Zbiera on informacje na konferencjach i forach użytkowników systemu. Na zebraniach projektowych ustalany jest kierunek rozwoju danego oprogramowania na najbliższy rok lub dwa.

• Współpraca ze zleceniodawcą w miejscu w pracy jest wskazana przez XP, ale może też przysparzać problemy. Trzeba odpowiednio selekcjonować spostrzeżenia i sugestie klientów, aby aplikacja rozwijała się w odpowiednim kierunku. Niektórzy z klientów Sabre sami piszą scenariusze i testy akceptacyjne. Są też tacy, którym trzeba pomagać w tworzeniu scenariuszy, ale już w precyzowaniu testów akceptacyjnych nie chcą brać udziału. Zdarzają się jednak i tacy, którzy przed samym terminem ukończenia prac, przypominali sobie o bardzo ważnych i czasochłonnych funkcjonalnościach. Robili to oczywiście w celu zaniżenia kosztów.

• W Sabre obowiązuje kwartalny system dystrybucji i dwutygodniowe cykle iteracyjne, od których nie stosuje się wyjątków.

• Według Jansena najważniejszą rzeczą jest oparcie planowania na możliwościach tworzonego systemu. Kolejne elementy planu powinny odzwierciedlać najważniejsze z punktu widzenia klienta funkcjonalności. W ten sposób, każda kolejna dystrybucja systemu będzie funkcjonować zgodnie z oczekiwaniami zleceniodawcy.

Firma: Lunar Logic Polska

Zespół: 20 pracowników polskiego oddziału Lunar Logic

Zadanie: Wdrożenie lekkich metodyk z rodziny „Agile” (w tym XP). [10]

• Bezpośredni udział klienta w tworzeniu oprogramowania nie zawsze musi dawać pozytywne efekty. Jeżeli zleceniodawca nie zdaje sobie sprawy z wymagań, jakie stawia przed nim Agile, to może dojść do różnego rodzaju nieporozumień. Jeden z klientów Lunar zażyczył sobie kontynuowania prac nad ukończoną wersją produktu. Był zadowolony z tempa prac, ale w jego rozumieniu program gotowy do użycia to taki, który ma zaimplementowane wszystkie założone wcześniej funkcjonalności. Nie można było kontynuować prac nad daną wersją, ponieważ zalecenia i termin zostały zrealizowane, a zespół powinien przystąpić do implementacji kolejnej wersji.

• Iteracyjne podejście do rozwoju oprogramowania daje klientowi możliwość zrezygnowania z dalszej realizacji w każdej chwili. Jeżeli zrezygnuje, to może korzystać z niepełnej, ale działającej wersji software'u. W ten sposób pieniądze włożone w rozwój tworzonego systemu nie są tracone. Iteracyjność daje możliwość obserwacji rozwoju oprogramowania od początku, aż po samo wdrożenie. W systemie kaskadowym klient otrzymuje produkt dopiero po zaimplementowaniu wszystkich funkcjonalności.

• Jednym z obowiązków zespołu XP/Agile jest wytłumaczenie zleceniodawcy pojęć i założeń takiego podejścia. Pewne zwroty są odmiennie rozumiane w różnych metodykach. „Klient” w XP to nie tylko osoba, która płaci rachunki, ale przede wszystkim członek zespołu mający ogromny wpływ na jego prace. Klient ustala kolejność wykonywanych prac, określa wymagania i bierze udział w określaniu założeń fazy testowania. Niedoinformowany klient może być sfrustrowany nawet przy sukcesie projektu.

• Korzystanie z testów jednostkowych daję większą pewność przy refaktoryzacji kodu. Nie jest to tak bardzo istotne przy małych projektach, ale im większy system tym większe korzyści z testów.

• Zarząd nie jest przekonany do programowania w parach. Przy pracach nad małymi projektami, zespół, który znajduje się w jednym biurze i konsultuje na bieżąco architekturę systemu, daje satysfakcjonujące rezultaty.

• Na początku wprowadzania lekkich metodyk zespół umieszczał każdą wersje na serwerze testowym, gdzie klient, po wcześniejszym zalogowaniu, mógł przeglądać postępy pracy. Niektórzy klienci uznali takie rozwiązanie za stratę czasu, więc zaczęto wysyłać maile ze screenshot'ami odpowiednich funkcjonalności (interfejsu graficznego).

1.3. Ekonomiczne korzyści stosowania praktyk XP

Rozdział ten pokazuje korzyści ekonomiczne, jakie daje stosowanie praktyk Extreme Programming w procesie wywarzania oprogramowania. Analizę oparto na pracy „Ekonomiczna ocena metodyki „Extreme Programming”” Krzysztofa Górbiela [6], która pokazuje efektywność XP w porównaniu z modelem kaskadowym. Ocenie poddane zostały praktyki związane ze współpracą z klientem, takie jak: system dostarczany fragmentami, implementacja najważniejszych funkcjonalności czy odwlekanie decyzji o kontynuowaniu prac.

Dla uproszczenia obliczeń zostały przyjęte pewne założenia:

• Produkt dostarczony przy użyciu każdego z modelu jest taki sam.

• Suma oddawanych klientowi wersji w iteracjach jest równa wartości całego projektu.

• Iteracje mają stałą długość (okres czasu).

• Opłata za każdą oddaną klientowi wersję jest stała.

• Koszty pozyskania kapitału dla klienta jest stały dla obu metod i odpowiada ryzyku związanemu z projektem.

Założenia te odbiegają od rzeczywistości, jednak są konieczne do przeprowadzenia analizy ekonomicznej stosowania XP.

Analiza opłacalności podziału systemu na iteracje

Jednym z podstawowych założeń XP jest podział projektu na równe iteracje. W każdej z nich implementowane są scenariusze wybrane przez klienta. Takie rozwiązanie jest korzystne zarówno dla twórców oprogramowania, gdyż drastycznie zmniejsza się koszt ewentualnej rezygnacji klienta oraz dla zleceniodawcy, który może płacić za każdy kolejny zaimplementowany scenariusz.

Do oceny wartości projektu z perspektywy klienta posłużyła metoda wartości zaktualizowanej netto NPV. Pozwala ona porównać strumienie pieniężne występujące w różnych okresach czasu. Uwzględnia ona także wartość pieniądza w czasie.

Do uzyskania poniższego wykresu [Rysunek 1] został użyty iloraz wartości NPV dla XP i dla modelu klasycznego.

Rysunek 1. Przewaga metodyki Extreme Programming nad modelem klasycznym.

k - stopa dyskonta, czyli koszt alternatywny zainwestowania kapitału w ryzykowne projekty (zależy on od ryzyka związanego z projektem)

n - czas "życia" projektu, a więc liczba okresów między decyzją o inwestycji a ostatnim strumieniem pieniężnym.

Wykres [Rysunek 1] ten pokazuje, że przewaga XP nad modelem klasycznym staje się szczególnie widoczna przy projektach o dużym ryzyku. Wtedy to koszt pozyskania kapitału i oczekiwana stopa zwrotu są na tyle wysokie, że odwlekanie wypuszczania kolejnych wersji oprogramowania staje się nieopłacalne. Duża liczba wersji, a także szybkie wdrożenie do użytku pierwszej, daje możliwość natychmiastowych zysków i penetracji rynku.

Efekty szybkiej implementacji funkcji o największej wartości

Poszczególne fragmenty systemu stanowią dla klienta zróżnicowaną wartość. Oznaczać to może ujemne przepływy pieniężne w pierwszych fazach projektu. Najbardziej wartościowe z punktu widzenia klienta są główne funkcje systemu i interfejs użytkownika. To one dają najwyższy wzrost i według zaleceń metodyki Extreme Programming powinny być zaimplementowane w pierwszej kolejności. Oczywiście na początku każdego projektu muszą być wykonane pewne elementarne funkcje jak współpraca z systemem operacyjnym czy z bazami danych. Są to jednak pierwsze implementowane funkcjonalności niezależnie od stosowanej metodyki, dlatego ten etap został pominięty przy porównywaniu wpływu szybkiej implementacji najbardziej wartościowych funkcji na zaktualizowana wartość projektu netto. Dla wyizolowania wpływu kolejności implementowanych funkcjonalności założono, że strategia porównania charakteryzuje się również iteracyjnościa realizacji oprogramowania.

Przewaga metodyki XP została zmierzona przyrostem zaktualizowanej wartości netto (różnica wartości NPV dla XP i modelu klasycznego) [Rysunek 2]:

Rysunek 2. Przewaga metodyki Extreme Programming w porównaniu z modelem klasycznym ze względu na szybką implementację funkcji o największej wartości.

Im większa jest liczba iteracji projektu - n, tym większe są możliwe korzyści. Zależność ta jest niemal liniowa. Wartość współczynnika dyskontującego - k ma niejednoznaczny wpływ na postać wykresu. Biorąc jednak pod uwagę, że jego wartość w rzeczywistości na ogół nie przekracza 0,4 to zależność ta jest również dodatnia w rozsądnym przedziale. Zauważono, że im większą jest różnica w wartości poszczególnych funkcjonalności, tym większe są potencjalne zyski.

Wartość elastyczności procesu produkcji

W dwóch poprzednich wyliczeniach założono, że na rozkład korzyści z użytkowania tworzonego oprogramowania przez klienta nie mają wpływu czynniki losowe i zmiany w otoczeniu. Często jednak zdarza się, że dana funkcjonalność, poprzez zmiany warunków wewnętrznych traci jakąkolwiek wartość. Metodyka Extreme Programming pozwala dzięki udziałowi klienta w procesie tworzenia i wyboru funkcjonalności na kontrolę nad implementacją odpowiednich modułów. Unika się w ten sposób tworzenia zbędnych i kosztownych modułów.

Gdy korzystamy z Extreme Programming mamy możliwość dobrania funkcjonalności do danej wersji, gdy znamy już rzeczywiste warunki zewnętrzne. Mamy możliwość oceny czy dana wersja przyniesie nam wzrost i czy jest sens jej implementacji. Sytuację taką zbadać można posługując się metodą analizy typu „real options”:

Jeżeli założymy, że rozkład prawdopodobieństwa i wypłat we wszystkich okresach jest równy to przewagę metodyki XP możemy odwzorować za pomocą ilorazu wartości odpowiadających sobie projektów:

Rysunek 3. Przewaga XP nad modelem klasycznym ze względu na możliwość uniknięcia ryzyka.

Powyższy wykres [Rysunek 3] pokazuje zależność korzyści ze stosowania XP od prawdopodobieństwa zaistnienia korzystnych warunków oraz potencjalnej wysokości strat. Wynika z niego, że przewaga XP wzrasta, gdy ryzyko przedsięwzięcia jest duże (czyli jak spada prawdopodobieństwo korzystnych warunków) oraz gdy wzrastają ewentualne przyszłe straty (niekorzystne warunki obniżają w dużym stopniu wartość wersji).

Wnioski

Podsumowując powyższe analizy ekonomiczne, należy zauważyć, że Extreme Programming jest niezwykle efektywną i opłacalną metodyką. Połączenie wielu bardzo wydajnych praktyk, takich jak cykliczność iteracji czy implementacja najważniejszych dla klienta funkcji, daje bardzo dobre rezultaty ekonomiczne zarówno dla firmy programistycznej, jak i dla zleceniodawcy. Korzyści i przewaga XP nad modelem klasycznym wzrastają jeszcze bardziej, gdy mamy do czynienia ze wzrostem kosztu pozyskania kapitału, zmiennymi warunkami zewnętrznymi (czyli dużym ryzykiem) oraz zróżnicowaniem wartości tworzonych wersji. Wyników tych nie można przyjąć jako dokładne odzwierciedlenie rzeczywistości ze względu na uproszczenia i założenia konieczne do wykonania obliczeń. Przytoczone przykłady zastosowania XP w dużych i małych zespołach, świadczą jednak o dużej skuteczności tej metodyki. Oczywiście nie dla każdego zespołu korzyści będą takie same, może się także zdarzyć, że XP nie sprawdzi się w danym otoczeniu.

Rozdział 2.

Wartości, zasady i praktyki Extreme Programming

W poniższym rozdziale opisane zostały najważniejsze wartości, zasady i praktyki metodyki Extreme Programming. Na wstępie zostanie jednak wyjaśnione znaczenie tych określeń w realiach XP.

Wartości leżą u podstaw dokonywanych przez nas wyborów. Jest to pewien poziom doświadczenia i zrozumienia. Kryteria, które rządzą naszymi wyborami i postrzeganiem świata. Bez odpowiedniego systemu wartości praktyki stają się zwykłym rytuałem. To one nadają im znaczenie i sens, pozwalają wyciągać wnioski i analizować pracę zespołu.

Rysunek 4. Zasady jako pomost pomiędzy systemem wartości i praktykami.

Zasady to pomost pomiędzy systemem wartości i praktykami [Rysunek 4]. Jest to zestaw instrukcji i wskazówek jak powinniśmy korzystać z praktyk.

Praktyki to zestaw czynności, które są urzeczywistnieniem wyznawanych wartości i zasad. Wykonywane przez zespół programistyczny w trakcie codziennej pracy.

2.1. Wartości

2.1.1. Komunikacja

Extreme Programming kładzie bardzo duży nacisk na rolę komunikacji przy tworzeniu oprogramowania. Jeżeli podczas prac nad projektem pojawiają się problemy, należy upewnić się, że przez struktury naszej grupy deweloperów występuje odpowiedni przepływ informacji. Często zdarza się, że problem który występuje, da się rozwiązać dzięki wykorzystaniu wiedzy innych programistów pracujących w zespole, jednak brak komunikacji blokuje taką możliwość.

XP promuje wartość komunikacji i zaleca:

• Włączenie klienta bezpośrednio do produkcji oprogramowania. Najlepiej, jeżeli jeden z przedstawicieli zleceniodawcy zostaje przydzielony do zespołu, przez co ułatwia przepływ informacji.

• Komunikację werbalną nad pisaną dokumentacją. Nic nie jest w stanie zastąpić rozmowy dwóch pracowników. Jest to duża oszczędność czasu i ułatwia uniknięcie niezrozumienia zaleceń dokumentacji. Pozwala także pogłębić więzi i wzajemne zaufanie w zespole.

• W sytuacji, gdy każdy może zmienić kod aplikacji, potrzebna jest komunikacja aby uniknąć niepotrzebnych błędów.

• Programowanie w parach daję możliwość na bieżąco sprawdzania pisanego kodu, a także usprawnia poznawanie struktur aplikacji przez programistów.

• Otwarte przestrzenie w biurach ułatwiają wymianę poglądów i wiedzy.

Przy pomocy takich sposobów jak e-mail czy przekazanie dokumentacji dużo informacji zostaje zatraconych. Nieraz intonacja lub język ciała mają niebagatelny wpływ na zrozumienie przekazywanej informacji. Extreme Programming forsuje bezpośrednią rozmowę jako główną metodę komunikacji.

2.1.2. Prostota

Programiści w swojej naturze dążą do generalizowania i myślenia na przód, poza ramy rozpatrywanego problemu. Chcą tworzyć od razu rzeczy skomplikowane, takie które będą obsługiwać wiele obiektów i niepotrzebnych nieraz funkcji. Chcą upakować program swoimi pomysłami i rozwiązaniami, które może i są technologicznym osiągnięciem, ale nie mają znaczenia dla zleceniodawcy. Powodują tylko wzrost skomplikowania architektury systemu.

XP kieruje nas w zupełnie innym kierunku. Zaleca projektowanie i implementację najprostszego możliwego systemu, który rozwiązywałby dany problem. Klienta obchodzą tylko funkcjonalności, których sobie zażyczył, a nie spełnienie ambicji programisty. Należy więc dążyć do jak najprostszych rozwiązań, które przybliżają nas do założonego celu. Pieniądze, które zostaną zaoszczędzone dzięki utrzymywaniu prostych rozwiązań mogą pokryć ewentualne przeróbki i dodawanie nowych funkcjonalności w przyszłości. A to z kolei jest mniej kosztowne, gdy odpowiednio używamy programowania obiektowego i wzorców projektowych.

Komunikacja i prostota są od siebie zależne:

• Im lepsza komunikacja w zespole, tym bardziej jesteśmy pewni, że implementujemy tylko i wyłącznie konieczne funkcjonalności, które spełniają odpowiednie założenia klienta.

• Im prostsza jest architektura naszego projektu, tym łatwiej jest nam się komunikować.

W XP zaczynamy od złamania wszelkich zasad programowania. Duplikujemy kod, nie używamy wzorców projektowych itp. Nasz program w pierwszej kolejności ma przechodzić testy jednostkowe. Jeżeli ten warunek jest spełniony możemy przystąpić do refaktoryzacji i czyszczenia kodu, cały czas mając na uwadze zaliczenia testów. Ten sposób pozwala programistom stale posuwać się do przodu, jednocześnie utrzymując prostotę całego projektu.

2.1.3. Sprzężenie zwrotne

Sprzężenie zwrotne jest niezwykle istotne w procesie tworzenia oprogramowania. Częste zmiany w tworzonej aplikacji, nowe sposoby rozwiązań i wdrożenia pomysłów wymagają stałego utwierdzania zespołu w przekonaniu, że rozwija swoją pracę w odpowiednim kierunku. Zespoły korzystające z XP dążą do maksymalizacji sprzężenia zwrotnego, zwłaszcza ze strony klienta, ale nie tylko. Sprzężenie zwrotne to także testy jednostkowe, odpowiedzi na pytania dotyczące architektury systemu i wszystkie kwestie, które mogą spowolnić pracę i wprowadzić niepewność.

Maksymalizacja sprzężenia zwrotnego może powodować także problemy. Jeżeli dostajemy zbyt dużo informacji, możemy nie wyłowić z nich tych najistotniejszych dla zespołu. Należy wtedy zastopować wszelkie prace i poświecić czas na przeanalizowanie danych, co może być bardzo frustrujące.

Rysunek 5. Pętla sprzężenia zwrotnego.[14]

Extreme Programming daje nam możliwość otrzymania sprzężenia zwrotnego na różną skalę:

Skala	Sprzężenie zwrotne
Od minut do godzin	Programiści piszą testy jednostkowe, następnie piszą kod, który pozwoli na zaliczenie testu i potwierdzenie działania implementowanej funkcji. Kolejnym krokiem jest refaktoryzacja i usuwanie duplikowania kodu, przy ciągłym sprawdzaniu wcześniej napisanego testu.
Od godzin do dni	Codzienne spotkania całego zespołu utwierdzają jego członków o odpowiednim kierunku rozwoju oprogramowania i zapoznają ich z obecnymi problemami. Programiści estymują czas, jaki potrzebują na implementacji nowych funkcjonalności określonych przez klienta.
Od dni do tygodni	Klient określa i wykonuje testy akceptacyjne dla każdej iteracji lub wersji.

Tabela 1. Skala sprzężenia zwrotnego.

Sprzężenie zwrotne pozwala nam także dążyć do uproszczenia projektu. Zawsze przed przystąpieniem do implementacji jakiegoś większego elementu systemu możemy wykonać kilka prób i testów w celu określenia, który sposób rozwiązania będzie najlepszy i najprostszy. Potwierdzanie właściwego kierunku naszej pracy powoduje, że nasze działania są bardziej pewne. Zwiększa się także odwaga do wprowadzania zmian, o czym więcej napisano przy omawianiu następnej „wartości”.

2.1.4. Odwaga

Odwaga to zdolność programistów do działania w obliczu zagrożeń i niepewności, jakie spotykają nas w procesie tworzenia oprogramowania. Sposób radzenia sobie ze stresem i presją czasu może mieć ogromny wpływ na efektywność programisty. Odwaga przejawia się w podejmowaniu trudnych decyzji, ale także może być oczekiwaniem na otrzymanie większej ilości danych do podjęcia rozsądnej decyzji. Odwaga w rozumieniu XP nie może być bezsensownym parciem do przodu i podejmowaniem pochopnych decyzji.

Odważne mówienie prawdy o stanie prac czy też widocznych błędach ma duży wpływ na zaufanie i pracę całego zespołu. Tradycyjny strach wstrzymuje wprowadzanie zmian mogących mieć duży wpływ na efektywności czy funkcjonalność tworzonego systemu. Zaniechanie wprowadzenia takich modyfikacji i przesunięcie ich w czasie, może przysporzyć dodatkowych kosztów. XP za pomocą testów jednostkowych i refaktoryzacji kodu daje deweloperom odwagę do wprowadzania swoich pomysłów.

Klient nie mający obaw o postęp prac (dzięki testom akceptacyjnym i częstym wypuszczaniu działających wersji), chętnie zgłasza nowe pomysły, ponieważ wie, że zespół jest w stanie sprostać jego oczekiwaniom.

2.1.5. Szacunek

Każdy członek zespołu XP powinien być szanowany. Poszczególni członkowie zespołu powinni dbać o wzajemne problemy i rezultaty całego projektu. Wkład każdego pracownika powinien być doceniany. Nie powinniśmy faworyzować jednostek, gdyż może to zaburzyć harmonie w grupie i wprowadzić konflikty. Zespół XP powinien być postrzegany jako zgrana, wolna od konfliktów grupa ludzi, którzy koncentrują całą swoją wiedzę w celu osiągnięcia założonych rezultatów.

2.2 Zasady

2.2.1. Ekonomia

Każde oprogramowanie jest tworzone aby przynosić wymierne korzyści. Należy mieć to cały czas na uwadze. Jeżeli zespół nie będzie skupiał się tylko na najważniejszych, z komercyjnego punktu widzenia, funkcjonalnościach i celach klienta, to efektem tego będzie co najwyżej „sukces technologiczny”.

Jedna z zasad ekonomicznych mówi, że złotówka zarobiona dziś jest więcej warta niż ta sama złotówka zarobiona później. Odnosi się to także do oprogramowania. Stworzone szybciej będzie szybciej przynosiło zysk. XP dostosowuje się do tej zasady wprowadzając projektowanie przyrostowe i częste wypuszczanie wersji programu. Pozwala to rozłożyć koszty produkcji w czasie i uzyskać zysk od użytkowania wczesnych wersji oprogramowania.

Techniki stosowane w XP pozwalają także tworzyć elastyczne systemy, łatwe w modyfikacji i odporne na zmiany zewnętrzne. Wielokrotne użycie danego kodu prowadzi do zwiększenia zysków.

2.2.2. Wspólna korzyść

Każda czynność wykonywana przez zespół XP powinna przynosić korzyść wszystkim zainteresowanym. W niektórych sytuacjach może być to ciężkie do osiągnięcia, ponieważ często się zdarza się, że dane rozwiązanie przynosi korzyści jednym, a dla niektórych oznacza stratę. Przykładem tego może być drobiazgowe tworzenie dokumentacji kodu. Dla programistów, którzy będą go w przyszłości modyfikować takie rozwiązanie jest korzystne. Natomiast dla zespołu, który traci czas na dokumentacje, jest to rozwiązanie niekorzystne, ponieważ w większości przypadków taka dokumentacja nigdy nie znajdzie zastosowania. Praktyki takie naruszają zasadę wspólnej korzyści. XP rozwiązuje ten szczególny problem w następujący sposób:

• tworzenie zautomatyzowanych testów, które ułatwiają innym przyszłe modyfikacje

• stosowanie odpowiednich konwencji nazewniczych

• refaktoryzacja kodu, dzięki której nasz kod staje się prosty i zrozumiały

Praktyki powinny przynosić korzyści zarówno programistom, jak i użytkownikom. Gdy naruszamy zasadę wspólnej korzyści doprowadzamy do konfliktu interesów.

2.2.3. Doskonalenie

Oczywiście nie ma czegoś takiego jak idealne oprogramowanie czy też idealna metodyka. Ale XP pozwala nam się zbliżyć do tych ideałów. Powinniśmy pamiętać cały czas o ulepszaniu naszych procedur, zasad, a także technik programistycznych. Kwartalny cykl rozwojowy pozwala nam weryfikować długofalowe plany, a przyrostowe projektowanie daje możliwość ciągłych zmian, które mogą być efektem nowych doświadczeń. Doskonalenie oprogramowania powinno opierać się na eliminowaniu zbędnego wysiłku poprzez wykorzystanie najlepszych dostępnych technologii i powstawanie efektywniejszych struktur społecznych.

2.2.4. Jakość

Jakość to jedna z wytycznych tworzonego obecnie oprogramowania. Wyższa jakość oprogramowania zwiększa zyski i ułatwia proces jego wdrażania. Postawienie poprzeczki jakości wyżej nie musi zawsze prowadzić do spowolnienia produkcji. Na pewno prowadzi do mniejszej ilości błędów co ułatwia prace zespołu nad rozwojem takiego systemu i wpływa znacznie na poprawę stosunków z klientem. Zespoły, które stosują praktyki XP potrafią znacznie zwiększyć jakość swoich aplikacji, czego dowodem jest opisywane w tej pracy Sabre Airline Solutions, gdzie znacznie zmniejszono ilość błędów w tworzonym oprogramowaniu.

Jakość jest jednym z kryteriów oceny i kontroli projektów informatycznych. Niektóre specyficzne systemy muszą przejść bardzo rygorystyczne testy jakości, gdyż od ich działania może zależeć nawet życie ludzkie.

Utrzymywanie odpowiedniego poziomu kodu i projektu pozwala jego twórcom osiągnąć satysfakcje i uczucie dobrze wykonanej pracy. Ma to ogromny wpływ na zaangażowanie pracowników.

2.2.5. Zasada małych kroków

Przy wprowadzaniu znaczących zmian w kodzie programiści zazwyczaj starają się zrobić wszystko na raz, sądząc, że taki sposób jest najlepszy. Niestety później spędzają dużo czasu na debugowaniu lub przywracaniu aplikacji do poprzedniego stanu po nieudanej próbie implementacji. Extreme Programming zaleca wprowadzanie każdej zmiany małymi krokami. Należy podzielić zadanie na małe etapy, napisać odpowiadające im testy i dopiero wtedy zabrać się za kodowanie. Pozwala to na większą kontrolę nad wprowadzanymi zmianami i ułatwia ewentualne wycofanie się. Łatwiej jest rozwiązać kilka małych problemów, niż głowić się nad jednym dużym. XP wspomaga takie działanie testami jednostkowymi, ciągłymi integracjami systemu, a także częstym sprzężeniem zwrotnym.

2.3 Praktyki podstawowe

2.3.1. Wspólne środowisko pracy

Idealnym rozwiązaniem jest umieszczenie całego zespołu w jednym przestronnym biurze. Ma to duży wpływ na szybką wymianę informacje i łatwiejsze rozwiązywanie problemów. Jeżeli grupa ludzi jest dobrze dobrana i nie ma między nimi konfliktów to praca jest dużo bardziej efektywna, gdyż pracownicy na bieżąco mają możliwość wymiany doświadczeń i pomysłów. Oczywiście należy też zadbać o sferę prywatności każdego członka zespołu. Bardzo modne ostatnio są tzw. „boxy”, które oddzielają danego pracownika od reszty zespołu, jednocześnie pozwalając mu na swobodną komunikacje i wymianę poglądów.

Miejsce pracy powinno w jakiś sposób odzwierciedlać projekt, nad którym w danym momencie pracuje zespół. Dobrą praktyką stosowaną w wielu firmach jest wieszanie na widocznych tablicach opisów scenariuszy, podzielenie ich na wykonane i oczekujące. Można też umieścić na takiej tablicy wykres pokazujący postęp pracy. Praktyki takie działają mobilizująco na pracowników, którzy mają stały podgląd na rozwój projektu, nad którym pracują.

Im więcej czasu pracownicy spędzają razem tym bardziej efektywna staje się ich praca. Jeżeli zespół nie daje sobie rady z zadaniami to należy się zastanowić, czy komunikacja w zespole jest na odpowiednim poziomie. Nie jest to oczywiście reguła, gdyż są zespoły, które potrafią ze sobą współpracować na odległość korzystając z różnych technologii ułatwiających porozumiewanie się.

2.3.2. Proces planowania

Jednym z mitów na temat Extreme Programming jest to, że dezorganizuje kodowanie pomijając proces planowania. W rzeczywistości planowanie jest jednym z ważniejszych aspektów XP i występuje cały czas.

Proces planowania pozwala klientowi określić wartość biznesową swoich wymagań. Estymacje kosztów implementacji dostarczone przez programistów pomagają określić co jest opłacalne, a co należy pominąć.

Rysunek 6. Proces planowania iteracji w XP.[14]

Proces planowania w XP możemy rozdzielić na kilka kroków, które są powtarzane przy każdej wersji tworzonego oprogramowania:

• scenariusze użytkownika są zapisywane, sortowane względem priorytetu i estymowane.

Scenariusze użytkownika są to krótkie opisy funkcjonalności z punktu widzenia klienta i pisane jego językiem bez użycia terminologii technicznej. Mogą też być w postaci przypomnienia do późniejszej rozmowy pomiędzy programistą a klientem. Taka rozmowa ma miejsce podczas planowania iteracji. Wtedy deweloper uzyskuje szczegółową informacje na temat implementowanej funkcjonalności i może rozbić ją na mniejsze zadania.

Zaraz po etapie estymacji czasowych i finansowych danych scenariuszy, klient ma możliwość dokonania wyboru najważniejszych dla niego funkcji. Każda większa funkcjonalność systemu powinna mieć przynajmniej jeden scenariusz. Muszą być one pisane wyłącznie przez zleceniodawcę.

Podczas iteracji scenariusze zostają przekształcone w testy akceptacyjne, dzięki którym wiadomo czy zaimplementowana funkcjonalność działa poprawnie.

Scenariusze użytkownika spełniają podobną rolę do popularnych Use Case'ów.

• planowanie kolejnych wersji to wybieranie scenariuszy, które będą zaimplementowane i określenie terminów kolejnych wersji

Zespół XP powinien jak najczęściej wypuszczać działające wersje tworzonego oprogramowania. Po ukończeniu tworzenia scenariuszy użytkownika powinno się zorganizować spotkanie z klientem, na którym zostaną wybrane najważniejsze z punktu biznesowego funkcjonalności i ustalone terminy ich realizacji. Taki plan posłuży później do dokładniejszego zaplanowania kolejnych iteracji. Ważne jest, aby każda strona podejmowała decyzje z odpowiedniego dla siebie zakresu. Klient podejmuje decyzje biznesową, a deweloperzy odpowiadają za stronę techniczną.

Kiedy uda się stworzyć finalny plan kolejnych wersji należy się spodziewać negatywnej reakcji ze strony klienta. Każdy chce otrzymać produkt jak najszybciej, ale należy ufać dokonanym przez fachowców estymacjom i nie uginać się pod presją klienta. Jeżeli zdecydujemy się na niekorzystne zmiany terminów, możemy w późniejszym czasie tego żałować, ponieważ nie będziemy w stanie się z nich wywiązać.

• planowanie iteracji zaczyna się na początku każdej z nich

Proces rozwoju tworzonego oprogramowania powinien być podzielony na 1-3 tygodniowe iteracje. Na początku każdej iteracji powinno się odbyć zebranie całego zespołu programistycznego, na którym wszyscy zapoznają się ze scenariuszami przydzielonymi do danej iteracji. Duże scenariusze są rozbijane na mniejsze zadnia i przydzielane odpowiednim programistom. Ilość scenariuszy w bieżącej iteracji określa się z zależności od pracy wykonanej w poprzedniej. Sposób ten zwany jest Yesteray's Weather. Pozwala on uniknąć częstego problemu, jakim jest obsadzenie iteracji zbyt dużą ilością zadań. Każde zadanie w iteracji nie powinno zajmować więcej niż 1-3 dni czasu. Jeżeli okaże się, że zespół wykonał całą pracę zaplanowaną na dany okres powinien skonsultować się z klientem, co do dodatkowych scenariuszy.

• codzienne spotkania zapoznają zespół z bieżącymi zadaniami i problemami

Każdego dnia zespół XP spotyka się na bardzo krótkim, obowiązkowym spotkaniu dotyczącym bieżących spraw. Jest ono zwane „Standup Meeting”, ponieważ zaleca się aby w jego trakcie uczestniczy stali. Dzięki temu unika się długich i szczegółowych rozmów.

• szybkość pracy jest mierzona podczas iteracji

Jest to miara szybkości dostarczania przez zespół danej wartości biznesowej, czyli ilość jednostek (wartości, które zespół używa do estymacji), jaką dana praca zajmuje z perspektywy klienta. Żeby zmierzyć taką wartość należy zsumować jednostki przypisane do scenariuszy wykonanych w danej iteracji. Miary tej używa się do określenia zakresu prac następnej iteracji, a także sporządzenia różnego rodzaju zestawień pokazujących efektywność pracy zespołu. Pozwala to dokładniej estymować prace w przyszłości.

• podsumowania po zakończeniu każdej iteracji i wersji

Podsumowania organizuje się w celu ulepszenia pracy zespołu. Tradycyjnie takie spotkania organizowało się pod koniec całego projektu, ale wtedy już mogło być za późno. Extreme Programming zaleca takie spotkania po każdej zakończonej iteracji i wersji. W każdym przypadku celem takiego spotkania nie jest wyłącznie ustalenie, co było złe, ale także podkreślenie tego, co było sukcesem dla zespołu. Na takich sesjach nie należy obwiniać pracownika za ewentualne niepowodzenia, a wręcz przeciwnie założyć, że każdy z nich wkłada maksimum energii w wykonywane zadania.

2.3.3. Cykl tygodniowy/kwartalny

• Cykl tygodniowy

Używając metodyki XP pracę dzielimy na iteracje. Nie powinny być one dłuższe niż 3 tygodnie i krótsze niż jeden. Przede wszystkim czas iteracji powinien być stały. Powoduje to, że nasz projekt jest prowadzony stałym rytmem i jest przewidywalny dla klientów, kierownictwa i programistów, którzy mogą ustalić szybkość projektu.

Przed każdą iteracją organizujemy spotkanie, na którym klient wybiera scenariusze do zaimplementowania. Scenariusze dzielimy na mniejsze zadania, które są wybierane i estymowane przez pracowników. Można też przy większej współpracy z klientem tworzyć mniejsze, bardziej szczegółowe scenariusze, które nie wymagają już dalszego podziału. Przed przystąpieniem do kodowania tworzy się zautomatyzowane testy, na podstawie których później będziemy sprawdzać poprawność zaimplementowanych funkcjonalności. Resztę czasu poświęcamy na kodowanie i testy.

Zalecany tydzień jest najbardziej naturalną skalą czasową. Piątek wyznacza koniec tygodnia i jednoznacznie kojarzy z końcem iteracji. Pracownicy podświadomie dążą do zakończenia wszelkich zadań właśnie do końca tygodnia.

• Cykl kwartalny

Pracę należy planować również w cyklach kwartalnych. Po takim cyklu powinniśmy zrobić spotkanie podsumowujące naszą prace, jej rezultaty i stan zespołu. Podczas takich sesji powinniśmy zidentyfikować wąskie gardła, zwłaszcza, jeżeli nie zależą one od zespołu, zainicjować procedury naprawcze, sformułować tematy na najbliższy kwartał i wybrać odpowiednią ilość scenariuszy.

Cykle kwartalne umożliwiają okresową kontrole trudnych do zidentyfikowania ograniczeń. Pozwalają podsumować i ocenić długotrwałe eksperymenty organizacyjne.

Tak jak w przypadku iteracji tygodniowych, kwartał jest jednym z naturalnych okresów czasowych, wyznaczanym przez pory roku.

2.3.4. Testy

Testowanie to jedna z fundamentalnych praktyk Extreme Programming. Daje programiście i klientowi odwagę by posuwać się do przodu jak najszybciej to możliwe i dostarcza sprzężenia zwrotnego koniecznego do zwiększenia jakości pracy. Programiści tworzą oprogramowanie korzystając z programowania sterowanego testami (Test-Driven Development, TDD), cały czas walidując swój kod.

Rysunek 7. Schemat czynności wykonywanych przy testowaniu oprogramowania.[14]

„Test-Code-Simplify cycle” to schemat czynności, jakie powinniśmy wykonywać przy testowaniu oprogramowania:

1. napisać pojedynczy test

2. skompilować i sprawdzić, że test wyrzuca błąd, gdyż kod, który on wywołuje nie został jeszcze zaimplementowany

3. napisać najmniejszą część kodu potrzebną do kompilacji

4. zobaczyć, że test wyrzuca błąd

5. napisać najmniejszą część kodu potrzebna do zaliczenia testu

6. zobaczyć, że test zostaje zaliczony

7. przystąpić do oczyszczenia, czyli refaktoryzacji kodu

8. powtórzyć wszystkie czynności

Sama koncepcja TTD jest bardzo prosta, natomiast wymaga ona dużej dyscypliny i skupienia od programisty. Testy jednostkowe powinny być możliwie jak najmniejsze, tak, aby kod potrzebny do zaliczenia takiego testu też był odpowiednio mały. Końcowym rezultatem serii takich testów jest zestaw, który możemy sprawdzać automatycznie i w każdej chwili.

Należy podkreślić kilka bardzo ważnych rzeczy dotyczących testowania:

• testy muszą być zautomatyzowane i odpalane za pomocą jednego polecenia

• najpierw piszemy test, później projektujemy, a na końcu kodujemy

• jeżeli mamy problemy z napisanie testu, tzn., że architektura naszego systemu jest prawdopodobnie złe zaprojektowana

Mechanizm testów ciągłych zakłada uruchamianie zestawu testów po każdej zmianie w kodzie, dlatego należy zadbać, aby testowanie trwało bardzo szybko. Jeżeli taki warunek jest spełniony to mamy doskonałe narzędzie do wczesnego wykrywania błędów w logice programu. Testy nie sprawdzają samego kodu, bo od tego jest kompilator, ale rezultaty jego działania. Mimo czasu poświęconego na pisanie testów, zyskujemy bardzo dużo. Nasz program jest wolny od błędów, przez co jego jakość się podnosi, i oszczędzamy duże ilości zasobów przeznaczonych na naprawianie błędów w późniejszym okresie.

Rysunek 8. Rozkład godzin potrzebnych na usunięcie usterki z oprogramowania.[4]

Powyższy wykres [4][Rysunek 8] pokazuje jak szybko rośnie koszt wykrycia i naprawy błędów w kolejnych etapach tworzenia oprogramowania.

W Extreme Programming rozróżniamy następujące rodzaje testów:

• testy programisty/jednostkowe

Służą one do technicznej i logicznej weryfikacji na poziomie klas i metod. Programiści piszą testy dla poszczególnych metod, o możliwie najmniejszym zakresie. Dlatego testy te, również są nazywane testami jednostkowymi, gdyż odpowiadają za sprawdzenie bardzo małych funkcjonalności. Ta nazwa ma jednak powiązania z bardziej tradycyjnymi modelami produkcji oprogramowania, więc zaleca się stosowanie tej, która bardziej oddaje co i kto testuje.

Istnieje bardzo wiele narzędzi komercyjnych i open-source, które wspomagają testy programistów. Ich nazwa zazwyczaj ma postać xUnit, gdzie x jest nazwą języka programowania, np. JUnit dla Javy lub NUnit dla .NET.

• testy użytkownika/scenariuszy

Testowanie scenariuszy ma bardziej strategiczne znaczenie dla aplikacji. Weryfikują one czy scenariusze klienta zostały w poprawny sposób zaimplementowane. Testy użytkownika dostarczają także dodatkowych danych na temat zakładanego działania programu, ponieważ scenariusze są tylko krótkim opisem funkcjonalności. Przyszły użytkownik za ich pomocą może zdefiniować co system powinien robić i w jaki sposób.

Klient jest tym, który jest odpowiedzialny za tworzenie testów scenariuszy. Do pomocy ma specjalistę z zespołu programistycznego, który pomaga mu zautomatyzować i zrozumieć system ich tworzenia.

• testy integracyjne

Literatura XP nie mówi za dużo o tym rodzaju testów, ale są one często używane przez zespoły programistyczne. Mają one większy zasięg niż testy programistów, a także inny cel niż testy scenariuszy. Są one zazwyczaj używane do sprawdzenia czy poszczególne części większej aplikacji współgrają ze sobą odpowiednio. Są to rzeczy, które nie wymagają częstego sprawdzania, dlatego testy te są przeprowadzane rzadziej niż opisywane wcześniej.

2.3.5 Refaktoryzacja kodu

Korzystając z praktyk XP ciągle dążymy do upraszczania struktury kodu i usuwania z niego powtórzeń, nie wpływając jednocześnie na jego działanie. Używanie zautomatyzowanych testów po każdej poprawce pomaga nam w określeniu czy zmiana przez nas wprowadzona nie zmienia działania aplikacji. Wpływa to znacząco na naszą odwagę do dalszych prób „wygładzenia” kodu.

Refaktoryzacja to ciągłe, występujące co kilka minut, małe zmiany w kodzie. Nie można ich kojarzyć ze zmianą całej struktury czy dużych obszarów kodu. Wiele mniejszych zmian prowadzi do poprawy przejrzystości kodu i stwarza okazje do optymalizacji.

Niektóre ze sposobów refaktoryzacji to:

• wydzielanie klas/metod interfejsów

• przenoszenie metod

• zmiana nazw klas/metod/zmiennych

• usuwanie zbędnych zmiennych i duplikacji kodu

2.3.6. Programowanie w parach

Extreme Programming zakłada, że cały kod projektu jest pisany przez pary programistów pracujących przy jednym komputerze. Udowodniono, przez różne eksperymenty, że programowanie w parach daje oprogramowanie lepszej jakości przy takich samych lub niższych kosztach. Deweloperzy pracujący w tym systemie bardziej przykładają się do swojej pracy, chętniej piszą testy i przestrzegają standardów kodowania, wiedząc, że ktoś na bieżąco obserwuje ich prace.

Badania przeprowadzone przez Dr. Randalla W. Jensena w 1996 [8] w okresie jego pracy dla U.S. Air Force mówią o pracy w zespołach dwuosobowych. System taki stosowano tam już od 1975 roku, a badania pokazały 150% wzrost produktywności w okresie jednego miesiąca. Podobne badania przeprowadzone przez Dr, Laurie Williams na North Carolina State University wykazały 15% przewagę par programistów nad pracami samodzielnych koderów. Zauważono także dużo większą elegancję w kodzie i mniejszą ilość błędów. Nie jest to może spodziewane 50%, ale dowodzi przewagę i zasadność programowania w parach. [15]

Gdy programujemy w parach należy podzielić się na role. Jeden programista obiera funkcje taktyczną, a drugi strategiczną. Co jakiś czas należy zamienić się rolami, a także wybrać innego partnera, najlepiej codziennie siadać z inna osobą.

Programowanie w parach stanowi świetną okazję do poszerzenia wiedzy programistów o tworzonym systemie, a także znacznie poprawia jakość, gdyż kod jest zawsze sprawdzany przez dwie osoby. Ciągłe skupienie jest bardzo męczące, dlatego większość ludzi nie jest w stanie pracować w ten sposób więcej niż 5/6 godzin. Czas ten jednak jest w całości poświecony na efektywne kodowanie i testowanie.

2.3.7. Stały kontakt z klientem

O udziale klienta w projektach XP napisano dosyć dużo na wcześniejszych stronach pracy, dlatego w tej części znajdzie się podsumowanie i zebranie informacji o tej praktyce:

• w idealnej sytuacji klient ma swojego przedstawiciela, który jest cały czas do dyspozycji zespołu programistycznego, dzięki czemu nie marnuje się czasu na komunikację (natychmiastowe sprzężenie zwrotne)

• klient tworzy scenariusze i odpowiada na wszelkie wątpliwości dotyczące wyglądu i działania tworzonej aplikacji

• klient wybiera scenariusze dla danych iteracji oraz określa ich priorytety

• klient musi wiedzieć czego chce, musi mieć wizje projektu, gdyż to on podejmuje najważniejsze strategiczne decyzje

Rola klienta w procesie tworzenia oprogramowania jest jedną z najważniejszych a jednocześnie najtrudniejszych dla każdego typu projektu. Jest szczególnie ważna dla XP i dla wszystkich metodyk z rodziny Agile. Posiadanie w zespole osoby tylko i wyłącznie odpowiedzialnej za reprezentowanie wizji klienta ogromnie zwiększa szanse na końcowy sukces. Uczestnicząc bezpośrednio w pracach zleceniodawca może w dosłownie każdej chwili wprowadzić poprawki i dostarczyć programistom wszelkich informacji na temat pożądanych funkcjonalności.

2.3.8. Projektowanie przyrostowe

Praktyka projektowania przyrostowego nie oznacza, że należy unikać projektowania przed rozpoczęciem prac, bo oczywiście należy mieć jakąś wizje przyszłych funkcjonalności i struktur całego projektu. Praktyka ta mówi, że należy projektować w możliwie najdogodniejszym momencie. Każdego dnia należy poświęcać czas na ulepszanie projektu systemu, tak żeby odpowiadał realizowanym zadaniom.

Klasyczne metody zakładały tworzenie bardzo szczegółowych projektów systemów przed przystąpieniem do kodowania. W pewnym sensie blokowało to możliwość wprowadzania mniejszych lub większych zmian w trakcie procesu kodowania. XP preferuje budowanie projektu w oparciu o zdobyte w trakcie jego tworzenia doświadczenie. Zespół projektowy powinien dostosowywać system, a także jego dokumentacje, do wszelkich zmian na bieżąco, ponieważ zwlekanie ze zmianami może oznaczać większy koszt takiej modyfikacji w przyszłości. XP zwraca uwagę na otwartość i gotowość projektu na zmiany, ponieważ jest to gwarantem dostosowania tworzonego oprogramowania do aktualnych potrzeb i wymagań.

2.3.9. Ciągła integracja

Ciągła integracja to praktyka, która oznacza sprawdzanie i kompilacje kodu tworzonego oprogramowania tak często jak tylko jest to możliwe. Dzięki temu wszyscy programiści są na tym samym etapie, co daje możliwość większego i szybszego progresu. Im częściej zespoły dokonują integracji tym mniejsze problemy mają przy jej przeprowadzaniu. Związane jest to oczywiście z zasadą małych kroków, gdyż więcej zmian oznacza prawdopodobieństwo większej ilości błędów i niespójności. Integracje powinny obejmować cały tworzony system.

Koncepcja codziennych integracji istnieje już od 1993 roku, ale dopiero Extreme Programming zaczęło propagować iteracje po każdej zmianie dokonanej w repozytorium kodu. Taki model zwany jest integracjami asynchronicznymi. Zarejestrowane zmiany automatycznie są kompilowane i testowane, a programiści otrzymują powiadomienie o rezultatach np. na skrzynkę pocztową. Model synchroniczny zaleca wstrzymanie prac nad kodem aż do momentu zakończenia integracji, która czasem może być dłuższa od samego etapu wprowadzania zmian. Czas oczekiwania programiści mogą poświęcić na dyskusje na temat możliwych usprawnień lub na odpoczynek.[11]

2.3.10. Wspólny kod

Cały kod należy do wszystkich programistów, czyli każdy członek zespołu w każdej chwili może zabrać się za ulepszanie dowolnej części kodu. Ma to oczywiście swoje dobre i złe strony. Dobrą na pewno jest ogólna wiedza o systemie każdego z programistów. Jeżeli więc ktoś z zespołu odchodzi, nie odczuwamy tak dużej straty jak w przypadku, gdy ta osoba pracowałaby tylko i wyłącznie nad specyficzną częścią projektu. Należy jednak uważać, aby wprowadzanie zmian przez programistów nie było chaotyczne i pochopne, ponieważ może to wyrządzić więcej szkód niż pożytku. Tu z pomocą przychodzi opisywana wyżej ciągła integracja i programowanie w parach.

Decydując się na stosowanie tej praktyki należy przed wszystkim zadbać o stworzenie w zespole atmosfery wspólnej odpowiedzialności. Jeżeli to się uda, to możemy być pewni, że zaowocuje to ogólnie lepszym i bardziej dopracowanym kodem.

Rozdział 3.

Implementacja narzędzia fleXPlanner

Rysunek 8. Logo aplikacji fleXPlanner.

3.1. Założenia aplikacji fleXPlanner

Istnieje wiele aplikacji wspomagających zarządzanie projektem informatycznym w oparciu o praktyki Extreme Programming. XPlanner, najbardziej popularny, wspiera większość kluczowych praktyk tej metodyki, jednak dla mniejszych, kilkuosobowych zespołów, może być narzędziem zbyt złożonym. Pojawiała się zatem potrzeba stworzenia oprogramowania, które wspomagałoby jedynie wybrane, podstawowe elementy programowania ekstremalnego. Narzędzie fleXPlanner usprawni komunikację w zespole, pozwoli intuicyjnie dzielić projekt na iteracje, rozdzielać zadania dla pracowników oraz zgłaszać błędy w tworzonym oprogramowaniu.

Główne założenia aplikacji fleXPlanner to:

• usprawnienie pracy zespołu XP

• dostęp dla członków zespołu przez przeglądarkę WWW

• prosty i funkcjonalny interfejs użytkownika

• działanie niezależne od systemu operacyjnego

W programie zaplanowano implementację następujących funkcjonalności:

• systemu wiadomości, który pozwoli na wymianę informacji pomiędzy członkami zespołu, tworzenie konwersacji oraz dodawanie komentarzy do zgłaszanych zadań i błędów

• dzielenia projektu na iteracje

• przydzielania członkom zespołu zadań do realizacji

• zgłaszania błędów w tworzonym projekcie

• wizualizacji statystyk iteracji i użytkownika za pomocą animowanych wykresów

• edycji profilu użytkownika

3.2. Zastosowane technologie

Po stronie serwera zastosowana została darmowa baza danych MySQL oraz skrypty w języku PHP. Do prezentacji danych i interakcji z użytkownikiem wykorzystano technologię FLEX oraz framework AMFPHP, który odpowiada za serializację danych przesyłanych z serwera.

Rysunek 9. Schemat klient-serwer aplikacji fleXPlanner.

Poniżej dokładniej opisano główne technologie i języki programowania, których użyto przy tworzeniu aplikacji fleXPlanner.

Adobe Flex 2

Adobe Flex 2 to niezależny od platformy framework do tworzenia aplikacji internetowych. Flex pozwala na budowanie aplikacji bogatych w multimedia i interakcję z użytkownikiem, powodując, że oprogramowanie jest bardziej atrakcyjne dla odbiorcy. Jedynym wymaganiem do uruchomienia programów tworzonych w tej technologii jest przeglądarka i aktualna wersja Adobe Flash Player.

Firma Adobe oferuje darmowe SDK, które zawiera biblioteki klas i kompilator do MXML i języka ActionScript 3.0.

• MXML

MXML to znacznikowy język do tworzenia interfejsu użytkownika bazujący na XML. Służy do rozmieszczania elementów i implementowania interakcji z nimi związanych. Języki znacznikowe, takie jak html czy xml, idealnie nadają się do tego typu zadań i są ogromnie popularne. MXML jest używany, podobnie jak w przypadku HTML, do deklarowania elementów widocznych dla użytkownika. Jako język oparty na XML, ma bardziej strukturalną postać i mniej dwuznaczną składnie. Posiada także dużo większą bibliotekę znaczników, takich jak np.: DataGrid, Tree, TabNavigator, Accordion czy Menu. Wszystkie one są w standardowym zbiorze tag'ów. Można rozszerzyć zbiór znaczników MXML o własne, tworząc komponenty.

Znaczniki MXML są renderowane przez Flash Player, dzięki czemu mogą być animowane, a przez to bardziej atrakcyjne niż zwykle HTML'owe strony WWW.

• Action Script 3.0

ActionScript 3.0 to obiektowy język programowania, który w znaczny sposób rozszerza możliwości Flash Player'a. Wcześniejsze wersje ActionScript'a dawały możliwości budowy efektownych, bogatych w animacje i dynamicznych stron. Wersja 3.0 oferuje około 10-krotne zwiększenie wydajności i łatwość budowania skomplikowanych aplikacji, obsługi dużych zbiorów danych i tworzenie zorientowanej obiektowo bazy kodu.

ActionScript 3.0 jest oparty na standaryzowanym języku ECMAScript, a dokładniej trzeciej jego edycji - ECMA-262. Wykonywany jest przez ActionScript Virtual Machine (AVM) wbudowaną w Flash Player. Wraz z pojawieniem się trzeciej odsłony języka wprowadzono drugą wersję wirtualnej maszyny - AVM2, która jest dużo bardziej wydajna i zoptymalizowana. AVM2 jest częścią nowego Flash Player w wersji 9, który jest także wstecznie kompatybilny, gdyż wspiera AVM1.

Rich Internet Application (RIA)

Obecnie występuje trend tworzenia aplikacji, które są uruchamiane w oknie przeglądarki. Dąży się także do tego, aby interfejs użytkownika działał i wyglądał tak samo w różnych środowiskach. Do tego aplikacje internetowe dają użytkownikowi coraz większe możliwości i zbliżają się do funkcjonalności oferowanych przez programy desktopowe.

Pojawiło się w ostatnim czasie dużo technologii i języków, które mają pomóc w budowaniu bogatych aplikacji internetowych. Są to m.in. AJAX, OpenLaszlo czy wybrany do realizacji fleXPlanner'a, Adobe Flex.

Aplikacje stworzone w oparciu o założenia modelu RIA różnią się od dotychczas spotykanych rozwiązań internetowych. Główne cechy charakterystyczne to:

• jednoekranowa prezentacja danych (wszystkie elementy aplikacji są widoczne, zmieniają się tylko wyświetlane informacje)

• brak odświeżania zawartości strony (wyniki działania użytkownika widoczne są natychmiast bez charakterystycznego dla technologii HTML przeładowywania strony).

• użytkownik ma możliwość wprowadzania danych w dowolnie wybranej i wygodnej dla siebie kolejności.

• pobieranie większości potrzebnych danych z serwera na początku sesji użytkownika, a następnie przetwarzanie i wyświetlanie danych wykorzystując zasoby i moc obliczeniową urządzenia-klienta.

• często występuje animowany interfejs zawierający elementy multimedialne (obraz video, dźwięk itp.).

AMFPHP/PHP

AMFPHP to framework oparty o RPC (Remote Procedure Call) dla języka PHP. Umożliwia bezpośrednie połączenie skryptów PHP i:

• Flash i Flex z wykorzystaniem Remoting

• JavaScript i Ajax z wykorzystaniem JSON

• klientów XML z wykorzystaniem XML-RPC

RPC (Remote Procedure Call) to sposób komunikacji i przesyłania danych pomiędzy klientem i serwerem. Służy do wykonywania metod zdalnych obiektów, za pomocą lokalnych funkcji, dzięki czemu wymiana danych nie musi się odbywać za pośrednictwem plików XML.

MySQL

Do przechowywania danych o projektach i użytkownikach użyto bazy MySQL. Jest to obok PostgreSQL najbardziej popularny darmowy system zarządzania relacyjnymi bazami danych. System ten ma opinie jednego z szybszych serwerów bazodanowych, dlatego idealnie nadaje się do współpracy z RIA.

MySQL jest rozwijany jako open-source przez szwedzką firmę MySQL AB.

3.3. Zaimplementowane funkcjonalności

W tym rozdziale dokładnie opisano interfejs użytkownika oraz funkcjonalności, jakie zostały zaimplementowane w aplikacji fleXPlanner.

Stałe elementy interfejsu użytkownika

Po uzyskaniu dostępu poprzez panel logowania do aplikacji fleXPlanner użytkownikowi pokazuje się strona startowa aplikacji. Występują na niej stałe dla całego programu elementy:

• informacje o zalogowanym użytkowniku:

• imię i nazwisko

• rola jaką pełni on w zespole

• główne menu aplikacji, które umożliwia wybór stron:

• „START”

• „ZADANIA/BŁĘDY”

• „ITERACJE”

• „PRACOWNICY”

• „MÓJ PROFIL”

• podręczne menu do najważniejszych operacji:

• „START”

• „WYŚLIJ WIADOMOŚĆ”

• „DODAJ ZADANIE”

• „DODAJ BŁĄD”

• „DODAJ ITERACJĘ”

• „DODAJ PRACOWNIKA”

• „MÓJ PROFIL”

• „WYLOGUJ”

Strona startowa

Na stronie startowej możemy uzyskać najistotniejsze dla projektu i pracownika informacje, takie jak:

• dane realizowanej iteracji:

• nazwa

• data rozpoczęcia

• data zakończenia

• ewentualne opóźnienie

• wykresy pokazujące:

• statystykę zadań przydzielonych do użytkownika

• statystykę błędów przydzielonych do użytkownika

• spis wiadomości wysłanych do użytkownika

System wiadomości

Rysunek 10. Strona startowa aplikacji fleXPlanner.

Biorąc pod uwagę rolę, jaką odgrywa komunikacja w Extreme Programming, zaimplementowano system ułatwiający wymianę informacji pomiędzy pracownikami.

Członkowie zespołu mają możliwość:

• wysyłania wiadomości do wybranego członka zespołu lub do wszystkich jednocześnie

• przeglądania treści wiadomości (przez dwukrotne kliknięcie na wybraną z tabeli wiadomość)

• przeglądania odebranych wiadomości na stronie startowej korzystając z przejrzystej listy, która pokazuje:

• nadawcę wiadomości

• tytuł wiadomości

• datę wysłania wiadomości (jeżeli wiadomość została wysłana w dniu obecnym to wyświetlana jest tylko godzina);

• ikony, które oznaczają kolejno:

• nowa wiadomość

• konwersacja

• wiadomość wysłaną do wszystkich

• usunięcie wiadomości

• odświeżania i wyszukiwania wiadomości po słowie kluczowym

• sortowania kolumn tabeli z wiadomościami

• tworzenia i przeglądania konwersacji (jeżeli odpowiedziano na wiadomość to tworzy się konwersacja, która jest formą dokumentacji rozmowy na dany temat)

• wyświetlania szczegółów danego zagadnienia, jeżeli wiadomość jest komentarzem do zadania/błędu

System obsługi zadań i błędów

Rysunek 11. Strona „ZADANIA/BŁĘDY” aplikacji fleXPlanner.

Jedną z głównych funkcjonalności narzędzia fleXPlanner jest system zadań i błędów zgłaszanych przez członków zespołu. Aplikacja wspomaga projekty XP, dlatego też zgłaszane zadania/błędy przypisywane są do poszczególnych, wcześniej utworzonych iteracji.

Zaimplementowany system obsługi zadań i błędów pozwala użytkownikowi na:

• zgłoszenie zadania przez sprecyzowanie:

• wykonawcy zadania:

• jednego pracownika

• dwóch pracowników

• wszystkich członków zespołu (poprzez zmianę statusu zadania wysłanego do wszystkich na „realizowane” pracownik przypisuje zadanie sobie)

• priorytetu:

• niski

• normalny

• wysoki

• iteracji, poprzez wybór aktualnie realizowanej lub jednej z zamkniętych

• opisu zadania, czyli wyjaśnienia na czym polega dane zadanie

• zgłaszania postępu (jeżeli opcja jest zaznaczona to wykonujący zadanie może ustawić podczas wykonywania dłuższego zadania jego postęp)

• zgłoszenie błędu, które odbywa się analogicznie do dodawania nowych zadań, z tym, że nie ma możliwości przypisania błędu do pary programistów

• zmianę statusu zadnia/błędu na:

• zamknięte

• realizowane

• zakończone (również poprzez ustawienie postępu prac na 100%)

• dodanie komentarza do zagadnienia, który zostaje wysłany w formie wiadomości do zainteresowanych stron (nadawcy i wykonawcy), a także dodany do opisu zagadnienia

• przeglądanie szczegółów zadania/błędu (przez dwukrotne kliknięcie na wybrane z listy zagadnienie)

• przeglądanie przypisanych do użytkownika zagadnień korzystając z przejrzystej listy, która pokazuje:

• tytuł zadania

• priorytet, czy zadanie zostało wysłane do wszystkich, nadawcę, pasek postępu oraz ikonę przedstawiającą status

• odświeżanie i wyszukiwanie zadania/błędu po słowie kluczowym

• sortowanie kolumn tabeli z zadaniami/błędami

• filtrowanie zadań/błędów (korzystając z chowanego panelu „FILTRY”) według:

• iteracji

• statusu

• nadawcy

Podział projektu na iteracje

Rysunek 12. Strona „ITERACJE” aplikacji fleXPlanner.

FleXPlanner, tak jak metodyka XP, dzieli projekt na iteracje. Użytkownicy mają możliwość:

• dodawania nowej iteracji poprzez sprecyzowanie:

• tytułu iteracji

• daty rozpoczęcia

• daty zakończenia

• opisu, czyli wyjaśnienia jakie funkcjonalności będą implementowane w danej

iteracji

• zmiany statusu iteracji na:

• zamknięta

• realizowana

• zakończona

• przeglądania iteracji korzystając z przejrzystej listy, która pokazuje:

• tytuł iteracji

• ramy czasowe

• ikonę przedstawiającą status

• przeglądania szczegółów iteracji (przez dwukrotne kliknięcie na wybrane z listy zagadnienie) w zakładkach:

• „Informacje”, gdzie wyświetlane są podstawowe informacje o iteracji

• „Zadania”, gdzie wylistowane są zadania przypisane do zaznaczonej iteracji

• „Błędy”, gdzie wylistowane są błędy przypisane do zaznaczonej iteracji

• „Statystki”, gdzie mamy wykresy postępu wykonania zadań i błędów analogiczne do tych na stronie startowej

• odświeżania i wyszukiwanie iteracji po słowie kluczowym

• sortowania poszczególnych kolumn tabeli z iteracjami

Lista pracowników

Rysunek 13. Strona „PRACOWNICY” aplikacji fleXPlanner.

Na stronie „PRACOWNICY” użytkownik ma możliwość:

• przeglądania listy pracowników, która pokazuje:

• zdjęcie pracownika

• imię i nazwisko

• stanowisko

• adres e-mail

• numer telefonu

Podsumowanie

Głównym celem pracy było stworzenie narzędzia wspomagającego zarządzanie projektem informatycznym w oparciu o metodykę Extreme Programming. FleXPlanner został stworzony dla XP, dlatego też dużo uwagi poświęcono komunikacji pomiędzy użytkownikami aplikacji i podziałowi projektu na iteracje. Powstałe systemy wiadomości, obsługi zadań i błędów są na tyle elastyczne, że mogą także być stosowane do wspomagania projektów opartych na innych metodykach.

Wszystkie planowane wcześniej funkcjonalności zostały zaimplementowane, co opisano dokładnie w rozdziale trzecim. Uzasadniono w nim także wybór odpowiednich technologii i języków programowania, które zostały użyte w trakcie tworzenia narzędzia fleXPlanner.

Proces powstawania aplikacji przebiegał w następujących etapach:

• wstępne planowanie i wybór technologii

• implementacja funkcjonalności i testowanie programu na lokalnym serwerze

• wdrożenie aplikacji na zdalnym serwerze [ http://flexplanner.pl ]

• testy użytkowników

Aplikacja została pomyślnie wdrożona i przetestowana przez kilkuosobową grupę użytkowników.

Kolejnym celem pracy było zapoznanie się z teoretycznymi założeniami metodyki Extreme Programming, które odbywało się w dwóch etapach. Pierwszym było gromadzenie wiedzy i materiałów poprzez uczęszczanie na konferencje poświęcone inżynierii oprogramowania, lekturę książek i artykułów oraz analizę zakończonych sukcesem zastosowań XP. Kolejny etap polegał na rozkładzie na czynniki pierwsze praktyk programowania ekstremalnego, spisaniu ich i wyjaśnieniu w przystępnej formie. Efekty realizacji tych etapów zostały zawarte w dwóch pierwszych rozdziałach.

Niniejsza praca może posłużyć jako przewodnik po podstawowych praktykach XP, natomiast aplikacja fleXPlanner może być użyta jako podstawa do stworzenia bardziej rozbudowanego narzędzia wspomagającego także pozostałe elementy metodyki Extreme Programming.

Bibliografia

[1] Addison-Wesley, "Interview with Ron Jeffries, Ann Anderson, and Chet Hendrickson", 16 marzec 2001 (http://www.awprofessional.com/articles/article.asp?p=20930&rl=1)

[2] Beck K., Andres C., „Wydajne programowanie - extreme programming” wydanie II, Mikom, , Warszawa, styczeń 2006

[3] Beck, K., “Embracing Change with Extreme Programming”, październik 1999, (http://www.cs.wm.edu/~coppit/csci435-spring2005/references/rx070.pdf)

[4] Dziwisz J., „Test-Driven Development & Pair Programming - Demistyfication”, konferencja JustJava, Politechnika Krakowska, 28 marzec 2007 (http://dziwisz.org/jakub/download/)

[5] Erdogmus H., La Barre M., „Value of Commercial Software Development under Technology Risk”, The Financier Vol. 7, czerwiec 2001 (http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-44890_e.html)

[6] Górbiel K., “Ekonomiczna ocena metodyki "Extreme Programming"”, Szkoła Główna Handlowa, (http://www.e-informatyka.pl/article/show-bw/1121)

[7] Jeffries R., http://www.xprogramming.com

[8] Dr. W. Jensen R., „Management Impact on Software Cost and Schedule”, Brigham [9] City, lipec 1996 (http://www.stsc.hill.af.mil/crosstalk/1996/07/manageme.asp)

[10] Klipp P., „Pierwsze doświadczenia w stosowaniu "Agile"” (http://www.llp.pl/sitepl/index.php?page=Article2)

[11] Mayford Technologies Inc., http://www.mayford.ca/xp/

[12] Plamondon S., „Working smarter, not harder: An interview with Kent Beck”, DeveloperWorks, 17 czerwiec 2003

[13] Szejko S., "Metody Wytwarzania oprogramowania", Mikom, Warszawa, listopad 2002

[14] Wells D., http://www.extremeprogramming.org/

[15] Dr. Williams L., „Pair Programming”, 14 grudzień 2006 (http://collaboration.csc.ncsu.edu/laurie/pair.html)

Spis rysunków i tabel

Rysunek 1. Przewaga metodyki Extreme Programming nad modelem klasycznym.

Rysunek 2. Przewaga metodyki Extreme Programming w porównaniu z modelem klasycznym ze względu na szybką implementację funkcji o największej wartości

Rysunek 3. Przewaga XP nad modelem klasycznym ze względu na możliwość uniknięcia ryzyka.

Rysunek 4. Zasady jako pomost pomiędzy systemem wartości i praktykami.

Rysunek 5. Pętla sprzężenia zwrotnego.

Rysunek 6. Proces planowania iteracji w XP.

Rysunek 7. Schemat czynności wykonywanych przy testowaniu oprogramowania.

Rysunek 8. Logo aplikacji fleXPlanner.

Rysunek 9. Schemat klient-serwer aplikacji fleXPlanner.

Rysunek 10. Strona startowa aplikacji fleXPlanner.

Rysunek 11. Strona „ZADANIA/BŁĘDY” aplikacji fleXPlanner.

Rysunek 12. Strona „ITERACJE” aplikacji fleXPlanner.

Tabela 1. Skala sprzężenia zwrotnego.

[Author ID0: at Thu Nov 30 00:00:00 1899 ]

Rich Internet Application - określenie stworzone na początku 2001 roku przez pracowników firmy Macromedia, po zaobserwowaniu licznych stron internetowych utworzonych w technologii Flash oferujących pracę w dynamicznie generowanym, jednoekranowym interfejsie (one-screen-application), eliminujących uciążliwości standardowych rozwiązań technologii HTML (np. wprowadzanie danych w kolejnych formularzach wymagające wielokrotnego przeładowywania stron).

[ http://pl.wikipedia.org/wiki/Rich_Internet_Application ]

Kent Beck to twórca programowania ekstremalnego i jeden z twórców Manifestu Agile (Agile Manifesto). Beck publikował na temat wzorców projektowych oraz języka Smalltalk. Popularyzował metodę kart CRC wraz z Wardem Cunninghamem oraz stworzył bibliotekę JUnit razem z Erichem Gamma. [ http://pl.wikipedia.org/wiki/Kent_Beck ]

Chrysler Comprehensive Compensation System (C3) - projekt korporacji Chrysler miał na celu zastąpienie kilku mniejszych systemów wypłat jednym obsługującym cała korporację. Nowy system był tworzony przy użyciu języka Smalltalk i baz danych GemStone. Projekt rozpoczęto w 1995. Zamknięto go w 1 lutego 2000 roku, z uwagi na zmiany technologiczne, a także wykupienie Chryslera przez Daimler-Benz i przekształcenie w DaimlerChrysler.

[ http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System ]

Smalltalk jest czysto obiektowym, reflektywnym językiem programowania z dynamiczną typizacją. Umożliwia to w praktyce zupełnie inny sposób programowania od tego, do jakiego są przyzwyczajeni programiści używający języków obiektowych rozwiniętych z języków proceduralnych takich jak C, czy Pascal. [http://en.wikipedia.org/wiki/Smalltalk]

Ron Jeffries jest jednym z twórców metodyki XP. Autor książki „Extreme Programming Installed” - drugiej opublikowanej książce o tematyce XP. Prowadzi także stronę internetowej o tej metodyce: http://www.xprogramming.com. Jest także jednym z 17 autorów manifestu Agile. [7]

„Working smarter, not harder” -- „So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we'll divide the project into three-week intervals called, say, iterations. In each iteration we'll implement a few new features called stories. We'll write down all the stories we need, slot them into the iterations, then do it.” [11]

Acxiom - firma oferującą kompleksowe rozwiązania z obszaru zarządzania informacjami. Pomaga klientom osiągać założone cele biznesowe i marketingowe poprzez odpowiednie wykorzystanie informacji rynkowych. Światowy lider w kreowaniu i zarządzaniu informacjami oraz ich przetwarzaniu.

[ http://www.axciom.pl ]

Forte Software, Inc. - firma tworząca oprogramowanie do wspomagania budowania aplikacji biznesowych. Forte został zaprojektowany, aby umożliwić organizacjom tworzenie oprogramowania o dużych możliwościach, które może stabilnie obsłużyć tysiące użytkowników. Architektura client-server Frote podnosi wydajność w produkcji oprogramowania.

[http://www.business.com/directory/computers_and_software/computer_services/forte_software,_inc/profile/]

Framework - (rama projektowa, szkielet) to w programowaniu struktura wspomagająca tworzenie, rozwój i testowanie powstającej aplikacji. Z reguły na framework składają się programy wspomagające, biblioteki kodu źródłowego i inne podobne narzędzia. [ http://pl.wikipedia.org/wiki/Framework ]

GemStone - firmy Gemstone Systems Inc. jest smalltalkową obiektową bazą danych idealną jako serwer obiektowy dla środowisk takich jak VisualWorks czy VisualAge.

[ http://www.gemstone.com/products/smalltalk/ ]

Sabre Holdings - światowy lider w produkcji oprogramowania i rozwiązań dla branży podróżniczej.

[ http://www.sabre-holdings.com/aboutUs/index.html ]

Brad Jansen - tekst został opracowany na podstawie wywiadu z Bradem Jensenem, wicedyrektorem działu rozwoju produktów lotniczych. [2]

Bangalore SPIN - Software Process Improvement Network (SPIN), Bangalore, India. Korporacja pomaga indyjskim producentom oprogramowania w osiągnięciu odpowiedniej jakości i produktywności. [ http://www.bspin.org ]

Lunar Logic Polska - firmą tworzącą oprogramowanie, z siedzibą w Krakowie. [10]

Screenshot - zrzut widocznych elementów ekranu monitora do pliku graficznego.

Polega ona na wycenieniu prawa do zakupu ryzykownego aktywu (w tym przypadku jest to kolejna wersja) w przyszłości. Cena jaką płacimy za możliwość zrealizowania tej opcji to koszt budowy wersji. Rozumowanie to wywodzi się z modelu wyceny opcji finansowych, natomiast analityczne rozwiązanie tego zagadnienia dostarczyli trzej laureaci nagrody Nobla: Black, Scholes i Merton.

Yesterday's Weather - zasada, która mówi, że jeżeli przewidzimy pogodę na jutrzejszy dzień w oparciu o dzisiejszą, to w 70% trafnie uda nam się ją przewidzieć. Koncepcja ta jest używana do określenia ilości pracy do wykonania w najbliższej iteracji, która może zawierać, co najwyżej tyle zadań co poprzednia.[2]

1-3 dni - są to tzw. Idealne dni programowania, czyli takie, w których cały dosłownie czas poświęcamy na wykonanie danego zadnia. W ten czas wlicza się także Refaktoryzacja i pisanie testów.[2]

Wąskie gardło (bottleneck) - „Teoria wąskich gardeł mówi, że w każdym systemie w danej chwili istnieje tylko jedno wąskie gardło (bardzo rzadko mogą występować dwa równorzędne wąskie gardła). Aby zwiększyć efektywność systemu, należy najpierw odnaleźć aktualne wąskie gardło, przeanalizować efektywność generującego je mechanizmu, a następnie spróbować go odciążyć, przesunąć część realizowanych przezeń zadań do innych, równoległych mechanizmów” [2]

Open-source - termin ten jest używany w odniesieniu do kodu źródłowego oprogramowania, który jest udostępniony do wglądu publicznego, niekiedy z ograniczoną, ale przed wszystkim z możliwością jego darmowego użycia i modyfikacji. (http://en.wikipedia.org/wiki/Open_source)

Pełną listę framework'ów do testowania można znaleźć na http://www.xprogramming.com/software.htm .

„Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” - Martin Fowler

Codzienne integracje - koncepcja wymyślona i opisana przez Steva McConnela w książce pt.: „Code Complete”.

AMF - Action Message Format to protokół oparty o Simple Object Access Protocol (SOAP). Jest wykorzystywany przez Flash Remoting (wywoływanie zdalnych funkcji, Remote Services) do serializacji danych przesyłanych z i od aplikacji opartych o Flash. [http://www.amfphp.org/]

Adobe Flash Player - aktualna wersja pluginu do przeglądarek do pobrania ze stron Adobe: http://www.adobe.com/products/flashplayer/

SDK (Software Development Kit) - zestaw narzędzi dla programistów niezbędny w tworzeniu aplikacji korzystających z danej biblioteki (np. DirectX SDK), pod dany system (np. Microsoft Platform SDK), sprzęt, itp. [http://pl.wikipedia.org/wiki/SDK]

MXML - Adobe nie podaje oficjalnego znaczenia tego skrótu, jednak niektórzy deweloperzy sugerują, że jest to Multimedia eXtensible Markup Language. [http://en.wikipedia.org/wiki/MXML]

HTML - HyperText Markup Language (hipertekstowy język znaczników), to język składający się ze znaczników stosowany do pisania stron WWW. [http://pl.wikipedia.org/wiki/Html]

TAGI - (ang. tags) znaczniki

ActionScript - ActionScript z obecnie stosowaną składnią pojawił się po raz pierwszy we Flash 5, który w pełni udostępniał programowanie we Flashu. Ta wersja ActionScriptu została nazwana ActionScript 1.0. Flash 6 (MX) dalej rozszerzył użyteczność środowiska programistycznego przez dodanie wielu wbudowanych funkcji i umożliwienie lepszej programistycznej kontroli nad filmami we Flashu. Flash 7 (MX 2004) wprowadził wersję ActionScript 2.0, która dodała strong typing i cechy obiektowe takie jak explicit class declarations, dziedziczność, interfaces i Strict Data Typing. [http://pl.wikipedia.org/wiki/ActionScript]

ECMAScript - standaryzowane przez ECMA kluczowe elementy obiektowego skryptowego języka programowania JavaScript. Specyfikacja ta oznaczona jest jako ECMA-262. [http://pl.wikipedia.org/wiki/ECMAScript]

AJAX - (ang. Asynchronous JavaScript and XML, Asynchroniczny JavaScript i XML) - architektura projektowania aplikacji internetowych, w której interakcja użytkownika z serwerem odbywa się bez przeładowywania całego dokumentu. Pobrany już kod w języku (X)HTML jest modyfikowany za pomocą treści pobieranych z serwera przez obecny w językach skryptowych programistyczny interfejs XMLHttpRequest. [http://pl.wikipedia.org/wiki/AJAX]

OpenLaszlo - jest to platforma open source, która służy do projektowania, tworzenia i udostępniania aplikacji sieci web z bogatym interfejsem użytkownika. Aplikacje generowane są w postaci plików Flash, ale istnieje również możliwość kompilowania projektów do plików DHTML. [http://www.openlaszlo.org/]

5

[Author ID0: at Thu Nov 30 00:00:00 1899 ]

---