e-Informatica Software Engineering Journal Extreme89 – gra symulacyjna pomagająca zrozumieć Programowanie Ekstremalne

Extreme89 – gra symulacyjna pomagająca zrozumieć Programowanie Ekstremalne

Jerzy R. Nawrocki,  Adam Wojciechowski
Instytut Informatyki,  Politechnika Poznańska
{Jerzy.Nawrocki, Adam.Wojciechowski}@put.poznan.pl

I śmiech niekiedy może być nauką…

–Ignacy Krasicki
Streszczenie

W rozdziale zaprezentowano grę symulacyjną Extreme89 ułatwiającą zrozumienie podstawowych praktyk Programowania Ekstremalnego. Gra ma charakter zespołowy i trwa 89 minut. Programowanie zastąpiono w niej obliczaniem wartości funkcji rekurencyjnych. Uczestnicy gry pełnią role będące odpowiednikami ról występujących w Programowaniu Ekstremalnym. Cykl gry jest podzielony na dwa wydania a każde wydanie ma dwa przyrosty. Autorzy przedstawiają zarówno grę, jak i wstępne doświadczenia wynikające z jej przeprowadzenia wśród studentów III, IV i V roku informatyki.

1. Wstęp#

Programowanie Ekstremalne (XP) jest stosunkowo nową (ale coraz bardziej popularną) metodyką programowania [Beck2000]. Stanowi ona radykalną zmianę w stosunku do wcześniej proponowanych podejść do wytwarzania oprogramowania. Aby z sukcesem wprowadzać XP do programów kształcenia na uczelniach wyższych (a także do firm) potrzebne są nie tylko wykłady, ale także aktywne formy kształcenia.Jedną z aktywnych form prowadzenia zajęć dydaktycznych są gry symulacyjne stanowiące tzw. miniaturę procesu (ang. process miniature) [process2003]. Poprzez zabawę i współzawodnictwo można w miłej atmosferze nie tylko nabyć wiedzę, ale również nauczyć się obserwowania i wyciągania wniosków zarówno z własnych sukcesów, jak i porażek.

Pierwszą znaną nam grą symulacyjną przybliżającą jej uczestnikom zasady Programowania Ekstremalnego jest Extreme Hour zaproponowana przez Petera Merela [xhour2003]. W grze tej proces budowy oprogramowania został zastąpiony pracą koncepcyjną nad wybranym urządzeniem (np. udoskonalona pułapka na myszy). Słabością tego podejścia jest brak zróżnicowania między wiedzą klienta a wiedzą programistów. Nie ma też elementów będących odpowiednikami testów akceptacyjnych. Brak również zmian, które odgrywają zasadniczą rolę nie tylko w XP, ale we wszystkich zwinnych metodykach programowania.

Inną grę, również stawiającą sobie za cel wprowadzenie do XP, zaproponował Alistair Cockburn [Cockburn2002, str. 140]. Jego gra ma charakter ćwiczenia programistycznego. Zadaniem uczestników gry jest zrealizowanie w ciągu 90. minut prostego licznika (od 0 do 20) dostępnego przez przeglądarkę internetową. Ten pomysł ma również pewne wady. Programowanie na poziomie wydań 40-minutowych nie jest dobrym pomysłem z punktu widzenia szacowania pracochłonności. Przy tym „rozmiarze” zadań jakość szacowania za bardzo zależy od czynników przypadkowych (np. czas odpowiedzi serwera, kłopoty z drukarką) i drugorzędnych (część czasu poświęconego na analizę problemu i dyskusje w zespole jest w przypadku gry znacznie większa niż w rzeczywistym przedsięwzięciu). Nie pozwala to w odpowiedni sposób odzwierciedlić Gry Planistycznej (jest to jedna z głównych praktyk XP) i jej roli. Nie ma też możliwości porównania wyników uzyskanych przez różne zespoły, co uniemożliwia wprowadzenie współzawodnictwa między zespołami.

