EXtreme Programming

Dr Karol Grudziński

<Zawiera obszerne cytaty z książek. Do użytku wewnętrznego.>

●

Wydajne Programowane (extreme programming) to

nowe podejście do tworzenia oprogramowania oparte
o najlepsze z technik ze szczególnym
uwzględnieniem prostoty i pracy zespołowej.

●

XP to ciągłe testowanie i przeglądanie kodu oraz

zaangażowanie klienta w proces tworzenia aplikacji.
Metody XP zostały dobrze przyjęte przez
programistów, jednak ich praktykowanie wymaga
cierpliwości i jest nie lada wyzwaniem. 1

Krótko o Extreme Programming

●

Gdy programowanie komputerów było nową dziedziną,

czas procesora był bardzo cenny.

●

Było niewiele komputerów i konkurencja w zyskaniu

dostępu do sprzętu była bardzo duża.

●

Jeśli istniał błąd uniemożliwiający poprawne działanie

programu, trzeba było czekać dni albo tygodnie, by móc

sprawdzić go ponownie.

●

Dowolna zmiana programu miała wpływ na cały program.

●

Aby zaoszczędzić czas i pieniądze należało się upewnić, iż

program jest w pełni sprawny przed umieszczeniem go w

komputerze (sprawdzanie na “sucho”). Sprawdzanie kodu

zajmowało wiele godzin.

●

A więc wynikała z tego lekcja:

ZMIANA JEST TRUDNA I KOSZTOWNA!

2

●

Kilka dekad później, Extreme Programming, nazywane w skrócie XP

(wydajne programowanie), stawia wszystko na głowie, gdyż sugeruje

operację całkowicie odwrotną:

Wykonanie wysokiej jakości oprogramowania odbywa się

pomimo, a nawet dzięki ciągłym zmianom.

●

XP to sposób tworzenia oprogramowania, który kładzie nacisk na

prostotę, reakcję zwrotną, odwagę i komunikację. Stanowi w zasadzie
reakcję na przekonanie, iż zmiana jest zła i można jej uniknąć.

●

W kilku ostatnich latach tysiące programistów i firm przekonało się, że

XP pomaga im tworzyć lepsze, bardziej niezawodne oprogramowanie

przy mniejszym stresie. Koncepcje XP wpłynęły nawet na słownictwo i
narzędzia wykorzystywane poza zespołami używającymi XP.

●

Zauważyć można wzmożone zainteresowanie inżynierów

oprogramowania testowaniem i odpowiednimi do tego narzędziami.

3

●

XP jest doskonałym rozwiązaniem, ponieważ 12 jego

głównych technik polega na sobie i jest ściśle związanych.

Siła jednej z technik neutralizuje słabość innej.

●

Zrozumienie wartości wydajnego programowania i

związków między technikami umożliwia odniesienie
sukcesu.

●

XP nadaje się idealnie dla niewielkiej grupy twórców w

firmie piszącej oprogramowanie dla innej firmy –

oprogramowanie dostarcza się często, wynik prac nie jest

znany od samego początku – modyfikacje są nieuniknione.

●

XP nadaje się także w projektach, w których wiadomo, co

dokładnie należy wykonać.

●

Oczywiście kilka technik XP przydaje się w każdym

projekcie programistycznym.

4

Dlaczego Extreme Programming?

●

Wiele metod tworzenia oprogramowania zakłada, że

zmiana jest kosztowna. Błąd znaleziony w fazie
konserwacji kosztuje więcej, niż ten sam błąd

znaleziony w fazie planowania.

●

Techniki Extreme Programming (wydajne

programowanie) postulują inne stwierdzenie:

Możliwa jest minimalizacja wzrostu kosztu zmian

w czasie.

5

●

XP stara się odpowiedzieć na następujące pytania:

●

Jakiego rodzaju oprogramowanie można wykonać,
gdy ma się pełną swobodę w zmianie wymagań i
środowiska?

●

Mając wystarczającą ilość czasu i zasobów, co
można w ten sposób uzyskać?

●

Czy taki cel jest w ogóle realistyczny?

●

Jeśli tak, w jaki sposób można go uzyskać?

6

Równanie XP

●

Projektami programistycznymi można zarządzać w

kategoriach 4 zmiennych:

czasu, możliwości, zasobów i jakości.

