eXtreme Programming – czyli coś ekstremalnie zwinnego

Szymon Bohdanowicz

Treść prezentacji

• Problem– Problemy spotykane przy tworzeniu systemów

• eXtreme Programming (XP)– Wartości– Techniki, praktyki– Dlaczego XP działa– Korzyści XP

• Wnioski

Podstawowe problemy napotykane w czasie produkcji oprogramowania

Zagrożenia:• Niedotrzymanie terminów• Niezrozumienie modelu biznesowego• Wysoki poziom błędów• Wstrzymanie projektu• Starzenie się systemu• Zmiana w modelu biznesowym klienta

Problem z terminowością

• Wiele projektów nie kończy się w ustalony terminie– Przykład : Diablo 2, systemy dla ZUS

• Niektórych deadline’ów nie można przesunąć– Przykład: systemy na Euro 2012

• Co jeśli: uda nam się jednak dostarczyć główne funkcjonalności na czas

Problem z rozpoznaniem realnych potrzeb klienta(modelu biznesowego)

• Bez bezpośredniej komunikacji z klientem programista/deweloper może tylko zgadywać co powinien wyprodukować(nie mówiąc o tym, że klient na ogół nie ma pojęcia czego chce)– Przykład: Systemy audytowe

• Co jeśli: klient będzie w stanie przekazać swe oczekiwania dotyczące systemu

Problem z awaryjnością systemu

• System został sprzedany, wprowadzony do użytku jednak jego jakość uniemożliwia efektywne wykorzystanie.

• Co jeśli: udało się zautomatyzować testy

Statystyka projektówWielkość projektu

(w punktach funkcjonalności) Przed terminem Na czas Opóźniony Zakończony fiaskiem Suma

1 14.68% 83.16% 1.92% 0.25% 100.00%10 11.08% 81.25% 5.67% 2.00% 100.00%

100 6.06% 74.77% 11.83% 7.33% 100.00%1,000 1.24% 60.76% 17.67% 20.33% 100.00%

10,000 0.14% 28.00% 23.83% 48.00% 100.00%100,000 0.00% 13.67% 21.33% 65.00% 100.00%Średnia 5.53% 56.94% 13.71% 23.82% 100.00%

z Patterns of Software Systems Failure and Success, Capers Jones

Termin dostarczenia projektu

Problem – projekt zawieszony/zamknięty

• Co jeśli: krótkie cykle produkcyjne(inkrementy) umożliwiają dostarczenie przynajmniej częściowo działającego oprogramowania (zainwestowane pieniądze mają odzwierciedlenia w dostarczonym produkcie)

Problem starzenia się systemu

• Software jest wykorzystywany, działa prawidłowo, jednak z czasem koszt jego modernizacji, wprowadzenia poprawek jest bardzo wysoki – tańsza okazuje się produkcja nowej aplikacji niż utrzymywania dotychczasowej.

• Co jeśli: kod jest czysty, klarowny a projekt czytelny

Problem zmieniającego się świata – wraz z nim wymagań wobec systemu

• Zmiany w prawie, nowe warunki rynkowe, rozwój technologii wymuszają modyfikacje modelu biznesowego klienta

• Co jeśli: klient może się rozmyślić, zmienić zdanie definiując inne funkcjonalności, określić na nowo priorytety

Economics of software development

Specyfikacjawymagań

Analiza Projekt Implementacja Testy Produkcja

koszty zmian

Co jeśli…

Czas

koszt zmian

eXtreme Programming

• Zbiór technik, praktyk wypracowywanych przez środowisko deweloperów/programistów softwarowych, które mają na celu szybką produkcję oprogramowania wysokiej jakości, łatwo dostosowującego się do zmian w wymaganiach.

eXtreme…

Nadanie sprawdzonym rozwiązaniom charakteru ekstremalnego

• Testowanie jest dobre - niech wszyscy ciągle testują• Ocenianie kodu jest dobre – prowadźmy ciągłą ocenę• Projektowanie jest dobre - niech wszyscy projektują

(udoskonalają system - refaktoring)• Testy integracyjne są dobre – integrujmy bez przerwy• Prostota jest dobra - wybierajmy najprostsze

