docExtreme Programming
download 
Reklamacja Transkrypt
Extreme Programming
EXTREME PROGRAMMING – ZAPEWNIENIE SKUTECZNEJ I WYDAJNEJ PRACY PROGRAMISTÓW KRZYSZTOF KACZMARSKI Streszczenie. Extreme Programming stara się w szczególny sposób zwrócić uwagę na wydajność i skuteczność pracy programistów. W tym celu stosuje pewne znane od dawne praktyki oraz zupełnie nową filozofię pracy zespołu programistycznego. Pomimo nieugiętych reguł, których trzeba przestrzegać, nie nakłada na programistów dodatkowej pracy nie związanej bezpośrednio z tworzeniem i pielęgnowaniem kodu programu. Metodyka ta, zastosowana w małych i średnich zespołach, może przynieść ogromne korzyści. 1. Wstęp Jak osiągnąć sukces. Martin Fowler w pracy [5] analizuje skąd się bierze ryzyko w projektach i jak go uniknąć. Stawia tezę, że kodowanie jest tak samo procesem twórczym jak sam proces projektowania. Znaczy to, że rozdzielenie projektowania i kodowania jest błędne. Sam, nawet najlepszy, projekt nie zapewnia w tej sytuacji sukcesu, skoro nie da się dokładnie zaplanować kodowania. Sukces staje się w tej sytuacji zależny od procesu nie zawsze przewidywalnego. Na kodowanie trzeba położyć więc większy nacisk. Podkreśla też, że wymagania nieustannie się zmieniają i sztywny projekt nie będzie w stanie za nimi nadążyć. Rozwiązaniem jest opracowanie metody, która będzie mogła adaptować się do zmieniających się warunków. Stwierdza, że konieczna jest stała kontrola małych iteracyjnych działań. Takie podejście prezentują właśnie lekkie metodyki typu Extreme Programming (XP). 2. Co to jest Extreme Programming Extreme Programming to lekka metoda prowadzenia projektów informatycznych. Opiera się ona na zbiorze zasad i sugestii, które powinny być praktykowane. Zasady te nie wtłaczają programistów w stosy 20 listopada 2001 roku Słowa kluczowe: Extreme Programming, Software Engineering Adres e-mail autora: [email protected] Dziękuję Krzysztofowi Mossakowskiemu za nieocenioną pomoc przy korekcie. 2 KRZYSZTOF KACZMARSKI formularzy i niekończących się formalizmów, a jedynie mówią jak i co powinien, a czego nie powinien robić. Praca jest organizowana w taki sposób, by sukces osiągnąć możliwie najszybciej. Wake [7] pisze, że na XP trzeba patrzeć z trzech stron równocześnie: jako dyscyplinę programowania, dyscyplinę pracy grupowej oraz dyscyplinę pracy z klientem. Lekkość tej metodyki oznacza, że rezygnuje ona z formalizmów, które często nadmiernie obciążają programistów i kierowników zespołów. Tutaj nie zmusza się ludzi do tworzenia ton dokumentów, których nikt nigdy nie przeczyta. Podstawową filozofią jest robienie tylko tego, co jest w danej chwili potrzebne. Jednak lekkość ta jednocześnie niekoniecznie oznacza, że XP łatwo jest używać w praktyce. Jak wykazują nawet nieformalne analizy działań firm, mało która jest w stanie sprostać wszystkim wymaganiom stawianym przez tą metodykę [9]. Jednak utrzymanie dyscypliny pracy procentuje w tym, że osiąga się zadowolenie klienta oraz dużą satysfakcję z wykonanego zadania. Początkowo może wydać się dziwne, że pomimo wyeliminowania formalizmów obecnych w innych metodykach można osiągnąć wysoką jakość. Przecież te formalizmy powstawały przez lata właśnie po to, by ustalić standard jakości. Zgodzi się ze mną jednak większość programistów, że standardy wprowadzane w ciężkich metodykach oznaczają wiele dodatkowej pracy, której sens i wartość jest problematyczna. XP jest zaprojektowane w taki sposób, by wszystkie zasady uzupełniały się wzajemnie. Dzięki temu pomimo braku ściśle ustalonych formuł doprowadza do celu nie tylko w zamierzonym czasie, ale i z produktem najwyższej jakości. Tom DeMarco [4] twierdzi, że Extreme Programming to ruch, który przez akcentowanie talentu, pracy zespołowej, lekkiego procesu i dyscypliny bez dogmatów przyniesie odświeżenie i nową energię do zespołów programistycznych. Opracowane ostatnio ciężkie metodologie typu CMM określa jako bezrozumne. Historia XP. W ’90 latach Chrysler próbował stworzyć system płacowy dla całej firmy. Projekt na skutek błędnego zarządzania i kłopotów technicznych popadł w poważne tarapaty. W roku ’96 szefowie przekazują projekt Kentowi Beckowi, który szybko stwierdza, że to co powstało jest do niczego i radzi rozpocząć od nowa. Chce założyć nowy zespół i organizować pracę w zupełnie inny sposób. Istnieją już wtedy podstawy teoretyczne XP opracowane przy pomocy Warda Cunninghama. Powstaje zespół C3, który staje się polem doświadczalnym dla XP. System zostaje ukończony, jednak po pewnym czasie projekt popada w finansowe tarapaty i zostaje anulowany w ’99 roku. Obecnie teoria EXTREME PROGRAMMING . . . 3 związana z metodologią XP dynamicznie się rozwija i jest szeroko testowana na całym świecie. Przez swoje dość rewolucyjne podejście zyskała sobie tyle samo zwolenników, co przeciwników. Trudno powiedzieć jak będzie wyglądała przyszłość XP. Dziś jasne jest jedynie, że odejście od ciężkich metodyk wydaje się (w większości przypadków) nieuniknione. Nazwa. Istotę tej metody najlepiej oddaje jej nazwa. Programowanie jest, wraz z powstałym w jego wyniku kodem, najważniejszą czynnością podczas tworzenia oprogramowania. Kod jest zawsze jednoznacznym i formalnym sposobem opisu systemu. Jeśli kod nie działa jak należy system nie będzie mógł być zaakceptowany. XP dąży więc do poprawy jakości kodu. Sposobem na osiągnięcie tego celu jest ekstremalne potraktowanie pewnych znanych od dawna zasad (o których wiadomo, że są dobre, sprawdzone i skuteczne): weryfikacji kodu, testowania, iteracyjnego tworzenia małych wydań i prostoty. Praktyki te są stosowane w sposób ciągły (programowanie w parach, ciągłe testowanie, nieustanne przeprojektowywanie). Nacisk na te zasady jest tak silny, że są one posunięte niemal ’do granicy wytrzymałości’. Takie właśnie podejście ma zapewnić XP sukces. 3. Podstawowe praktyki Kent Beck [6] podkreśla jako kluczowe 12 praktyk, których powinno się przestrzegać, by można było powiedzieć, że realizuje się metodykę XP. W rzeczywistości trudno jest sprostać wszystkim wymaganiom. Proponowane są więc, podobnie jak w innych metodykach pewne stopnie, kolejne etapy, na drodze do pełnego stosowania XP. Trzeba podkreślić jednak, że dopiero stosowanie wszystkich praktyk jest w stanie zagwarantować sukces i zminimalizować szanse porażki. Wybór jest ekstremalny: albo pełna rewolucja i wielki sukces albo balansowanie pomiędzy zabezpieczeniami i przyjemnością. 3.1. Planowanie. Tworzenie oprogramowania w XP odbywa się przyrostowo przez wdrażanie kolejnych wydań produktu. Planowanie wydania odbywa się przed rozpoczęciem każdej nowej iteracji. Podstawowym celem jest oszacowanie każdej pojedynczej historii użytkownika, powstałej w wyniku gry planistycznej z klientem. Do szacowania używa się jednostek zwanych idealnymi osobo-tygodniami. Idealny osobotydzień to tydzień pracy wyłącznie nad programem, bez dodatkowych zajęć, ale wliczający czas testowania programu. Historie użytkownika to spisane na niedużych kartach małe specyfikacje pojedynczych zadań, jakie mają być realizowane przez system. Opis taki nie powinien przekraczać jednego, dwóch zdań. Projektanci 4 KRZYSZTOF KACZMARSKI mogą stwierdzić, że przedstawiona historia jest zbyt duża i poprosić użytkownika o podzielenie jej na mniejsze części. Podczas gry planistycznej klient określa, które historie są dla niego najważniejsze i które z nich powinny być zrealizowane w pierwszej kolejności. W rezultacie powstaje spis funkcji systemu, które będą do niego dodawane w ramach kolejnych wydań produktu. Podczas tworzenia oprogramowania odbywa się wiele iteracji, z których każda jest oddzielnie planowana, ukończona złączeniem i osiągnięciem działającej wersji systemu. 3.2. Małe wydania. Małe kroki to częste łączenie kodu napisanego przez programistów. Osiąga się je przez podział zadania na małe historie użytkownika. Dzięki temu pojedynczy fragment kodu może być łatwo i szybko wykonany, przetestowany i złączony z resztą systemu. Małe wydania to częste akceptacje powstałego systemu przez klienta. Dzięki ciągłym testom i łączeniu zawsze istnieje sprawnie działająca wersja, a klient nie musi długo czekać na kolejną. Ciągle istnieje też informacja zwrotna od klienta, który ocenia czy zespół realizuje to, o co mu chodziło. 3.3. Metafora systemu. Każdy zespół programistyczny musi kontaktować się z klientem. Często dochodzi do sytuacji, w której po godzinach rozmów nagle odkryto, że klienci i projektanci mówią o zupełnie różnych rzeczach. Wynika to oczywiście z tego, że jedni i drudzy posługiwali się innymi pojęciami. Klient patrzy na system przez pryzmat swojego działania i nie jest mu łatwo, a często nie jest w stanie, nazywać rzeczy inaczej niż przywykł. Nie będzie więc mówił o encjach bazy danych zamówień, ale o kartkach z kalendarza itd. Aby możliwe było wzajemne porozumienie potrzebne jest opracowanie wspólnego słownika używanych pojęć. Tworzenie jednak takich rozbudowanych słowników jest kosztowne i pracochłonne, a zapamiętanie wszystkich haseł może być trudne. Aby uniknąć problemów z komunikacją oraz ze słownikiem XP stosuje metaforę systemu. Jest to nic innego jak analogiczne do projektowanego oprogramowania pojęcie, które jest w sposób oczywisty zrozumiałe na klienta i dla programisty. Klient może np. uznać, że dobre jest dla niego określenie zakładania czapki. Taka czapka zakładana na program powoduje, że zaczyna się on inaczej zapisywać dane. Programiści doskonale wiedzą, że chodzi o filtr konwertujący dane wyjściowe do innej, potrzebnej postaci. Metafora systemu jest szczególnie ważna dla klientów, którzy nie są zapoznani z technologią komputerową i którzy nie mogą operować specyficznymi pojęciami. W takich sytuacjach programiści używają jej do EXTREME PROGRAMMING . . . 5 wyjaśnienia działania programu bez zagłębiania się w techniczny żargon. Klient szybko pojmuje o co chodzi, a nawet może bez trudu podjąć dialog i podać swój punkt widzenia, ponieważ słownictwo i pojęcia używane w metaforze systemu są mu dobrze znane. Metafora pomaga też spojrzeć na system z innej strony, co może pomóc w postawieniu pytań, które wcześniej nie przychodziły do głowy. Skoro już np. ustaliliśmy, że mamy napisać ’czapkę’ dla jakiegoś oprogramowania, która spowoduje to i tamto, to dobrze jest sobie zadać pytanie ’jak ją się zakłada i jak się zdejmuje ?’ oraz ’czy można założyć dwie czapki na raz ?’. 3.4. Prosty projekt. XP zakłada, że wymagania klienta, rynku i sytuacja w branży ciągle się zmieniają. Nie ma więc sensu planować rozwiązań, o których nie wiadomo, czy zostaną wykorzystane w przyszłości. Celem XP jest jak najszybsze i najprostsze osiągnięcie satysfakcji klienta przez dostarczenie oprogramowania, spełniającego postawione wymagania. Programista implementując daną historię użytkownika stara się osiągnąć sukces przy minimalnych nakładach. Jeśli klient chce dodać nową funkcjonalność musi stworzyć nową historię. Jej koszt i pozycja na liście ważności zostaje ustalona w wyniku kolejnej gry planistycznej. 3.5. Ciągłe testowanie. Ciągłe testowanie to podstawowe działanie podczas pisania programu w metodzie XP. Programista jeszcze przed napisaniem danej procedury tworzy kod, który ma ją testować. W ten sposób wcześniej musi pomyśleć o wszystkich rzeczach, które mogą ’pójść źle’. Dzięki temu podczas pisania właściwego kodu procedury zabezpieczy ją przed tymi możliwościami. Pisanie procedury testowej nie powinno jednak trwać zbyt długo i nie powinna być ona zbyt rozbudowana. Zespół dąży do automatyzowania procedur testowych, które są uruchamiane po każdorazowym łączeniu kodu oraz po przerabianiu. W ten sposób istnieje pewność, że zmiany w innych częściach oraz integracja programu nie spowodowały nowych problemów. Ponadto dla każdej historii, powstałej w grze planistycznej, klient określa test akceptacyjny. Kolejne wydanie nie jest zakończone dopóki test ten nie zostanie zdany pomyślnie. 3.6. Przerabianie. Przerabianie (eng. refactoring) jest konieczne zaraz po przetestowaniu działającej procedury. Przerabianie to według autora sformułowania [8] „poprawianie projektu istniejącego kodu”. Należy pamiętać, że przerabianie nie może zmieniać zewnętrznego zachowania programu. 6 KRZYSZTOF KACZMARSKI Przerabianie może być przeprowadzone w celu uzyskania wielu różnych efektów. Jako najbardziej oczywiste wymienia się poprawienie wydajności działania procedury, oraz uzyskanie lepszej struktury systemu. Przerabianie może mieć jednak jeszcze inne cele np. uzyskanie bardziej przejrzystego kodu. Przykładowe konkretne działania podczas przerabiania to: skracanie metod, skracanie klas, przesuwanie zwalniania zasobów do bloków catch oraz finally, usuwanie ’prawie’ powtarzających się fragmentów kodu, usuwanie niepotrzebnych iteracji, usuwanie ’magicznych’ współczynników, usuwanie zbyt wielu zmiennych roboczych. Każdorazowe przerabianie, nawet jeśli jest najprostsze, musi oczywiście zakończyć się uruchomieniem testów. 3.7. Programowanie w parach. Jednym z bardziej krytykowanych przez szefów zespołów elementem XP jest praca w parach. Uważają oni, że w ten sposób tracą połowę ’siły roboczej’: „Którą firmę stać na to by posadzić dwóch programistów przy jednym komputerze!”. Pogląd ten jest jednak tylko na pierwszy rzut oka zasadny. Każdy kto kiedykolwiek spróbował programować w parach doświadczył, że diametralnie zmienia ono sposób pisania kodu. Podczas gdy jedna osoba (trzymająca klawiaturę) pisze kod, druga na bieżąco go sprawdza, sugeruje możliwe rozwiązania, może służyć pomocą i zwraca uwagę na błędy syntaktyczne. Tak powstały kod jest nie tylko lepszy ale i łatwiej oraz szybciej się kompiluje. Według Kenta [6] pary powinny się między sobą mieszać. Również programiści wewnątrz pary powinni co jakiś czas zamieniać się miejscami. W ten sposób wysiłek jest rozłożony równomiernie. Programowanie w parach jest trudne, wymaga dobrego zgrania zespołu, ale przynosi wymierne korzyści w postaci lepszego kodu. Programowanie w parach pomaga również w dokonywaniu poprawek. Druga osoba może bowiem wiedzieć więcej o danym fragmencie kodu. Generalnie programowanie w parach pomaga propagować wiedzę o różnych fragmentach programu na całą grupę osób, pracujących przy systemie. 3.8. Standard kodowania. XP narzuca wszystkim programistom wspólny standard kodowania i dokumentowania. Standard taki powinien być ustalony i zaakceptowany przez całą grupę. Jeśli ktoś nie chce się zgodzić na zrezygnowanie ze swojego przyzwyczajenia, a grupa nie może zaakceptować jego propozycji, nie może uczestniczyć w projektach realizowanych przy pomocy XP. Standard powinien jednoznacznie określać wygląd kodu, ale nie powinien być zbyt długi i szczegółowy. Polecane są opracowania jednostronicowe. EXTREME PROGRAMMING . . . 7 Standard dokumentowania zakłada, że samych komentarzy w kodzie jest jak najmniej. Klasy powinny być tak zaprojektowane by przeznaczenie poszczególnych metod było jasne, a samo działanie oczywiste. Jeśli nie da się tego osiągnąć przy pomocy przerabiania, można zamieścić skrótowe opisy. Jedyną formą komentowania jest dokumentowanie całych klas. Poleca się zwięzłe opisanie przeznaczenia klasy i jej działania. XP stara się podtrzymać naturalne skłonności programistów do upiększania i ulepszania kodu. Komentowanie tego, co jest piękne i przejrzyste może zakrawać na profanację. 3.9. Wspólna odpowiedzialność. Dzięki standardom kodowania każdy programista czuje się jak ’u siebie’ w każdym fragmencie systemu, nawet jeśli go nie pisał. Zbiorowa praca nad kodem, to jednak nie tylko wspólne pisanie go, ale i wspólna odpowiedzialność za niego. W niektórych zespołach nie wiadomo, kto jest odpowiedzialny za dokonanie poprawek. Kiedy trzeba szybko wykonać poprawki nie ma czasu na poszukiwania ’właściwej osoby’. Taka osoba może być zresztą już nieosiągalna. W XP wszyscy są odpowiedzialni tak samo. Jeśli trzeba coś zmodyfikować nie ma problemu, bo poprawki może zrobić każdy. Częste przeorganizowywanie doprowadza kod do stanu dobrej przejrzystości, a gotowe procedury testujące zapewniają, że poprawki nie doprowadzą do katastrofy. XP preferuje umieszczenie całej grupy programistów w jednym pomieszczeniu, co ma pomagać w komunikacji i rozwijaniu życia grupy. Zostawia jednak dla każdego jego prywatną przestrzeń. Do pracy w parach powinny być wyznaczone oddzielne komputery. 3.10. Ciągłe łączenie. Ciągłe łączenie to integracja programu tak często, jak to tylko możliwe. Programista po wykonaniu każdego nowego fragmentu programu łączy go z systemem. Najczęściej stosuje się jedną maszynę, na której w danej chwili może pracować jedna osoba zajmująca się łączeniem kodu. Ciągłe łączenie jest ułatwione w XP dzięki prostym projektom, ciągłym testom i wspólnej odpowiedzialności za kod. 3.11. 40-godzinny tydzień pracy. Swego rodzaju symbolem, znakiem rozpoznawczym XP, stało się wymaganie 40-to godzinnego tygodnia pracy. Zespoły programistów powinny być przyzwyczajone do stałej wydajności i stałego obciążenia. Może przytrafić się czasem jeden tydzień nieco większego obciążenia, ale dwa tygodnie mogą już oznaczać kłopoty z harmonogramem prac. Oczywiste jest, że dla niektórych zespołów tydzień może trwać 45 godzin, a dla innych 35. Istotne jest to, by ustalić konkretną, nienaruszalną granicę obciążenia grupy. Kent 8 KRZYSZTOF KACZMARSKI Beck tłumaczy to podejście jako zmianę filozofii z myślenia: „Nie mamy dość czasu” – która prowadzi do wydłużania czasu pracy, na filozofię: „Mamy zbyt wiele do zrobienia” – która zwraca uwagę raczej na przeorganizowanie zadań. 3.12. Ciągły kontakt z klientem. Aby zadowolić wymagania klienta należy bezwzględnie podążać za jego życzeniami. Co jednak zrobić, gdy klient zapomniał nas o czymś poinformować lub mamy problem który wymaga przekonsultowania? Potrzebny jest kontakt z klientem. Często jest on jednak nieosiągalny, co doprowadza do opóźnień w realizacji projektu. XP zakłada ciągłą możliwość konsultacji z klientem ’na żywo’. W praktyce oznacza to codzienną obecność klienta w zespole programistów. Często bywa to jednak trudne do spełnienia. Zespoły takie mogą zrezygnować z XP, zorganizować zastępczą formę komunikacji z klientem, bądź znaleźć inne rozwiązania pozwalające na utrzymanie więzi z odbiorcą systemu. Niektórzy twierdzą, że klient nie jest poważny, jeśli nie może poświęcić wystarczająco dużo czasu dla nowego systemu. 4. Technika Pracy Skoro poznaliśmy już podstawowe zasady, jesteśmy gotowi do przejścia przez działania podejmowane podczas realizowania projektu z metodyką XP. Przyjrzymy się dokładniej poszczególnym osobom pracującym na różnych stanowiskach w zespole. XP jest przeznaczone dla małych ekip od 2 do 10 osób. Taki zespół, kiedy jest dobrze zorganizowany może być wydajniejszy od większych grup, które pracują w ciężkiej metodyce. Rysunek 1. Podstawowe czynności podczas pracy w XP EXTREME PROGRAMMING . . . 9 4.1. Planowanie. Pojedyncze wydanie systemu powinno powstawać od miesiąca do kilku miesięcy. Jest zaplanowane w taki sposób, by dostarczyć użytkownikom określoną ilość nowych funkcji systemu. Gra planistyczna. Klient tworzy historyjki, zapisując je na kartach. Jedna historia jest jedną funkcją, bądź cechą, która ma być zrealizowana w systemie. Może to być na przykład „możliwość wybierania zakresu czasowego wyświetlanych wyników” lub „szybki podgląd dokumentu przed otworzeniem”. Programista analizuje wszystkie karty i ocenia czy nie są nazbyt skomplikowane (wtedy prosi o podzielenie zadania na mniejsze części) oraz czy zadanie jest dla niego zrozumiałe (prosi klienta o dodatkowe wyjaśnienia). Na zakończenie powstaje zestaw kart zawierających pełną, podzieloną na małe kawałeczki, specyfikację systemu. Ważne w XP jest to, że programista czuwa nad pomysłami klienta. Zgodnie z zasadą nie robienia tego, czego klient nie będzie potrzebował, musi upewnić się, że klient dokładnie wie czego chce i naprawdę będzie tego używał. Programista może też podpowiadać pewne rzeczy, które nie muszą przyjść klientowi do głowy w pierwszej chwili. Szacowanie. Następnie programiści określają koszt zaimplementowania każdej historyjki. Koszt jest wyrażany we wspomnianych wcześniej idealnych osobo-tygodniach. Jednostki te zwykle kalibruje się do możliwości zespołu przez podzielenie przez magiczny współczynnik. Najczęściej jest to dwa lub trzy. Ustalenie kolejności. Po oszacowaniu klient wie już, które elementy systemu będą bardziej, a które mniej kosztowne. Pozwala mu to poukładać karty z wymaganiami według hierarchii ważności i potrzeb. Programiści będą realizować zadania z kart w kolejności ustalonej przez klienta, co oznacza, że system będzie na początku zawierał te funkcje, które są najbardziej potrzebne klientowi. Ważne jest, że ani klient ani programiści nie są przywiązani do ustalonej kolejności. Klient może postanowić o zmianie kolejności kart w każdym momencie. Programiści mogą dodatkowo uporządkować historie według ryzyka, które określa czy dana rzecz jest trudna, czy łatwa do zrobienia. Pozwala to klientowi zapoznać się z tym co może stwarzać problemy, co jest zagrożone, a co jest łatwe i pewne. Często również zespoły programistów wolą wydzielić trudne elementy systemu, np. po to by przydzielić je bardziej doświadczonym pracownikom. Zaplanowanie wydania . . . . Jeśli zakończono szacowanie wszystkich historyjek i klient ustalił kolejność ich wykonywania, można zaplanować 10 KRZYSZTOF KACZMARSKI Rysunek 2. Przykładowa karta historii klienta kolejne wydania. Suma punktów na kartach podzielona jest przez możliwości zespołu dla pojedynczej iteracji, która trwa zwykle około dwóch, trzech tygodni. W ten sposób uzyskuje się liczbę iteracji, potrzebnych do ukończenia danego wydania. Prędkość pracy zespołu powinno się ustalić eksperymentalnie wraz z nabywanym przez zespół doświadczeniem w XP. . . . oraz iteracji. Po zaplanowaniu z klientem wydania zespół przystępuje do zaplanowania iteracji. Odbywa się to na bardzo podobnych zasadach do planowania wydania. Programiści decydują, nad którymi historiami będą pracować i rozbijają je na zestawy mniejszych zadań. Podział na zadania jest wynikiem ’burzy mózgów’ całego zespołu. Programiści wybierają sobie zadania do realizacji i szacują (każdy dla siebie) czas ich wykonania. Wydajność danego programisty oceniana jest na zasadzie „wczorajszej pogody”, zgodnie z którą najlepszym prognostykiem jest doświadczenie z przeszłości. Może też okazać się, że konieczne jest dokładniejsze określenie historii klienta, bądź rozbicie jej na mniejsze. Wykonanie projektu. Zespoły stosujące XP nie potrzebują wiele dokumentacji ze względu na bardzo rozwiniętą komunikację w grupie. Wszyscy pracują w jednym pomieszczeniu, razem podejmują istotne decyzje. Grupa może stworzyć ogólny projekt systemu, który będzie realizować. Projekt taki powinien być umieszczony (narysowany) na dobrze widocznej tablicy na ścianie. Zwykle programiści tworzą różne schematy, które pomagają im ogarnąć program. Nie należy im tego zabraniać, jeśli mają na to ochotę. Podstawowym jednak źródłem wiedzy o systemie EXTREME PROGRAMMING . . . 11 w XP są inne osoby w grupie. Komunikacja z innymi zapewnia sukces i właściwą koordynację działań. Generalnie rzecz biorąc dokumentacja jest raczej tworzona na potrzeby świata zewnętrznego. W zespole jest zawsze szybciej i łatwiej zapytać tego, kto wie jak rozwiązać problem. 4.2. Typowy dzień. Poranne spotkania. Zespół zaczyna pracę od krótkiego spotkania ’na stojąco’. Spotkanie to ma na celu zakomunikowanie problemów, które się ostatnio pojawiły i rozważenie możliwych rozwiązań. Odbywa się na stojąco, by uniknąć pokusy długiego debatowania, które prowadzi zwykle jedynie do straty czasu. Decyzje powinny być podejmowane przez kompetentne osoby, a nie przez rozdyskutowanych programistów. Spotkania takie mogą odbywać się wokół komputerów, gdzie na bieżąco można przeglądać kod i rozmawiać o konkretnych rozwiązaniach. Dobrze jest ustalić godzinę porannego spotkania na stałe, tak by zespół ciągle miał świadomość nienaruszalnych ram czasowych dnia i tygodnia. Spotkanie powinno trwać około 10 minut, Rysunek 3. Działania podczas typowego dnia pracy.XP Programowanie. Po rozdzieleniu zadań na programistów, zespół przystępuje do pracy. Każdy wybiera sobie osobę, z którą chce danego dnia pracować oraz zadanie do realizacji. Programowanie w parach może być 12 KRZYSZTOF KACZMARSKI dla niektórych uciążliwe. Wszyscy członkowie zespołu muszą je jednak zaakceptować, gdyż jest ono ważne dla XP – zapewnia wysoką jakość wykonanego programu. Podobnie przerabianie i ciągłe testowanie ma na celu doprowadzenie kodu do idealnej postaci. Jeśli kod będzie niejasny, nieoptymalny pod kątem projektowym, zespół szybko osiągnie stan chaosu, gdy programiści będą ślęczeć nad kodem, bezskutecznie próbując zrozumieć o co w nim chodzi. Programowanie i projektowanie w XP opiera się na zasadzie, by tworzyć tylko to, co będzie potrzebne. Należy bezwzględnie unikać tworzenia funkcji i konstrukcji, których przydatność w danej chwili jest mglista. Podstawowa zasada: „zaprogramuj tylko to co jest teraz potrzebne i to w możliwie najprostszy sposób”. Przed zaprogramowaniem danego zadania programiści tworzą procedurę testową. Bezpośrednio po napisaniu procedura testowa nie może się skompilować, bo nie ma jeszcze procedury, która ma być testowana. Następnie tworzony jest szkielet właściwej procedury, który pozwala przekompilować procedurę testową. Jednak ciągle uruchomienie testu musi zwrócić błąd, gdyż testowana procedura jeszcze nic nie robi. Dopiero potem para przystępuje do napisania właściwego kodu procedury. W momencie, gdy procedura jest już gotowa i przetestowana, para przystępuje do jej przerobienia. Zwracana jest uwaga na wydajność, przejrzystość i piękno. Po każdorazowej zmianie uruchamiane są testy. Przerabianie i testowanie trwa aż do uzyskania idealnego kodu, nie powinno jednak trać zbyt długo. Może okazać się, że programista ma pytania do klienta. Może wtedy poprosić o pomoc i dodatkowe wyjaśnienia. Łączenie. Po stworzeniu i przetestowaniu nowej części oprogramowania dołącza się ją do działającego systemu. Całość systemu po połączeniu jest znów testowana. Zakłada się, że na raz dokonuje się tylko jedno łączenie. Dołączenie nowo powstałego kodu odbywa się możliwie często, nawet co kilka godzin. Dzięki temu maszyna, która zawiera repozytorium ma zawsze najnowszą i sprawną wersję systemu. Ułatwia to znakomicie pracę pozostałych programistów, którzy z niej korzystają. Częste łączenie pozwala również na szybkie wykrycie problemów zgodności pomiędzy częściami systemu. Może zdarzyć się, że powstały kod nie daje się łatwo zintegrować z systemem i testy systemowe zawodzą. Jeśli programista nie zdąży tego zrobić do końca dnia pracy, poleca się, by wyrzucił stworzony kod i zaczął następnego dnia od nowa. Koniec dnia. Po przepracowaniu ustalonego czasu, uśmiechnięty zespół idzie do domu. Jeśli ktoś nie skończył programować swojego zadania EXTREME PROGRAMMING . . . 13 może skończyć następnego dnia, z tą samą, bądź z inną osobą. Zaleca się jednak, żeby każda para wykonała wybrane zadanie do końca i dokonała złączenia. W ten sposób wszyscy opuszczają biuro z głowami wolnymi od problemów – zadanie zostało wykonane i wszystko gra. 5. Zespół W Extreme Programming zespół jest wspólnotą ludzi, którzy razem dążą do celu. Są nie tylko odpowiedzialni za projekt ale i troszczą się o niego. Darzą się wzajemnie szacunkiem i mają silne poczucie więzi. W zespole XP poza programistami są też inne osoby, odpowiedzialne za zarządzanie, oraz pomagające rozwiązywać szczególnie trudne problemy. Są to: trener, zarządca, tester, konsultant, szef i klient. Wszystkie one mają bardzo ściśle określone kompetencje i nie powinny wzajemnie sobie wchodzić w drogę. Wszyscy są odpowiedzialni za proces powstawania aplikacji, ale gdy zespół zdobędzie pewne doświadczenie nie wszyscy będą potrzebni. Poniżej omówię zadania każdej z tych osób. Programista. Zadania programisty są generalnie te same co zawsze. Celem jego pracy jest stworzenie oprogramowania. Tutaj jednak jego odpowiedzialność jest szersza. Bierze on czynny udział w procesie projektowania oraz sterowania wykonaniem. Musi też mieć świadomość pracy w zespole, w którym jest współodpowiedzialny za powstający system. Powinny więc być praktykowane działania pozwalające odczuć mu tą odpowiedzialność i wspólnotę z innymi. Programista musi w związku z tym posiąść pewne umiejętności, które nie są wymagane w innych metodykach, nie tylko takie jak testowanie oraz refaktoring, ale i również zdolność łatwego komunikowania się oraz posiadać wrodzony nawyk prostoty. Wiedza o systemie rozłożona jest na wszystkich członków zespołu. Każda osoba, również programista, musi więc potrafić zrezygnować z własnej dumy by zapytać innych o radę. Klient. Klient w XP zajmuje szczególnie ważne miejsce. Zajmuje on stałe miejsce przy projektowaniu (gra w planowanie) oraz przy testowaniu (testy akceptacyjne). Ponadto kontroluje wykonanie aplikacji (choć nie może nim sterować) i podejmuje decyzje o kolejności realizacji modułów. Aby mógł sprostać tym zadaniom powinien nauczyć się pisać testy funkcjonalne oraz tworzyć opisy (historie użytkownika). W czasie realizacji projektu może okazać się potrzebny by rozstrzygać kwestie sporne i wyjaśniać problemy. Jest on najlepszą osobą, która może to zrobić ponieważ posiada dokładną wiedzę jak system powinien działać. 14 KRZYSZTOF KACZMARSKI Tester. Tester spełnia funkcję kontrolną wobec programisty, ale nie na zasadzie ustawianie się w opozycji do niego. Jego zadaniem jest regularne uruchamianie testów i publiczne ogłaszanie ich wyników. Jego podstawowym współpracownikiem jest klient, któremu pomaga tworzyć i wykonywać testy funkcjonalne. Z czasem, jeśli klient nabiera doświadczenia jego rola może maleć. Koncentruje się wtedy na potwierdzaniu testów. Konsultant. Czasem potrzebna jest określona wiedza specjalistyczna. Zespół nie powinien w takiej sytuacji tracić czasu na poszukiwanie rozwiązania, lecz powinien uzyskać je od konsultanta. Aby praca była maksymalnie wydajna zespół musi rzetelnie i precyzyjnie opisać problem. Konsultant rozwiązuje problem samodzielnie, a zespół może co najwyżej się przyglądać. W ten sposób może nabyć wiedzę, która pozwoli mu w przyszłości rozwiązać problem samodzielnie. Może też zdarzyć się, że zespół po poznaniu rozwiązania stworzy własne, alternatywne w stosunku do zaproponowanego. Trener(coach) i Zarządca(tracker). Trener jest osobą, która ponosi odpowiedzialność za cały proces tworzenia systemu. Musi utrzymać zespół na właściwej drodze do rozwiązania. Aby to zrobić musi posiadać spore doświadczenie, musi głęboko rozumieć istotę XP i potrafić dobrze nim sterować. Jego działanie często jest pośrednie przez zasugerowanie zmiany kierunku pracy przy pomocy określonego testu, bądź przypadku. Pomaga w ten sposób zespołowi w samodzielnym dojściu do poprawnych decyzji. Powinien też wiedzieć ile czasu potrzeba na zrobienie danego zadania. Zna też sposoby zaradzenia pojawiającym się problemom. Często trener musi być dostępny jako partner do programowania dla mniej doświadczonych. Pomaga w tworzeniu testów i refaktoringu. Jego rola może maleć wraz z rozwijaniem się zespołu i dochodzenia do wspólnej odpowiedzialności za projekt. Zarządca jest swego rodzaju sumieniem zespołu. Jest on odpowiedzialny za właściwe szacowania. Kontroluje czy oczekiwania mają odzwierciedlenie w rzeczywistości. Śledzi obciążenie i jakość oszacowań (na podstawie danych z przeszłości) każdego programisty. Jako historyk zespołu prowadzi dziennik testów funkcjonalnych, wykrytych wad, osób za nie odpowiedzialnych i testów, które pozwoliły je wykryć. Jego praca nie może jednak zbytnio obciążać zespołu. Potrzebne mu dane powinien zbierać w sposób maksymalnie niezauważalny. Szef. Szef ma prawo wymagać rzetelnej komunikacji z zespołem. Jeżeli coś idzie nie tak powinien być natychmiast poinformowany. Może wtedy zaproponować pewne rozwiązania, ale nie ma władzy nad terminarzem EXTREME PROGRAMMING . . . 15 projektu. To zespół określa warunki realizacji na podstawie środków zapewnionych przez szefa. Zespół ma prawo oczekiwać od niego odwagi, zaufania, zrozumienia i szybkich, kompetentnych reakcji. Taki szef będzie dobrze kierował zespołem XP, a jego zespół będzie zadowolony z pracy. Może się jednak zdarzyć, że szef będzie musiał zatrzymać bezsensowne działania zespołu, które nie przynoszą efektu. Zapewnienie właściwych warunków pracy. Aby zespół mógł dobrze funkcjonować musi mieć zapewnione odpowiednie warunki pracy. Pomieszczenie powinno być wspólne dla wszystkich, tak by zapewnić swobodną komunikację. Jednocześnie powinny istnieć (być może pod ścianami) miejsca na prywatne rozmowy, odgrodzenie się od reszty w razie potrzeby oraz przechowywanie prywatnych rzeczy. Wyniki pracy i śledzenie postępów powinny być widoczne na zawieszonych na ścianach tablicach. Komputery do pracy w parach umieszczone są w centrum. W ten sposób łatwiej siadać przy nich w dwie osoby. Całość powinna być zaakceptowana i lubiana przez cały zespół. Musi się on czuć dobrze, przydatne mogą być odpowiednie gadżety i lubiane przez nich przedmioty. Miejsce wspólne z kanapą i ekspresem do kawy powinno być maksymalnie sympatyczne i przyjemne. Czasem potrzebna jest chwila relaksu, gdy coś idzie nie tak i nie wiadomo jak ruszyć z miejsca. Pomieszczenie jest nierozerwalnie związane z zespołem, który nie będzie funkcjonował poprawnie, jeśli nie będzie się w nim dobrze czuł. Zapewnienie dobrych warunków pracy ma zdecydowane pierwszeństwo wobec innych prac firmy. 6. Podsumowanie 6.1. Co to znaczy wybrać XP. Szefowie, którzy zdecydują się na wprowadzenie XP muszą być świadomi jakie to rodzi konsekwencje. Przede wszystkim muszą zgodzić się na oddanie programistom władzy nad sterowaniem projektem. Muszą ograniczyć zespół do maksymalnie 10 osób. Autorzy metody podkreślają, że zespół tej wielkości sprawnie pracujący w XP może być o wiele wydajniejszy niż o wiele większe grupy pracujące w ciężkich metodykach. Szefowie muszą również potrafić sterować wspólnym życiem grupy ludzi w zespole. Muszą potrafić zorganizować miejsce pracy tak by było przyjazne, pomagało w komunikacji oraz pozwalało na celebrowanie wspólnych spotkań, posiłków i rozmów, a jednocześnie zapewniało niezbędną prywatność i spokój. Dobrym przykładem jest tu zespół C3 i jego pokoje pokazane na stronach [3]. Szefowie muszą wreszcie potrafić podejmować niepopularne ale konieczne decyzje oraz mieć odwagę ’skoczyć na głęboką wodę’. 16 KRZYSZTOF KACZMARSKI 6.2. Czemu zapobiega XP. Przy przestrzeganiu zasad wydaje się oczywiste, że stosując to metodę można zapobiec wykonywaniu pracy która nie ma znaczenia (bo zgodnie z zasadą minimalizacji rozwiązania robimy tylko to co jest potrzebne), częstemu anulowaniu projektów (bo ciągły kontakt z klientem zapewnia spełnienie jego wymagań, a jego udział w procesie projektowania zapewnia dobranie właściwego harmonogramu prac) i wykonywaniu pracy z której nie jest się dumnym (bo tworzony kod jest najwyższej jakości, a zespół cały zespół pracuje nad osiągnięciem perfekcyjnego produktu). 6.3. Co daje XP. Zyski z wprowadzenia XP są oczywiste, nie da się ich jednak dobrze opisać i pojąć bez własnoręcznego wypróbowania. Wprowadzenie XP daje nie tylko bardzo dobrą aplikację, ale i dużo satysfakcji z własnej pracy. Kent Beck podkreśla, że nie bez znaczenia jest również stałe obciążenie zespołu i postawienie nacisku na nieprzemęczanie go. Doprowadza to oczywiście do mniejszego stresu i w rezultacie również zwraca się w podniesieniu jakości pracy. Nie jest łatwo zaufać i wprowadzić w życie wszystkie zasady XP. Jeśli jednak zarzuci się któreś z nich, można stracić wiele z potencjalnych zysków. Pamiętać należy również, że XP nie jest sztywne, ale może dostosowywać się do potrzeb i danego otoczenia. Przedstawione praktyki i sposób pracy to jedynie początek. Zachętą do podjęcia wyzwania może być to, że wiele zespołów na świecie stosuje je z sukcesem. Osiągają oni duże zadowolenie klienta i satysfakcję z dobrze wykonanej pracy. Współtwórca XP Kent Beck mówi, że „XP jest proste w szczegółach, ale trudne w realizacji.” Podstawowe zasoby [1] XProgramming.com - an Extreme Programming Resource http://www.xprogramming.com [2] Extreme Programming: A gentle introduction http://www.extremeprogramming.org [3] WikiWikiWeb: Extreme Programming Roadmap http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap [4] ObjectMentor.com http://www.objectmentor.com/xp/xp.html [5] Martin Fowler The New Methodology http://www.martinfowler.com/articles/newMethodology.html [6] Kent Beck: Extreme Programming Explained, Addison-Wesley, 1999. [7] W.C.Wake: Extreme Programming Explored, Addison-Wesley, 2001. EXTREME PROGRAMMING . . . 17 [8] Martin Fowler et al.: Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999. [9] J. R. Nawrocki, B.Walter, A.Wojciechowski: Propozycja modelu dojrzałości dla Programowania Ekstremalnego III.KKIO 2001