●

Wiele projektów koncentruje się na czasie i zasobach,

zakładając, że jakość pozostanie stała. Jeżeli możliwości

kiedykolwiek się zmieniają, są typowo zwiększane (np. klient

prosi o nowe funkcje).

●

Co gorsza, czas i zasoby są często zmniejszane lub

pozostają stałe. Gdy zbliża się data wydania, często przy

projekcie pracuje mniej osób niż na początku.

●

Ostatni z parametrów, czyli jakość musi spadać! 7

●

XP sugeruje inną strategię:

●

Zespół wraz z klientem godzi się na pewien poziom

jakości.

●

Czas i zasoby ustala się jako wartości stałe.

●

Pozostaje tylko określenie możliwości:

●

Co zostanie dostarczone?

●

Kiedy zostanie dostarczone?

●

Klient ustala priorytety dla poszczególnych funkcji

systemu.

●

Praca odbywa się etapami a oprogramowanie

prawie zawsze będzie gotowe do wydania, choć nie
zawsze z pełnym zestawem funkcji.

8

●

XP zaleca regularne dostrajanie możliwości, nawet

codziennie. Każda decyzja biznesowa może wpłynąć na

projekt.

●

XP to wykorzystuje, czyniąc zmiany i ich efekty widocznymi

dla osób podejmujących decyzje biznesowe.

●

Zakładając odpowiednią komunikację w zespole, szybkie

odpowiedzi w kwestii stanu projektu i zdolność do

dostosowania możliwości, praktycy XP mogą swobodnie

zakładać dostateczną ilość zasobów. Jest to jedno z

głównych założeń XP:

Uwidocznienie zależności dotyczących zmian prowadzi
do mniejszej liczby niespodzianek i bardziej płynnego

tworzenia oprogramowania. 9

Wartości XP

●

XP składa się z czterech podstawowych

wartości:

komunikacji,
odpowiedzi na pytania (pętla zwrotna),
prostoty,
odwagi.

●

Wszystkie techniki XP wykorzystują te

podstawowe wartości.

10

Wartości XP: Komunikacja

●

Dobra komunikacja leży u podstaw każdego

projektu i umożliwia łatwe dostosowywanie się do
zmian.

●

Dzięki temu klient wie, kiedy poszczególne

funkcje systemu będą dostarczone a programiści i
analitycy wiedzą co robić.

●

Ukrywanie lub ignorowanie informacji i

nieszczerość jest często przyczyną fiaska
projektów.

●

Metodyka XP dokonuje podziału: osoby

podejmujące decyzje biznesowe zajmują się nimi
a osoby zajmujące się szczegółami technicznymi
podejmują wyłącznie decyzje techniczne. 11

●

Klient zajmuje się wyłącznie priorytetami i dyktuje

co i kiedy powinno być zrobione.

●

Wzajemne zaufanie: Analitycy ufają osobom

biznesowym w kwestiach identyfikacji funkcji i ich
priorytetów – to właśnie zarządzający znają się na
dziedzinie problemu.

●

Klient ufa twórcom oprogramowania w dziedzinie

oszacowania czasu trwania poszczególnych faz
zadań ponieważ to właśnie twórcy znają się na
technologii.

●

Każda z grup (osoby biznesowe i analitycy-

programiści) są częścią tego samego zespołu i
podejmują odpowiedzialność za swoje decyzje.
Celem zespołu jest zaspokojenie wymagań
rzeczywistego klienta.

12

●

XP, a jak to niekoniecznie bywa w przypadku tradycyjnego

procesu tworzenia oprogramowania, wymaga ciągłej

komunikacji twórców systemów z klientem.

●

Klient musi przeanalizować dostarczony przez twórców

projekt z punktu widzenia użytkownika i działalności
biznesowej.

●

Tak więc klient współdziała przy opracowaniu priorytetów i

odpowiada na pytania twórców.

●

Klient powinien codziennie widzieć postępy prac i do nich

dostosować harmonogram.

●

Klient uczestniczy w testowaniu oprogramowania już na

wczesnych etapach wytwarzania oprogramowania.

●

Usunięcie bariery komunikacyjnej prowadzi do

elastyczności.

●

Rozróżnienie decyzji biznesowych od technicznych

pomaga podejmować dobre decyzje.

●