Autorzy przedstawiają propozycję gry symulacyjnej Extreme89[2], której celem jest zaprezentowanie głównych praktyk Programowania Ekstremalnego bez konieczności programowania. Osoby uczestniczące w grze mają okazję, aby w trakcie zabawy obserwować i zrozumieć zasady współpracy w zespole XP. W definicji zasad gry silny nacisk położony został na ukazanie roli klienta i programistów oraz potrzeby efektywnej komunikacji między nimi. Omówienie gry Extreme89 poprzedzone jest krótkim wprowadzeniem do metodyki XP. Następnie przedstawiono role uczestników i zasady gry oraz ich związek z Programowaniem Ekstremalnym. Na końcu omówiono krótko wstępne doświadczenia wynikające z wykorzystania gry w procesie dydaktycznym na Politechnice Poznańskiej.

2. Kilka słów o Programowaniu Ekstremalnym#

Programowanie Ekstremalne jest metodyką budowy oprogramowania opartą na fundamentach czterech wartości: komunikacji, prostoty, informacji zwrotnej i odwagi[Beck2000]. Głównym celem zespołów programistów korzystających z XP jest szybkie dostarczenie klientowi produktu realizującego funkcje istotne z punktu widzenia jego działalności. Metodykę XP można zatem postrzegać jako powrót do modelu, w którym praca nad kodem programu jest centralnym punktem procesu, a zadowolenie klienta jest miarą sukcesu programistów. Cztery podstawowe wartości XP wyznaczają kierunek doskonalenia współpracy wewnątrz zespołu programistów i opisują cel, który przyświeca Programowaniu Ekstremalnemu: tworzenie oprogramowania o wysokiej jakości za pomocą prostych środków, przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na potrzeby klienta oraz odważnym podejmowaniu trudnych decyzji.

fig1.png

Rys. 1. Warstwowa struktura praktyk XP

Metodą dochodzenia do wartości XP jest realizacja dwunastu podstawowych praktyk Programowania Ekstremalnego. Są to: Gra Planistyczna, krótkie okresy wydania kolejnych wersji, metafora, prosty projekt systemu, konstrukcja testów przed kodowaniem, refaktoryzacja, programowanie w parach, współwłasność kodu, ciągła integracja, brak nadgodzin, udział klienta w zespole i standard kodowania.Praktyki XP można postrzegać w dwóch wymiarach:

  • społecznym – chodzi tu o urzeczywistnianie wartości XP, służących budowie atmosfery pełnego zaangażowania w wykonywaną pracę i zaufania w zespole oraz dobrej komunikacji na linii klient-wykonawca;
  • technicznym – gdzie praktyki stanowią opis procedur, których realizacja służy wytworzeniu artefaktów wysokiej jakości, odpowiadających faktycznym potrzebom klienta.

Uznając centralną pozycję artefaktów (kodu i przypadków testowych), praktyki XP możemy podzielić na trzy warstwy (grupy) wspierające ich konstruowanie na poziomie pary programistów, organizacji programistycznej (firmy) i wszystkich uczestników procesu budowy oprogramowania, czyli programistów i przedstawiciela klienta (rys. 1). Część z wymienionych praktyk znalazła swoje bezpośrednie odbicie w zasadach gryExtreme89 opisanej w następnym punkcie.

3. Cel gry #

Celem gry Extreme89 jest poznanie zasad współpracy w zespole XP. Zadanie to jest realizowane poprzez udział w doświadczeniu, w którym, w rezultacie współpracy klienta i zespołu programistów, powstaje produkt, którego zakres i poprawność zależy zarówno od kompetencji programistów, jak i jakości komunikacji w zespole. Szczególny nacisk położony został na konieczność efektywnego komunikowania się między klientem a programistami. Efekt ten jest osiągnięty poprzez rozdział wiedzy udostępnianej programistom i klientowi.Rozgrywanie Extreme89 w zespołach wieloosobowych (minimalna liczba uczestników to 4 osoby) daje szansę na rzeczywiste obserwowanie efektów stosowania praktyk XP. Uczestnicy mogą m.in. wybierać pomiędzy pracą samodzielną lub rozwiązywaniem zadań w parach. Tropiciel (osoba wspomagająca programistów) może w różnym stopniu angażować się w komunikację z klientem i wspieranie pracy programistów. Końcowy sukces całego zespołu zależy w dużej części od sposobu prowadzenia Gry Planistycznej, w czasie której zapadają decyzje odnośnie zakresu i kolejności podejmowanych zadań. Prace programistyczne są w grze zastąpione rozwiązywaniem zadań arytmetycznych. Uczestnicy odgrywający rolę programistów mają za zadanie obliczyć wartości funkcji rekurencyjnych dla podanych parametrów.

