eXtreme Programming – czyli coś ekstremalnie zwinnego Szymon Bohdanowicz
Jan 06, 2016
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