możliwe rozwiązania• Krótkie cykle są dobre – zróbmy je naprawdę bardzo

krótkimi

Wartości przyświecające XPnaczynia powiązane

• Komunikacja/kontakt/współpraca• Prostota/klarowność/czytelność• Informacja zwrotna(and. feedback)• Odwaga• Szacunek

Komunikacja

• Kontakt pomiędzy klientem a twórcami systemu jest kluczem do sukcesu

• Klient powinien być w pełni dyspozycyjny• Komunikacja i współpraca wewnątrz zespołu

nie powinna napotykać jakichkolwiek barier

Prostota

• Skupienie się na głównych celach – proste rozwiązania – optymalizacja, dodatkowe funkcjonalności dodawane później.

• Realizacja potrzeb tylko dzisiejszych -YAGNI• Dzięki prostocie kod może być łatwo

rozumiany przez innych.

Feedback – informacja zwrotna

• Informacja zwrotna z systemu – dzięki testom jednostkowym system natychmiast udziela odpowiedzi dotyczącej jego stanu

• Informacja zwrotna od klienta – testy akceptacyjne (pisane wspólnie przez klienta i programistę) mówią o poziomie spełaniania wymagań

• Informacja zwrotna od zespołu – w sytuacji gdy klient przedstawia nowe wymagania, oczekiwania zespół natychmiastowo szacuje zasoby, które muszą być zaangażowane

Odwaga

• Przy refaktoringu – jeśli uważasz, że coś można poprawić zrób to!

• Przy usuwaniu fragmentów przestarzałych – jeśli uważasz część aplikacji za zbędną, przestarzałą usuń ją(nieważne jak wiele pracy ona pochłonęła)

• Przy rozwiązywaniu skomplikowanych problemów – jeśli pracujesz nad czymś długo bądź wytrwały, nie rezygnuj.

Szacunek(wobec siebie i innych)

• Programista nie powinien dodawać(commit) kodu, który nie przechodzi kompilacji, sypie się na testach lub utrudni pracę innym.

• Wzajemne szanowanie własnej pracy polega na ciągłym refaktoringu(doskonaleniu) kodu.

Praktyki, zwyczaje charakterystyczne dla XP

• The Planning Game*• Krótki cykle(inkrementy)• Metafora systemu

(wspólne wyobrażenie)• Prostota projektowania*• Testy*• Refaktoring*• Programowanie w

parach*

• Wspólnota własność kodu• Ciągła integracja systemu• 40 godzinny tydzień pracy• Pełny dostęp do klienta• Standardy

kodowania/projektowania• Otwarta przestrzeń

pracy(openspace)

The Planning GameRelease planning(planowanie wydania,etapu):• Exploration phase(faza poszukiwań):

– Spisanie oczekiwań, wymagań (user story cards)– Oszacowanie zasobów(czas, ludzie)– Podział oczekiwań, wymagań na mniejsze

• Commitment phase(faza zaangażowania):– Sortowanie wymagań wg wartości(krytyczne, istotne, przydatne)– Sortowanie wg ryzyka(niskie, średnie, wysokie; kompletność,

zmienność, skomplikowanie)– Oszacowanie prędkości, możliwego tempa pracy– Wybór zakresu

• Steering phase(faza sterowania):– Czas na zmiany, dostosowanie do nieoczekiwanych zdarzeń,

warunków.

The Planning GameIteration planning(planowanie cyklu):• Exploration phase(faza poszukiwań):

– Przetłumaczenie kart na zadania– Połączenie/podział zadań– Oszacowanie potrzebnego czasu na zadanie

• Commitment phase(faza zaangażowania):– Wybór zadań– Programista szacuje ile czasu zajmie mu zadanie– Ustalenie czynnika obciążenia(load factor)– Zbilansowanie zadań(wyrównanie obciążenia)

• Steering phase(faza sterowania):– Implementacja – znalezienie partnera->

zaprojektowanie rozwiązania-> testy jednostkowe-> kodowanie -> refaktoring -> testy funkcjonalne

Testy