Organizowanie gry Extreme89 jest możliwe praktycznie w każdych warunkach. Do gry potrzebne są przygotowane materiały drukowane stanowiące repozytorium wiedzy poszczególnych uczestników gry, kartki papieru i długopisy. Czas 89 minut potrzebny do przeprowadzenia całej rozgrywki pozwala na wygodne wkomponowanie Extreme89w typowe zajęcia akademickie. Rozgrywki Extreme89 powinny być poprzedzone wykładem wprowadzającym uczestników w zagadnienia związane z metodyką XP.

Udział w grze Extreme89 daje każdemu uczestnikowi szansę na obserwowanie zachowań partnerów oraz wybór roli, w której czuje się najlepiej.

4. Uczestnicy#

Role w grze Extreme89 stanowią paralelę do składu typowego zespołu pracującego według metodyki XP. W skład pojedynczego zespołu wchodzą:

  • Przedstawiciel klienta (zwany w skrócie klientem, 1 osoba),
  • Zespół programistów (co najmniej 2 osoby),
  • Tropiciel (1 osoba), którego praca polega na wspieraniu programistów poprzez śledzenie postępów pracy zespołu i mierzenie czasu potrzebnego na realizację pojedynczych zadań.

Grę prowadzi moderator, który odpowiada za:

  • przygotowanie materiałów stanowiących wiedzę klienta i programistów,
  • sterowanie przebiegiem gry poprzez udostępnianie kolejnych porcji informacji uczestnikom rozgrywki w odpowiednich odstępach czasu (zgodnie ze scenariuszem),
  • ostateczną weryfikację poprawności uzyskanych rozwiązań i wskazanie zwycięskiego zespołu.

5. Zasady Extreme89#

Zespoły biorące udział w grze Extreme89 powinny się składać z co najmniej 4 uczestników: 1 klienta, 1 tropiciela, co najmniej 2 programistów (por. rysunek 2). Włączenie do zespołu większej liczby uczestników umożliwia rozszerzenie grona programistów. Czas gry to 89 minut. Wszyscy członkowie zespołu zasiadają przy jednym stole stwarzając tym samym dogodne warunki do prowadzenia bezpośredniego dialogu. Zasada ta stanowi nawiązanie do jednej z praktyk XP sugerującej pracę w tzw. otwartej przestrzeni (ang. open space) ułatwiającej wzajemny kontakt [Beck2000]. W Extreme89programiści siedzą po przeciwnej stronie stołu w stosunku do klienta i oddziela ich od klienta „przegroda”, na której moderator kładzie kartki z informacjami dla obu stron. Przegroda jest tak pomyślana, że informacje przeznaczone dla klienta nie są dostępne programistom i vice versa.

fig2.png

Rys. 2. Uczestnicy gry Extreme89

5.1. Rola programistów#

Praca programistów polega na „ręcznym” obliczaniu wartości funkcji rekurencyjnych postaci:

F(a, b, 1)= a
F(a, b, 2)= b
F(a, b, n)= F(a, b, n-2) + F(a, b, n-1) div 2
dla n>2

G(a, b, 1)= a
G(a, b, 2)= b
G(a, b, n)= G(a, b, n-2) + G(a, b, n-1) div 10    dla n>2

Funkcję F można przedstawić w postaci:

F(1)= a
F(2)= b
F(n)= F(n-2) + F(n-1) div 2    dla n>2

Postać ta jest wygodniejsza do obliczeń i wyraźniej pokazuje rolę argumentów a, b(z funkcją G jest podobnie). Zaletą wcześniejszych, 3-argumentowych, definicji funkcji F i G jest łatwość wskazania parametrów a, b. Na przykład dla F(x1, x2, 5), gdzie x1=1,x2=7 mamy:

