Metodologia XP

1. Metodologia XP Husaria

2. XP – Co to takiego ? • Metodologia programowania • Paradygmat ( wzorzec ) • Forma zwinnego wytwarzania oprogramowania

3. Początki Metodologii XP • Stworzył ją Kent Beck • Powstała pod koniec lat 90-tych XX wieku • Po raz pierwszy wykorzystywana przy Chrysler Comprehensive Compensation System ( C3 ), projekt zakończył się niepowodzeniem :P • Ogromny wzrost zainteresowania metodologią na początku XXI wieku

4. XP Explained • Próba pogodzenia człowieczeństwa z produktywnością • Mechanizm dla zmian społecznych • Ścieżka do ulepszenia • Styl postępowania • Dyscyplina wytwarzania oprogramowania

5. Wartości XP • Komunikacja • Prostota • Feedback • Odwaga • Wzajemny szacunek

6. Komunikacja • Techniki szybkiego tworzenia i rozprowadzania niezbędnej wiedzy między członków zespołu • Rozpowszechnianie wizji systemu zgodnej z wizją użytkownika • Częsta komunikacja werbalna • Współdziałanie użytkowników i programistów

7. Prostota • Należy rozpoczynać od prostego systemu • Dodatkowe funkcjonalności dodawane są później • Programista skupia się na teraźniejszości • Skupianie się na przyszłości może być ryzykowne • Prosty kod i projekt jest łatwiejszy do zrozumienia • Prostota poprawia komunikację w zespole

8. Feedback • Uzyskujemy od systemu: Unit-Testy i Integration-Testy, programista widzi stan systemu po zmianach • Uzyskujemy od klienta: Testy zgodności, pisane przez klientów i testerów, dają miarodajną ocenę stanu systemu • Wreszczie od zespołu: W przypadku nowych wymagań zespół od razu może podać szacowany czas wykonania

10. Odwaga • Koduj na dziś, a nie na jutro • Komfort „refactoringu” • Usunięcia zbędnego kodu, w wypadku jego przestarzałości, bez względu na trud włożony w jego wytworzenie

11. Szacunek • Nie „psujemy” czyjegoś kodu • Nie opóźniamy kogoś w pracy • Szukamy najlepszych rozwiązań • Dążymy do uzyskania najlepszej jakości • Akceptujemy wszystkich członków zespołu • Doceniamy wszystkich członków zespołu • Motywacja i wspieranie

12. Czynności XP • Kodowanie • Testowanie • Planowanie • Projektowanie

13. Kodowanie • Kod musi spełniać uzgodnione standardy • Najpierw piszemy Unit-Testy • Kod produkcyjny pisany jest w parach • Tylko jedna para pracuje nad konkretnym kodem w tym samym czasie • Częsta integracja • Optymalizacja następuje na końcu

14. Testowanie • Każdy kod musi posiadać Unit-Testy • Każdy kod musi przejść swoje Unit-Testy • W wypadku pojawienia się błędu tworzymy następne testy • Częste wykonywanie Testów Zgodności i publikowanie ich wyników

15. Planowanie • Historyjki ( podobne do UseCase’ów), są wykorzystywane zamiast dokumentów z wymaganiami • Częste tworzenie małych release’ów • Projekt jest dzielony na iteracje • Codzienne spotkania, komunikacja • Częste zmiany par, grup itp

16. Projektowanie • Prostota • Wybieranie metafory dla systemu • Używanie Refactoringu • Używanie CRC (Class, Responsibilities, and Collaboration) • Funkcjonalności dodawane są w późniejszych etapach

17. Extreme Programming - Praktyka • 12 praktyk, które ułatwią wytwarzanie oprogramowania zgodnie z metodologią XP

18. Pair Programming • Używamy jednej klawiatury • Osobę piszącą nazywamy Driverem, skupia się na kodowaniu • Osobę oceniającą nazywamy Observerem lub Navigatorem • Łączenie typu Novice-Expert • Częste zmiany ról w parze, jak i samych par programistycznych • Wcześniej uzgodniony standard kodowania

19. Zalety Pair Programming • Jakość, mniej błędów, czytelniejszy kod, krótszy program • Redukcja kosztów, natychmiastowa poprawa błędów • Nauka i trening, przepływy wiedzy między programistami • Poprawa morali, większe zadowolenie • Przezwyciężanie trudności, łatwiejsze radzenie sobie z trudnymi problemami • Polepszenie dyscypliny, mniej czasu na inne rozrywki (naszaklasa, allegro itp.)