• Unit Testy and Functional Tests• Troszkę testuj, troszkę koduj(Test a little, code

a little…)– “Test-first programming”

• Testy stają się wyznacznikiem wymagań• Testy nadają systemowi stabilność• Testy dodają programistom odwagi w

momencie wprowadzania zmian

Testy jednostkowe(Unit Tests)

Programowanie w parach

• Dwie osoby siedzą przed jednym komputerem, jedna klawiatura, jedna myszka.

• Każdy ma swoją rolę: jeden koder/programista, jeden projektant/deweloper

• Cały kod implementacji jest pisany w parach

Zalety programowania w parach

• 15% mniej kodu niż w przypadku dwóch niezależnych programistów

• Ciągła weryfikacja, ocena kodu: lepsza jakość, mniej błędów

• Większa pewność, gotowość do wprowadzania zmian, nowych funkcjonalności

• Utrzymanie zwyczaju ciągłych testów i rekatoringu• Wzajemna wymiana poglądów, spostrzeżeń dotyczących

działania systemu• Nauka nowych umiejętności od partnera

Prostota w projektowaniu

Twórz/projektuj kod najprostszymi i najszybszymi sposobami

• Kod przejdzie większość testów• Brak powtórzeń w kodzie(usunięcie redundancji)• States every intention• Mniej klas i metod

Refactoring

• Projektowanie staje się dla każdego codzienną czynnością

• Ciągła praca nad udoskonalaniem kodu• Testy jednostkowe i programowanie w parach dodają

odwagiRezultaty:• Szybkie tempo rozwoju systemu• Kod staje się elastyczny, łatwy do zmiany

Jak/Dlaczego XP działa?!

• Lekkość: solidność bez biurokracji• Pod presją ludzie wybierają rozwiązania

najprostsze:– All XP practices have short-term benefits as well as

long-term benefits• Rozwój jako forma/rezultat komunikacji• Kod jest dokumentacją(jak to możliwe? –

standardy kodowania)• XP dostarcza dużo radości

Kto zyskuje na XP?

• Dostają klarowny, czysty zestaw wymagań i priorytetów

• can do a good job• Mogą podejmować

decyzje techniczne i projektowe

• Nie muszą wyrabiać nadgodzin

• get most business value first

• Dostają czytelną informację zwrotną

• can make informed business decisions

• Mogą zmieniać zdanie

Programiści\deweloperzy: Klienci:

Wnioski

• W jakich sytuacjach warto zdecydować się na prowadzenie projektu wg XP:– gdy system tworzony jest dla obszaru

podlegającego ciągłym zmianom, funkcjonalności są trudne do sprecyzowania

– gdy mamy do dyspozycji małe zespoły pracowników

• XP jest nastawione na prędkość• XP dostarcza dużo radości

Zarzuty wobec XP

• Bardzo kosztowny dla klientów(zasada pełnej dostępności)• Brak dokumentacji, całościowego projektu• Wiąże się z całkowita zmianą względem tradycyjnej

kultury pracy• W XP muszą być zaangażowanie doświadczenie, dobrzy

programiści /deweloperzy• Jako, że skupia się na funkcjonalnościach trudno jest

przekazać oczekiwanie nie związane bezpośrednio z nimi(user story cards)

• Może prowadzić do niekontrolowanego rozrostu projektu(scope creep)

Zarzuty wobec XP• Niemożliwym w zasadzie jest realne oszacowanie

zasobów dla realizacji całego projektu(skoro na początku nic nie wiadomo – wszystko się może zmienić w trakcie)

• Bez pełnego zaangażowania sukces nie jest możliwy• Ciągła zmiana oczekiwań może prowadzić do

bezustannego przeprogramowywania jednego obszaru – nie jest brane podczas szacunków, tworzenia harmonogramu

• Negocjacje kontraktowe z klientem są niezwykle trudne• Kolejne deliwerable nie są jasno określane – może

prowadzić do nadużyć, wyłudzeń

Dodatkowe materiały

• www.junit.org• www.xprogramming.com• www.extremeprogramming.org• www.refactoring.com• www.pairprogramming.com