WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA

WYDZIAŁ CYBERNETYKI

WYDZIAŁ CYBERNETYKI

eXtreme Programming

eXtreme Programming

lekka metodyka wytwarzania oprogramowania

lekka metodyka wytwarzania oprogramowania

Autor: Rafał KASPRZYK

Autor: Rafał KASPRZYK

Plan prezentacji



Syndrom LOOP, Manifest zwinności



Programowanie Ekstremalne



Cztery wartości, którym hołduje XP



Podstawowe praktyki



Model procesu wytwarzania
oprogramowania wg XP



Zespół



Zalety i wady XP

Syndrom LOOP

L

O

O

P

ate
(

późno

)

oor quality (

kiepska

jakość

)

ver budget (

przekroczony

budżet

)

vertime (

nadgodziny

)

Loop

Luty 2001, Snowbird,
Utah, 17 osób

Kent Beck (

karty CRC,

xUnit, XP

)

Alistair Cockburn (

rodzina

metodyk Crystal

)

Marin Fowler (

refaktoryzacja,

UML Distilled

)

Jim Highsmith (

Adaptive Software

Development

)

Manifest zwinności

Manifest zwinności

• Jednostki i interakcje niż procesy i
narzędzia

• Działające oprogramowanie niż
obszerna dokumentacja

• Współpraca klienta niż negocjacja
kontraktu

•

Nadążanie za zmianami

Nadążanie za zmianami

niż trzymanie się

niż trzymanie się

planu

planu

Ważniej

sze:

eXtreme Programming

(1/2)



nowa tzw. lekka (ang. lighweight lub agile)
metodyka wytwarzania oprogramowania



opiera się na zbiorze zasad i sugestii, które
powinny być praktykowane



programowanie wraz z powstałym w jego wyniku
kodem są najważniejsze, kod jest zawsze
jednoznacznym i formalnym opisem systemu



dąży do poprawy jakości kodu



dyscyplina programowania, dyscyplina pracy
grupowej oraz dyscyplina pracy z klientem

eXtreme Programming

(2/2)



Ekstremalne potraktowanie pewnych znanych
od dawna zasad o których wiadomo, że są
dobre, sprawdzone i skuteczne:



weryfikacja kodu



testowanie



iteracyjne tworzenie małych wydań



Prostota

zasady te muszą być stosowane w sposób ciągły



„…skuteczny, bezpieczny, elastyczny, naukowy
i przyjemny sposób programowani” (Kent Beck)

XP

kontra inne metodyki



Wczesne, konkretne i ciągłe informacje zwrotne w
krótkich cyklach programowania



Planowanie przyrostowe



Zdolność do elastycznego projektowania i
implementacji funkcjonalności w zależności od
dynamicznie zmieniających się wymagań



Opieranie się na komunikacji słownej i kodzie
źródłowym oprogramowania w celu przekazania
intencji programistów i klientów



Zapewnienie bliskiej współpracy programistów



Promowanie prostoty rozwiązań i iteracyjnego
procesu poprawy zaimplemetowanych rozwiązań

Wartości i praktyki

XP

Na XP składają się 4 wartości, którym hołduje: komunikacja,
prostota, informacja zwrotna i odwaga, a także 12 praktyk: gra
planistyczna, krótkie okresy wydania kolejnych wersji, metafora,
prosty projekt systemu, testowanie przed kodowaniem,
refaktoryzacja, programowanie w parach, współwłasność kodu,
ciągła integracja, brak nadgodzin, udział klienta w zespole i
standard kodowania.
Wspomniane

wartości opisują cel

wartości 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.

Praktyki stanowią implementację podanych wartości

Praktyki stanowią implementację podanych wartości. Są
one ze sobą ściśle związane i wspólnie realizują założone cele. By
można powiedzieć, że w pełni realizuje się metodykę XP należy
stosować wszystkie 12 praktyk.

4 wartości

XP



Komunikacja

Ścisła, bezpośrednia współpraca wewnątrz zespołu i zespołu z klientem



Prostota

Poszukiwanie najprostrzego rozwiązania spełniającego wyznaczone

założenia. „Konstruktor wie, iż osiągną doskonałość nie wtedy, gdy nic

już nie można dodać, lecz wtedy, gdy już nic nie da się ująć.”



Informacja zwrotna

Szybkie iteracje i bezpośredni kontakt umożliwiają uzyskanie niemalże

natychmiastowych informacji na temat stanu projektu i aktualnie

istniejących zagrożeń



Odwaga

Szybkie podejmowanie decyzji w oparciu o zebrane informacje,

agresywne i zachęcające podejście do zmian mogących wpłynąć na

jakość, termin i koszt oprogramowania wspierane przez pozostałe trzy

wartości

Praktyki

XP



Praktyki wspierające wartości XP podzielone

zostały na następujące obszary:



Planowanie



Projektowanie



Kodowanie



Testowanie



W odróżnieniu od innych metodyk XP nie ma

wyraźnego podziału na fazy, w których

realizowane są zadania z poszczególnych