20. Planning Game • Główny proces planowania w XP • Spotkanie odbywające się przy każdej iteracji, zazwyczaj raz na tydzień • Panowanie podzielone jest na:Release Planning oraz Iteration Planning • Obydwie składają się z: Exploration Phase, Commitment Phase, Steering Phase

21. Release Planning - Exploration • Faza badania, poszukiwania • Uzyskanie wymagań od klienta • Napisanie historii użytkownika • Podzielenie historii • Oszacowanie potrzebnego czasu

22. Release Planning - Commitment • Faza określenia zobowiązań • Sortowanie według wartości (główne opowieści, wartość biznesowa) • Sortowanie według ryzyku • Sortowanie według przewidywanej czasochłonności • Wybieranie zakresu

23. Release Planning - Steering • Sterowanie procesem • Wprowadzanie zmian • Dostosowywanie planu • Poprawa oszacowań

24. Iteration Planning - Exploration • Przetłumaczenie wymagań na zadania • Łączenie / dzielenie zadań • Oszacowanie czasu potrzebnego na implementację zadania

25. Iteration Planning – Commitment • Akceptacja zadania przez programistów • Oszacowywanie czasu przez programistów • Balansowanie między zadaniami

26. Iteration Planning - Steering • Pobieranie karty zadania • Znajdowanie partnera • Projektowanie zadania • Pisanie Unit-Testów • Pisanie kodu • Uruchamianie testów jednostkowych • Refactoring • Uruchamianie testów funkcyjnych

28. Test driven development • Metodologia zorientowanie na testowanie • Pisanie Unit Testów ma na celu zmuszenie programistów do myślenia o możliwych nieprawidłowościach jeszcze przed napisaniem samego kodu !

29. Whole team • Metodologia XP opiera się na komunikacji między ludzkiej. • Klient rozumiany jest tu jako użytkownik aplikacji. • Ponadto klient powinien być łatwo dostępny dla programistów.

30. Continuous integration • Nieograniczony dostęp zespołów programistycznych do kodu wymusza konieczność częstego zapisywania zmian w repozytorium kodu.

31. Design improvement • W chwili, gdy zauważamy, że zmiana funkcjonalności powoduje konieczność poprawienia znacznej części kodu XP zaleca refaktoryzację. • Zmiany powinny prowadzić do prostszego i bardziej typowego kodu.

32. Small releases • Zaleca się by każda iteracja kończyła się powstaniem wykonywalnej wersji aplikacji • Podstawową korzyścią z takiego podejścia jest natychmiastowa weryfikacja postępów programistycznych przez użytkownika aplikacji • Praktyka ta minimalizuje możliwość rozminięcia się z oczekiwaniami klienta

33. Collective code ownership • Zasada ta mówi, iż każdy w równym stopniu odpowiada za całość kodu. • Programiści mają prawo modyfikować dowolną część kodu

35. Coding standard • Standard kodowania jest naturalną konsekwencją stosowania zasady wspólnej odpowiedzialności za kod • Przyjęcie wspólnego dla całego zespołu standardu ułatwia komunikację, przyspiesza przeglądanie kodu

36. Simple design • Podejście „prostsze oznacza lepsze” • Programista, który napisał fragment kodu powinien zadawać sobie pytanie: „czy daną funkcjonalność można obsłużyć łatwiej ?”

37. System metaphor • Kolejna praktyka odnosi się do nazewnictwa klas, metod, atrybutów

38. Sustainable pace • Stały postęp • Podsumowując: zmotywowani, wydajniejsi programiści+ stały kontakt z klientem+ przetestowane wersje alpha= brak nadgodzin !!! • Metodologia XP marginalizuje wpływ DeadLine’ów na obciążenie pracowników

39. Kiedy używać XP ? • Kiedy klient nie do końca zdaje sobie sprawę czego oczekuje. Częste zmiany wymagań • Ryzyko opóźnienia projektu • Niewielki zespół programistyczny (2-12 osób) • Wtedy, gdy potrzebne oprogramowanie ma się pojawić w chwili, gdy jest potrzebne :P

40. Dlaczego warto ? • Zespół tworzy harmonogram • Prostota ułatwia opanowanie projektu • Metafory upraszczają projekt • „co dwie głowy to nie jedna” • Krótka integracja • Make it run, make it right, make it fast – optymalizacja nie zawsze jest potrzebna ! • Oszczędność czasu ( Unit Testy) • Testy akceptacyjne dają poczucie stabilności