F(1)= x1 = 1
F(2)= x2 = 7
F(3)= F(1) + F(2) div 2 = 1 + 7 div 2 = 1 + 3 = 4
F(4)= F(2) + F(3) div 2 = 7 + 4 div 2 = 7 + 2 = 9
F(5)= F(3) + F(4) div 2 = 4 + 9 div 2 = 4 + 4 = 8

Poniżej podano definicje przykładowych wielkości zdefiniowanych za pomocą funkcji F i G na potrzeby gry:

papier= F(x1, x2, 18)
wkład= F(x3, x4, 18)
oprawa= F(x5, x6, 18)
pióro= wkład + F(x5, x6, 35)
sterowanie= F(x7, x8, 18)
arytmometr= F(x9, x10, 18)
procesor= arytmometr + F(x7, x8, 35)
laser= F(x11, x12, 18)
toner= F(x13, x14, 18)
drukarka= laser + F(x13, x14, 35)

Obliczając te wielkości programiści zarabiają punkty. Chodzi o zarobienie jak największej liczby punktów w ustalonym czasie (89 minut). Punktację za obliczenie poszczególnych wielkości zna klient, więc programiści z nim muszą ustalić strategię. Wartości x1, x2 itd. podaje programistom moderator prowadzący grę. Przykładowy zestaw wartości xi przedstawiono w tabeli 1.

Tabela 1. Przykładowy zestaw wartości xi wykorzystywanych w Extreme89
x1 = 2 x5 = 2 x9 = 2 x13 = 2 x17 = 2 x21 = 2 X25 = 2 x29 = 2
x2 = 3 x6 = 5 x10 = 7 x14 = 9 x18 = 11 x22 = 13 x26 = 15 x30 = 17
x3 = 2 x7 = 2 x11 = 2 x15 = 2 x19 = 2 x23 = 2 x27 = 2
x4 = 4 x8 = 6 x12 = 8 x16 = 10 x20 = 12 x24 = 14 x28 = 16

5.2. Rola klienta#

Klient wie, że praca zespołu polega na obliczaniu wartości wielkości podanych w tabeli 2. w taki sposób, aby uzyskać łącznie maksymalną liczbę punktów. Zdaje też sobie sprawę, że nie uda się jego zespołowi obliczyć w trakcie gry wszystkich wartości, zatem ważne jest dokonanie odpowiedniego wyboru. Konieczność komunikacji między programistami a klientem wynika z faktu, że programiści wiedzą jak te wartości obliczyć, ale nie znają punktacji, natomiast klient zna punktację, ale nie wie jak trudne jest obliczenie poszczególnych wartości. Punktacji podanej w tabeli klient nie może pokazywać – musi tę informację przekazać programistom w formie rozmowy.

Tabela 2. Punktacja wybranych wielkości występujących w Extreme89
Wielkość Punkty
Papier 3
Wkład 3
Oprawa 4
Pióro 24
Sterowanie 4
Arytmometr 3
Procesor 20
Laser 5
Toner 3
Drukarka 20
Komputer 100
Rys. 3. Zależności między wybranymi wielkościami w Extreme89

Wielkości są ze sobą częściowo powiązane: niekiedy, aby obliczyć jedną (np. pióro) trzeba najpierw obliczyć inną (dla pióra jest to wkład i oprawa). Zależności te klient ma przedstawione tak, jak na rysunku 3. (wielkości przedstawione na górze wymagają wcześniejszego obliczenia tych umieszczonych na dole).Klient w trakcie rozmowy ma dowiedzieć się od programistów, ile czasu zajmie im obliczenie poszczególnych wielkości i jakie wiąże się z tym ryzyko. Na tej podstawie podejmuje decyzję, które z wielkości będą obliczane w poszczególnych wydaniach.

Klient zna nie tylko punkty uzyskiwane za obliczenie poszczególnych wielkości ale także przedziały, w których powinny się mieścić wartości poszczególnych wielkości (patrz tabela 3). Jest to odpowiednik testów akceptacyjnych, które w XP są pisane „pod dyktando” klienta – jeśli system „przejdzie” testy akceptacyjne, mamy podstawy sądzić, że implementacja jest poprawna, ale zawsze może się zdarzyć defekt, który ujawni się dopiero na etapie eksploatacji. Podobnie jest w Extreme89. Klient ma tylko przedziałypoprawnych wartości. Dokładne wartości zna prowadzący grę (moderator) i on dokonuje ostatecznej oceny przedstawionych rozwiązań.