obszarów tzn. planujemy, projektujemy,

implemetujemy i testujemy przez cały czas

Planowanie i definicja
wymagań

W Programowaniu Ekstremalnym planuje się tylko najbliższą przyszłość –

jeden przyrost funkcjonalności lub jedno wydanie. XP wyraża przekonanie,
że im odleglejsze plany, tym mniej są one prawdopodobne. Dlatego
ważniejsze jest precyzyjne planowanie krótkoterminowe niż obarczone
dużym błędem prognozy w dalszym horyzoncie czasowym. Trzy praktyki,
które znajdują się w tej grupie, są bardzo charakterystyczne dla XP.



Gra planistyczna – technika planowania i negocjacji. Podstawowym jej

celem jest oszacowanie każdej pojedynczej historii użytkownika, czyli
poszczególnych zadań jakie ma realizować cały system. 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



Metafora systemu - nieformalnym opisem systemu, jego zachowania i

środowiska w którym będzie pracował. Jej głównym odbiorcą jest klient, dla
którego powinna być zrozumiała. Metaforę tworzą wspólnie wszyscy
uczestnicy przedsięwzięcia. Stanowi ona pomost między klientem i
programistami



Udział klienta w zespole - możliwość konsultacji z klientem „na żywo”

Projektowanie

Projekt powstaje tuż przed kodowaniem i powinien

obejmować tylko tę funkcjonalność, która właśnie ma
zostać zaimplementowana. Kod programu jest także
jedynym dokumentem projektowym.



Prosty projekt – należy zawsze stosować rozwiązanie
najprostrze z możliwych. Zakłada się, że wymagania klienta,
rynku i sytuacji w branży ciągle się zmieniają. Należy więc jak
najszybciej osiągnąć satysfakcję 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żeli klient chce
dodać nową funkcjonalność musi dodać nową historię, jej koszt i
pozycja na liście ważności ustalana jest w wyniku kolejnej gry
planistycznej

Kodowanie (1/2)

Kodowanie jest najważniejszą czynnością w XP. Dotychczas, w

miarę rozwoju klasycznych metod inżynierii oprogramowania,

było ono stopniowo zaniedbywane. XP wraca do źródeł. To w

trakcie programowania powstają jedyne udokumentowane

artefakty (kod i przypadki testowe). Dlatego największa liczba

praktyk dotyczy właśnie programowania.



Małe wydania – wydanie to działający produkt realizujący określone

funkcje. W kolejnych wydaniach funkcjonalność jest rozwijana i

uzupełniana aż do osiągnięcia stanu docelowego. Małe wydania to

częste akceptacje powstającego systemu przez klienta. Zawsze istnieje

sprawnie działająca wersja, a klient nie musi długo czekać na kolejną



Standard kodowania – powinien być ustalony przez całą grupę. Jeśli

ktoś nie chce się zgodzić ze swojego przyzwyczajenia, a grupa nie może

zaakceptować jego propozycji, nie może uczestniczyć w projektach

realizowanych przy pomocy XP. Samych komentarzy w kodzie powinno

być niewiele. Klasy powinny być tak zaprojektowane by przeznaczenie

poszczególnych metod było jednoznaczne, a działanie oczywiste

Kodowanie (2/2)



Refaktoryzacja – zmiana struktury kodu bez zmiany realizowanej przez

niego funkcjonalności. Stosuje się ją wówczas, gdy dodawanie kolejnych

funkcji staje się coraz trudniejsze. Opiera się na wzorcach projektowych.

Warunkiem skutecznego przeprowadzania refaktoryzacji jest ponowne

przetestowanie działania kodu po dokonaniu zmian.



Współwłasność kodu – wspólna odpowiedzialność za powstały kod. Jeśli

trzeba coś zmodyfikować to nie ma problemu bo każdy jest w stanie tego

dokonać. Uniezależnienie od fluktuacji pracowników, poczucie efektu synergii

oraz integracja zespołu to kolejne plusy



Ciągła integracja – najczęściej stosuje się oddzielną maszynę, na której w

danej chwili może pracować jedna osoba zajmująca się łączenie kodu. Ciągłe

łączenie jest ułatwione dzięki prostym projektom, ciągłym testom i wspólnej

odpowiedzialności za kod.



Programowanie w parach – podczas gdy jedna osoba „trzyma klawiaturę”,

druga na bieżąco go sprawdza, sugeruje możliwe rozwiązania, może służyć

pomocą i zwraca uwagę na błędy. Dobrze jeżeli pary między sobą się

zmieniają oraz programiście wewnątrz pary, co pomaga propagować wiedzę

o różnych fragmentach programu na całą grupę



Brak nadgodzin – zespół powinien być przyzwyczajony do stałej wydajności

i stałego obciążenia. XP wymaga powtarzalności i regularności. Ponadto XP

kładzie duży nacisk na umotywowanie programistów, którzy muszą być

świadomi celu oraz metod jego osiągnięcia oraz czują się

współodpowiedzialni