Komunikacja jest niezbędna dla osiągnięcia celów. 13

Wartości XP: Odpowiedzi na pytania

●

Ten element XP podkreśla umiejętność zadawania pytań i

uczenie się z uzyskiwanych odpowiedzi.

●

Jedynym sposobem poznania zdania klienta jest zapytanie

go.

●

Jedynym sposobem sprawdzenia poprawności kodu jest

przetestowanie go.

●

XP kładzie nacisk na wczesne zadawanie pytań i wczesne

testowanie. XP umożliwia częste i szybkie odpowiedzi.

●

Każda z technik XP zawiera wbudowaną pętlę pytanie-

odpowiedź.

●

W celu zmniejszenia wzrostu kosztu zmian w czasie XP

zaleca słuchanie i naukę z wszystkich możliwych źródeł,

koncentrację na ciągłym planowaniu, projektowaniu,
testowaniu i komunikacji.

●

Pewne zmiany w systemie zawsze będą kosztowne ale są

tańsze, gdy są wprowadzone wcześnie (krótkie cykle pytanie-

odpowiedź.

14

●

Szybkie odpowiedzi i natychmiastowe reakcje na nie

zmniejszają nakład czasu i zasobów dla pomysłów, które
wnoszą niewiele nowego.

●

Błędy są znajdowane na przestrzeni krótkiego czasu (dni,

tygodni) a nie miesięcy czy lat.

●

Planowanie tylko do pewnego stopnia pozwala uniknąć

niektórych błędów – dopiero rzeczywiste sprawdzenie pozwala

poznać niektóre pułapki i zagrożenia.

●

Pytania i odpowiedzi ułatwiają dostosowywanie

harmonogramów i planów. Dzięki temu gdy ktoś znajdzie
problem, projekt jest natychmiast kierowany na właściwy tor z
uwzględnieniem tego problemu.

●

Częste uzyskiwanie odpowiedzi umożliwia częste

wprowadzanie poprawek i wyciąganie wniosków na ich

podstawie.

●

Zaleca się aby klient mógł uczestniczyć w projektowaniu kodu:

przeglądać funkcje w trakcie ich tworzenia – cenne uwagi klienta
– mogą wcześnie wpłynąć korzystnie na projekt.

15

●

Częste testowanie ogranicza miejsce poszukiwania

błędów do minimum.

●

Innymi podstawowymi zasadami XP są częste

demonstracje i wprowadzanie szybko
najważniejszych funkcji.

●

Czas od projektu do implementacji mierzony jest w

godzinach.

16

Wartości XP: Prostota

●

Prostota oznacza wykonanie tylko tej części

oprogramowania, która rzeczywiście musi być
wykonana.

●

XP wychodzi z założenia, że projektowanie na

zaś jest trudne i ryzykowane, przewidywalna jest
tylko najbliższa przyszłość, dlatego trzeba z
realizacją pewnych funkcji się wstrzymać.

17

Wartości XP: Odwaga

●

Odwaga oznacza konieczność podejmowania trudnych

decyzji gdy jest to niezbędne.

●

Jeżeli funkcja nie działa: naprawia się ją.

●

Jeżeli kod jest niewystarczający: ulepsza się go.

●

Informację o ewentualnym fakcie niemożliwości

przekazania wszystkich funkcji klientowi trzeba mu

natychmiast przekazać. To klient powinien zadecydować

jakimi funkcjami się najpierw zająć w przypadku gdy taka

sytuacja zajdzie.

●

Odwagę bardzo trudno wprowadzić: nikt nie chce źle

wypaść i tracić twarzy na skutek łamania obietnic.

●

Jednak jedynym sposobem odzyskania zaufania po

błędzie jest naprawienie go i przyznanie się do niego.

●

Wychodzenie na wprost wyzwaniu jakim jest tworzenie

oprogramowania zamiast unikanie go czyni

oprogramowanie lepszym.

18

Zakładanie dostatecznej ilości

czasu i zasobów

●

Tworzenie oprogramowania to nieustanny wyścig

związany z czasem i zasobami.

●

XP ma inne podejście i zakłada wystarczającą ilość

czasu na wykonanie oprogramowania.

●

XP twierdzi, że tylko zapewnienie wystarczającej

ilości czasu i zasobów prowadzi do dostarczenia
oprogramowania o satysfakcjonującej klienta jakości.

●

W XP zamiast spieszyć się z powodu zbliżającego

się terminu, praca odbywa się w normalnym tempie.
Ilość wykonywanej pracy jest zawsze stała i
dostosowuje się możliwości, by spełnić harmonogram
przy przyjętych ograniczeniach czasowych.

19

●

Wystarczająca ilość czasu na wykonanie zadań zapewnia

niewielki koszt zmian i małą liczbę popełnianych błędów.

●

Zakłada się, że klient może łatwo i tanio zmienić priorytety.

Klika technik XP czuwa nad tym by, kod był elastyczny (łatwy

do modyfikacji i rozszerzania).

●

XP stara się wykonać najlepsze oprogramowanie przy

dostępnych zasobach i czasie, zakłada się jednak, że dobrze

oszacowano ilość pracy jaką rzeczywiście da się wykonać.

●

Projekty XP mają bardzo krótkie cykle, co redukuje odstęp

czasu między projektowaniem (analizą) a wykonaniem
oprogramowania (działaniem).

●

Wprowadza się wiele mechanizmów oceny i weryfikacji na

każdym z etapów co umożliwia szybkie wprowadzanie

poprawek. Projekt prawie od razu produkuje pewne wyniki
więc daje się sprawdzić czy podąża się właściwym torem.

20

Wystarczająca ilość czasu

Wystarczająca ilość zasobów

●

XP zapewnia wystarczającą ilość zasobów w trakcie tworzenia

systemu informatycznego.

●

Liczba programistów określa liczbę pracy wykonywanej w

jednostce czasu – modyfikuje się możliwości, aby dopasować

projekt do zasobów.

●

Programiści muszą wykazać oszacowania przewidywanego

czasu trwania każdego zadania.

●

Następnie, ma miejsce poprawa tych ocen wraz z realnym

czasem spędzonym na wykonywaniu zadania. Z czasem te oceny

są tak precyzyjne, że mogą być użyte na etapie planowania.

●

Daje to możliwość klientowi utworzenia budżetu zasobów

niezbędnego na poszczególne elementy systemu. Po pewnym
czasie w projekcie nabiera się doświadczenia a więc zasoby wraz

z upływającym czasem są coraz lepiej wykorzystywane.

●

Odwrotnie niż w podejściu klasycznym, wraz z rozwojem kodu

coraz łatwiej dodawać nowe funkcje.

21

Stały koszt zmian

●

W klasycznych technikach rozwijania oprogramowania koszty

zmian z upływem czasu dramatycznie rosną. Np w modelu
kaskadowym gdzie czas, który upływa od momentu

planowania/projektowania do testowania oprogramowania
wykrycie błędów może wiązać się z powtórzeniem całego cyklu

życiowego rozwijania oprogramowania. W klasycznych modelach
cyklu życia aplikacji koszty zmian narastają.

●

XP zapewnia stały w czasie koszt zmian: dodanie nowej funkcji

będzie tak samo kosztowne za rok, jak w chwili obecnej.

●

Dzięki temu opóźnia się wprowadzenie pewnych funkcji do czasu

aż będą rzeczywiście potrzebne.

●

XP inwestuje czas i zasoby tam, gdzie oczekuje się

natychmiastowych wyników.

●

Redukuje się koszt zmian, poszukując ciągłego kontaktu z

klientem. Klient otrzymuje działającą wersję kodu, tak szybko jak
to jest możliwe, często już klika tygodni po rozpoczęciu projektu.

22

Wydajność twórców oprogramowania

●

XP stawia bardzo wysoką poprzeczkę pod względem

umiejętności programistów i projektantów.

●

Programiści często pracują w parach i dwóch programistów

pracuje nad tym samym kodem.

●

Cała baza programistyczna – projekt i implementacja – jest

otwarta na udoskonalenia.

●

XP zapewnia kilka pętli pytań i odpowiedzi na etapie kodowania

wymuszając na programistach staranność i skrupulatność. Częste
testowanie umożliwia usunięcie błędów natychmiast po ich

wykryciu.

●

Dzięki zgodzie na modyfikację poziomu możliwości przy

pozostawieniu czasu stałym unika się frustracji i przepracowania.

●

XP zakłada, że cały zespół – menadżerowie, programiści,

analitycy i klienci mają swobodę eksperymentowania.

●

Główny cel XP: wykonywanie wydajnego oprogramowania

poprzez wykonywanie naprawdę ważnych zadań.

23

Techniki XP

●

Istnieje 12 technik XP, które wzajemnie oddziałują i

wspierają się nawzajem.

●

Techniki te pomagają podejmować trafne decyzje i wykonać

oprogramowanie wysokiej jakości w przewidzianym czasie.

●

Często stosuje się tylko kilka technik, lecz stosowanie się do

wszystkich daje lepsze rezultaty.

●

Każda technika spełnia kilka zadań.

●

Wykorzystanie kilku technik bez znajomości ich

współdziałania często prowadzi do poważnych błędów.

●

Najlepszym sposobem zapewnienia dobrego

oprogramowania jest stosowanie i praktykowanie XP

●

XP nie jest uniwersalną receptą: istnieją inne techniki,

czasami wygodniejsze do specyficznych typów zadań.

●

3 grupy technik XP: kodowania, współpraca programistów,

związki między zagadnieniami technicznymi a biznesowymi.

24

Techniki kodowania

●

Pisanie kodu to jeden z najważniejszych

elementów tworzenia oprogramowania.

●

Większość czasu i energii poświęcanej

projektowi dotyczy właśnie kodu – stąd duże
zainteresowanie tym elementem tworzenia
oprogramowania ze strony XP.

●

Programiści praktykujący XP piszą najpierw kod

aby sprawdzić i ocenić swoje plany. Wiele osób
postrzega, że programiści XP piszą kod bez
żadnego planowania. Jest odwrotnie, pisanie
kodu umożliwia planowanie.

●

Cztery techniki kodowania współpracują ze sobą,

aby powstał kod prosty w utrzymaniu, elastyczny i
zawsze gotowy do dostarczenia klientowi.

25

Technika kodowania #1: proste projektowanie

i kodowanie

Cel: wykonanie oprogramowania łatwego w

modyfikacji

●

Należy wykonywać proste projekty i pisać prosty kod, który

spełnia aktualne potrzeby klienta.

●

Unika się odgadywania przyszłych potrzeb, zarówno na

etapie pisania kodu jak i projektowania.

●

Nadrzędny cel to elastyczność, prostsze projekty łatwiej

zrozumieć i nimi zarządzać.

●

Prosty kod łatwiej testować, konserwować i modyfikować.

●

XP skraca czas planowania do minimum, preferuje

spędzenie niewielkiej ilości czasu przed napisaniem kodu.

●

Projekt uwidacznia się wraz z rozbudową systemu.

●

Dla kontrastu tradycyjne podejście zakłada, że zmiany są

trudne i kosztowne więc trzeba wszystko zaplanować przed

rozpoczęciem pracy.

26

●

XP zakłada, że zmiany są nieuniknione więc plan

powinien się dostosowywać. Pracując w krótkich cyklach,

cały czas testując czy jesteśmy na właściwej drodze,

identyfikujemy błędy i szybko dostosowujemy się do

zmian.

●

Skupiamy się na prostocie i teraźniejszości, XP

przestrzega przed dodawaniem funkcji `na zaś', gdyż
każda funkcja wnosi pewien koszt, zabiera czas, zasoby i

odciąga od głównego nurtu projektu.

●

Niepotrzebne funkcje zaśmiecają i komplikują system –

chęć ich dodania wynika ze strachu, że wprowadzenie

ich w przyszłości będzie kosztowne i trudne.

●

XP uzyskuje elastyczność poprzez prostotę.

●

Zadaje się pytanie: ”Czy można uprościć kod i nadal

przejść przez odpowiednie testy”.

●

Przewidywanie przyszłości jest trudne, należy

projektować tylko to co jest aktualnie potrzebne.

27

●

Prosty projekt zapewnia:

●

wspólną odpowiedzialność za kod (z racji jego prostoty

– złożone systemy wymagają specjalizacji)

●

refaktoryzację (ponieważ w prostszym kodzie łatwiej

dostrzec niebędne do przeprowadzenia zmiany)

●

testowanie (ponieważ prostszy kod łatwiej sprawdzić).

●

Prosty projekt wymaga:

●

dobrej komunikacji między twórcami a klientem

●

pewności siebie

●

zdolności do znajdowania prostoty i chęci jej

utrzymania (czyli unikania komplikowania rzeczy, które da

się zrobić prosto).

28

Technika kodowania #2: refaktoryzacja

Cel: znalezienie optymalnego projektu kodu

●

Refaktoryzacja oznacza poprawę projektu aktualnego kodu

bez zmiany jego zachowania.

●

Refaktoryzacja poprawia istniejący kod, by stawał się

prostszy, krótszy i elastyczniejszy.

●

Refaktoryzację należy przeprowadzać regularnie zaraz po

fazie testów nowego kodu.

●

Wiele środowisk programistycznych (IDE) wyższej klasy

obsługuje podstawowe metody refaktoryzacji, które wykonuje

się automatycznie: wystarczy określić cel refaktoryzacji a

środowisko wykona niezbędne poprawki lub powróci do stanu

oryginalnego.

●

Refaktoryzacja jest o tyle ważna, że XP zachęca do

powstawania projektu na podstawie eksperymentów z kodem

a to prowadzi do powstania kodu nieeleganckiego i niskiej
jakości.

29

●

Refaktoryzacjia to eliminacja powtórzeń (duplikacji

kodu), podział długich metod i funkcji na krótsze,
uściślenie nazw metod i zmiennych, ciągłe
upraszczanie i poprawianie.

●

Celem refaktoryzacji jest uproszczenie projektu i

zmiana jedynie struktury kodu, bez wpływania na
zachowanie. Testy przed i po wykonaniu
refaktoryzacji powinny dać takie same wyniki.

●

Czasem zdarza się sytuacja, że po dłuższym czasie

spędzonym nad refaktoryzacją, zauważa się
możliwość znacznego uproszczenia architektury
systemu. Należy zapytać się klienta o zgodę na
zmiany i być gotowym na obronę swojej tezy pod
względem biznesowym.

30

●

Refaktoryzacja zapewnia:

●

prosty projekt (ponieważ zmiany są wprowadzane

regularnie)

●

dyscyplinę

●

Refaktoryzacja wymaga:

●

dyscypliny (ponieważ refaktoryzację należy

przprowadzać, gdy tylko to możliwe)

●

obiektywnych testów (aby upewnić się, że zachowanie

kodu jest takie samo przed jak i po refaktoryzacji)

●

wspólnej własności kodu (oznacza to możliowość

poprawienia dowolnego fragmentu systemu)

●

standardów kodowania (aby wykonywać zmiany w taki

sposób jak to oczekuje zespół)

31

Technika kodowania #3: opracowanie

standardów kodowania

Cel: łatwe przekazywanie pomysłów przy

użyciu kodu

●

Standardy pisania (kodowania) programów tworzy się w celu

pomocy programistom w komunikowaniu się poprzez kod. Kod to
główne narzędzie komunikacji w całym projekcie.

●

Standardy kodowania wykorzystują najlepsze praktyki

programistyczne i są to pewne konwencje w stosunku do kodu.

●

Standardy kodowania nie muszą być sztywne (obowiązujące cały

czas). Ewoluują wraz z projektem.

●

Standardy kodowania to wskazówki a nie rozkazy. Trzeba

wiedzieć kiedy stosować się do standardów a kiedy je zawiesić.

●

Standardy kodowania oszczędzają czas.

●

Niektóre projekty stosują zautomatyzowane testy czy kod spełnia

standardy kodowania.

●

Znany standard: Notacja węgierska w Microsoft opracowana

przez Charlesa Simonyi 32

●

Standardy kodowania zapewniają:

●

refaktoryzację (łatwiej zobaczyć zmiany i

zautomatyzować modyfikacje, gdy kod jest jednorodny

stylowo)

●

programowanie w parach (programiści skupiają się

na kodzie a nie na stylu)

●

wspólną własność kodu (kod zawiera elementy
wspólne dla całego zespołu a nie tylko programistów

danego kodu)

●

Standardy kodowania wymagają:

●

pracy zespołowej (w celu ustalenia wspólnych

preferencji i przyzwyczajeń)

●

okresowych sprawdzeń (aby sprawdzić czy

standardy nadal pasują do kodu po jego ewolucji)

●

programowania w parach (aby zachować - wymusić

standardy w nowo tworzonym kodzie)

33