Tabela 3. Przedziały wartości wybranych wielkości
Wielkość Przedział wartości Wielkość Przedział wartości
Papier 100400 Procesor 1410015900
Wkład 150450 Laser 250800
Oprawa 170190 Toner 300330
Pióro 1250012800 Drukarka 2120022900
Sterowanie 210..230 Komputer 5400.5700
Arytmometr 200..700

5.3. Zmiany#

Zmiany są siłą napędową XP. Jeśli w przedsięwzięciu nie ma zmian, to korzyści płynące z zastosowania XP są niewielkie. Z tego względu staraliśmy się wprowadzić zmiany również do naszej gry.Zmiany mogą pochodzić z zewnątrz (od klienta – zmiana wymagań) lub z wewnątrz przedsięwzięcia (od programistów – zmiany wynikające z wykrycia defektów lub wprowadzania nowych wersji oprogramowania narzędziowego). Zmiany zewnętrzne zamodelowaliśmy w Extreme89 poprzez zmianę punktacji w trakcie realizacji gry (są trzy wersje tabeli 2, które po kolei są przekazywane klientom). Zmiany wewnętrzne są realizowane w Extreme89 jako zmieniające się wartości argumentów xi. Są trzy wersje tabeli 1, które są po kolei udostępniane programistom. Różnią się one tylko na kilku pozycjach. Zawsze jednak nowe wartości xi należą do ciągu wyznaczonego przez początkowe wartości xi. Warto więc programistom zadbać o porządek w notatkach (jest to odpowiednik standardu kodowania). Jeśli notatki z obliczeń są właściwie prowadzone, to zmiana wartości parametrów xi sprowadza się do obliczenia kilku następnych wyrazów ciągu. W przeciwnym przypadku trzeba cały ciąg liczyć od nowa.

5.4. Scenariusz gry#

Gra przebiega według ściśle określonego reżimu czasowego ujętego w formie scenariusza. Obliczanie wartości jest podzielone na 4 etapy: 2 wydania, z których każde składa się z dwóch przyrostów. Przyrost, podobnie jak w XP, ma charakter wewnętrzny i pozwala lepiej zaplanować pracę zespołu. Wydanie polega na przekazaniu zestawu obliczonych wartości do moderatora, który po pewnym czasie wskazuje, które wyniki są poprawne, a które nie. W określonych momentach moderator przekazuje uczestnikom gry nową porcję wiedzy (osobno dla klienta i programistów). Dokładny scenariusz gry przedstawiono w tabeli 4.

Tabela 4. Scenariusz gry Extreme89

Symbole występujące po lewej stronie tabeli oznaczają odpowiednio:Ważnym elementem gry Extreme89 jest silna motywacja uczestników do uzyskania jak najlepszego wyniku, albowiem mobilizuje to graczy do zaangażowania się w rozwiązywane problemy. Cel ten można osiągnąć wprowadzając element współzawodnictwa, czyli organizując zabawę dla kilku zespołów jednocześnie. Zespół, który „zarobi” największą liczbę punktów zostaje zwycięzcą.

Jeżeli we współzawodniczących ze sobą zespołach występuje różna liczba uczestników wówczas dla porównania wyników i wskazania zwycięzców należy obliczyć liczbę uzyskanych punktów przypadających na pojedynczego programistę. Porównanie tych wartości pozwala na wyłonienie laureatów konkursu.

6. Modyfikowanie gry#

