eXtreme Programming – czyli coś ekstremalnie zwinnego

Prezentacja na temat: "eXtreme Programming – czyli coś ekstremalnie zwinnego"— Zapis prezentacji:

1 eXtreme Programming – czyli coś ekstremalnie zwinnego
Szymon Bohdanowicz

2 Treść prezentacji Problem eXtreme Programming (XP) Wnioski
Problemy spotykane przy tworzeniu systemów eXtreme Programming (XP) Wartości Techniki, praktyki Dlaczego XP działa Korzyści XP Wnioski

3 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 eg. Netscape 6 No communication after requirements analysis, or, Business needs changes Time pressure, quality sacrificed for short-term speed gain Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes System delivered, works, but complex and/or fragile

4 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

5 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

6 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

7 z Patterns of Software Systems Failure and Success, Capers Jones
Statystyka projektów Wielkość 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 6.06% 74.77% 11.83% 7.33% 1,000 1.24% 60.76% 17.67% 20.33% 10,000 0.14% 28.00% 23.83% 48.00% 100,000 0.00% 13.67% 21.33% 65.00% Średnia 5.53% 56.94% 13.71% 23.82% Termin dostarczenia projektu Todo: function point z Patterns of Software Systems Failure and Success, Capers Jones

8 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)

9 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

10 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

11 Economics of software development

12 Co jeśli…

13 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.

14 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 Take practices that have been proven to be good and take them to the extreme.

15 Wartości przyświecające XP naczynia powiązane
Komunikacja/kontakt/współpraca Prostota/klarowność/czytelność Informacja zwrotna(and. feedback) Odwaga Szacunek

16 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

17 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.

18 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

19 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.

20 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.

21 Praktyki, zwyczaje charakterystyczne dla XP
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 Game* Krótki cykle(inkrementy) Metafora systemu (wspólne wyobrażenie) Prostota projektowania* Testy* Refaktoring* Programowanie w parach*

22 The Planning Game Release 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. Big subject: will gloss over it Release planning & iteration planning

23 The Planning Game Iteration 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

24 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

25 Testy jednostkowe(Unit Tests)

26 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

27 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 (Alistair Cockburn & Laurie Williams) Partner is a safety net: changing the system is not scary

28 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

29 Refactoring Projektowanie staje się dla każdego codzienną czynnością
Ciągła praca nad udoskonalaniem kodu Testy jednostkowe i programowanie w parach dodają odwagi Rezultaty: Szybkie tempo rozwoju systemu Kod staje się elastyczny, łatwy do zmiany

30 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

31 Kto zyskuje na XP? Programiści\deweloperzy: Klienci:
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

32 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

33 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)

34 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ń

35 Dodatkowe materiały www.junit.org www.xprogramming.com