eXtreme Programming – czyli coś ekstremalnie zwinnego

1. eXtreme Programming– czyli coś ekstremalnie zwinnego Szymon Bohdanowicz

2. Treść prezentacji • Problem • Problemy spotykane przy tworzeniu systemów • eXtreme Programming (XP) • Wartości • Techniki, praktyki • Dlaczego XP działa • KorzyściXP • 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

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. 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.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% Statystyka projektów Termin dostarczenia projektu zPatterns 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 technologiiwymuszają 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 wypracowywanychprzez ś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

15. Wartości przyświecające XPnaczynia 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. ThePlanning 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) Praktyki, zwyczaje charakterystyczne dla XP

22. The Planning Game Releaseplanning(planowanie wydania,etapu): • Explorationphase(faza poszukiwań): • Spisanie oczekiwań, wymagań (user story cards) • Oszacowanie zasobów(czas, ludzie) • Podział oczekiwań, wymagań na mniejsze • Commitmentphase(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 • Steeringphase(faza sterowania): • Czas na zmiany, dostosowanie do nieoczekiwanych zdarzeń, warunków.

23. The Planning Game • Iterationplanning(planowanie cyklu): • Explorationphase(faza poszukiwań): • Przetłumaczenie kart na zadania • Połączenie/podział zadań • Oszacowanie potrzebnego czasu na zadanie • Commitmentphase(faza zaangażowania): • Wybór zadań • Programista szacuje ile czasu zajmie mu zadanie • Ustalenie czynnika obciążenia(loadfactor) • Zbilansowanie zadań(wyrównanie obciążenia) • Steeringphase(faza sterowania): • Implementacja – znalezienie partnera-> zaprojektowanie rozwiązania-> testy jednostkowe-> kodowanie -> refaktoring -> testy funkcjonalne

24. Testy • Unit Testyand 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

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

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(scopecreep)

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 • www.extremeprogramming.org • www.refactoring.com • www.pairprogramming.com