Metodologia XP Husaria.

Prezentacja na temat: "Metodologia XP Husaria."— Zapis prezentacji:

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

9

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

27

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

34

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