Zawsze to mówiłem

Testowanie



Ciągłe testowanie - Programowanie Ekstremalne

przewiduje dwa rodzaje testów: jednostkowe i

funkcjonalne. Testy funkcjonalne służą stwierdzeniu, czy

funkcjonalność wymagana przez klienta została

zaimplementowana poprawnie. Testy jednostkowe są

pisane i wykonywane przez programistów w celu

stwierdzenia, czy dany fragment kodu daje poprawne

wyniki. Testowanie powinno być procesem ciągłym. Nie

powinno się pisać żadnego kodu, dopóki nie wie się, jak

go przetestować. Programista jeszcze przed napisaniem

kodu realizującego daną funkcję, ma obowiązek

przygotować zestaw testów jednostkowych.

Zaprojektowane przypadki testowe powinny być

utrzymywane (tzn. powiązane z zaimplementowanymi

opowieściami użytkownika) i uruchamiane za każdym

razem, gdy następuje integracja nowych funkcji z

systemem.

Error

Model procesu
wytwarzania

Pojedyncza iteracja

Kodowanie (1/2)

Kodowanie (2/2)

Kluczowe praktyki

Udział klienta w zespole Programowanie parami

Refaktoryzacja

Ciągła integracja

Ciągłe testowanie

Zespół

XP



Programista – celem jego pracy jest stworzenie oprogramowania. Bierze on czynny udział w procesie

projektowania oraz sterowania wykonaniem. Musi mieć świadomość pracy w zespole, w którym jest

współodpowiedzialny za powstający system. 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 zdolność łatwego

komunikowania się i nawyk prostoty.



Klient - zajmuje szczególnie ważne miejsce. Bierze on udział przy projektowaniu (gry planistyczne) oraz przy

testowaniu (testy akceptacyjne). Ponadto kontroluje wykonanie aplikacji (choć nie może nim sterować) i podejmuje

decyzje o kolejności realizacji modułów. W czasie realizacji projektu może okazać się potrzebny by rozstrzygać

kwestie sporne i wyjaśniać problemy.



Tester - Spełnia funkcję kontrolną wobec programisty, ale nie na zasadzie ustawiania się w opozycji do niego. Jego

zadanie jest regularne uruchamianie testów i publiczne ogłaszanie ich wyników.



Konsultant – czasem potrzebna jest określona wiedza specjalistyczna. Zespół nie powinien wtedy 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.



Trener – musi utrzymać zespół na właściwej drodze do rozwiązania. Aby to zrobić musi posiadać doświadczenie,

musi głęboko rozumieć istotę XP i potrafić dobrze nim sterować. Często trener musi być dostępny jako partner do

programowania dla mniej doświadczonych.



Zarządca – jest odpowiedzialny za właściwe szacowanie. 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ć.



Szef - ma prawo wymagać rzetelnej komunikacji z zespołem. Jeśli coś idzie nie tak powinien być natychmiast

poinformowany. Może wtedy zaproponować pewne rozwiązania, ale nie ma władzy nad terminarzem projektu. To

zespół określa warunki realizacji na podstawie środków zapewnionych przez szefa. Zespół ma prawo oczekiwać od

szefa odwagi, zaufania, zrozumienia i szybkich, kompetentnych decyzji.

W Ekstreme Programming zespół jest wspólnotą ludzi, którzy razem dążą do

celu. Ważne jest, aby wzajemnie się rozumieli i mieli silne poczucie więzi. W
zespole oprócz programistów są też inne osoby, odpowiedzialne za
zarządzanie oraz pomagające rozwiązywać szczególnie trudne problemy.

Kiedy nie należy stosować

XP



Jeżeli wykorzystywana metodyka umożliwia produkcję

oprogramowania w sposób satysfakcjonujący Klientów i

członków grupy projektowej



Klient żąda dokumentacji w postaci jaką dają tzw. „ciężkie

metodyki”



W bardzo dużych zespołach



Gdy programiści nie są na tyle dojrzali by móc oddać w ich

ręce władzę nad sterowaniem projektem



Programiści nie czują się dobrze gdy ktoś im „patrzy na ręce”



W przypadku gdy wymagania nie ulegają zmianie



Brak uzyskania szybko informacji zwrotnej na temat

dostarczanych w ramach wydań kolejnych wersji

projektowanego systemu

Jak rozwiązać te problemy

i zachować zwinność?

Kiedy należy stosować

XP



Wymagania dotyczące systemu nie są

ustabilizowane i mogą ulegać częstym zmianom

(nawet po dostarczeniu i wdrożeniu systemu)



Istniejąca grupa programistów składa się z z

programistów o wysokich umiejętnościach



Wymagana jest większa efektywność pracy zespołu

projektowego



Działający system ma większe znaczenie niż jego

dokumentacja

W każdym innym przypadku niż przedstawione

na poprzednim slajdzie, a w szczególności gdy:

Tom

Tom

DeMarco

DeMarco

„XP jest

dzisiaj

najważniejszy

m ruchem w

IT."

Pytania

Error