Ważną cechą gry Extreme89 jest to, że można w nią zagrać wiele razy bez obawy nauczenia się jej „na pamięć”. Stałym elementem gry jest jej scenariusz, ale pozostałe parametry mogą być modyfikowane przez moderatora przed każdą edycją gry. Niestety, przygotowanie nowych definicji funkcji, opracowanie dokumentów, wyznaczenie poprawnych wyników oraz przedziałów akceptowalności dla klienta itp. wymaga trochę pracy, ale jest to wysiłek, który warto podjąć dla uatrakcyjnienia kolejnych rozgrywek zespołowych.Podstawowe parametry Extreme89, które można modyfikować to:

  • wartości argumentów xi,
  • postać funkcji rekurencyjnych definiujących poszczególne wielkości,
  • liczba punktów przyznawanych za obliczenie poszczególnych wielkości.
  • struktura powiązań między wielkościami (patrz rysunek 3).

7. Wstępne doświadczenia#

Grę Extreme89 po raz pierwszy przeprowadziliśmy w marcu 2003r. na Politechnice Poznańskiej. Uczestnikami byli studenci III, IV i V roku na kierunku Informatyka. w grze wzięło udział łącznie ponad 120 osób, które były podzielone na zespoły liczące od 4 do 6 studentów. W zespołach 4-osobowych rezygnowano z roli tropiciela.Dla studentów III roku, przygotowujących się do realizacji prac inżynierskich, był to praktycznie pierwszy kontakt z metodyką XP. Udział w grze poprzedzony był wykładem, w czasie którego omówione zostały praktyki XP. Studenci IV i V roku rekrutujący się ze specjalności Inżynieria Oprogramowania mieli już własne doświadczenia z pracy programistycznej prowadzonej zgodnie z wybranymi praktykami Programowania Ekstremalnego.

W celu wyzwolenia ducha współzawodnictwa w grupach studenckich, dla zwycięskich zespołów przewidziane były nagrody w postaci słodyczy i drobnych gadżetów komputerowych.

Udział w grze został pozytywnie oceniony przez zdecydowaną większość uczestników, którzy, w ankiecie przeprowadzonej po doświadczeniu, wśród mocnych stron gryExtreme89 podkreślali:

  • intensywność kursu Programowania Ekstremalnego,
  • możliwość zaobserwowania, jak istotną rolę odgrywa dobra komunikacja w zespole (zwłaszcza w warunkach rozdziału wiedzy klienta od wiedzy programistów), standard kodowania i praca w parach,
  • świetną zabawę.

Grupą uczestników, którzy najmniej entuzjastycznie oceniali udział w Extreme89 byli tropiciele. Osoby te wykonywały pracę pomocniczą na rzecz pozostałych członków zespołu i przez to nie czuły się równie mocno emocjonalnie zaangażowane w grę, jak programiści i klienci.

Zebrane doświadczenia skłaniają nas także do zmniejszenia złożoności poszczególnych zadań (obliczania wartości wielkości) poprzez zmniejszenie indeksów funkcji F i G (15 zamiast 18, 25 zamiast 35 itd.). Pozwoli to bardziej zdynamizować grę i zwiększyć rolę decyzji podejmowanych przez klienta.

8. Podsumowanie#

W rozdziale przedstawiona została propozycja gry symulacyjnej Extreme89, która pozwala szybko i przyjemnie przećwiczyć podstawowe zasady Programowania Ekstremalnego. Wstępne doświadczenia pokazują, że może ona stanowić istotne urozmaicenie procesu dydaktycznego.

Bibliografia#

[Beck2000] K. Beck, Extreme Programming Explained. Embrace Change,Addison-Wesley, 2000.
[Cockburn2002] A. Cockburn, Agile Software Development, Addison-Wesley, 2002.
[process2003] http://c2.com, Maj 2003, http://c2.com/cgi/wiki?ProcessMiniature.
[xhour2003] http://c2.com, Maj 2003, http://c2.com/cgi/wiki?ExtremeHour.

[#1] Praca zrealizowana w ramach projektu badawczego BW/91 394
[#2] Peter Merel nazwał swoją grę Extreme Hour. Nasza gra trwa 90 minut, więc początkowo nazwaliśmy ją Extreme90. Gdy dowiedzieliśmy się, że A. Cockburn również zaproponował grę trwającą 90 minut, skróciliśmy naszą grę do 89 minut i nazwaliśmy ją Extreme89.

©2015 e-Informatyka.pl, All rights reserved.

Built on WordPress Theme: Mediaphase Lite by ThemeFurnace.