Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "Metodologia XP Husaria. XP – Co to takiego ? Metodologia programowania Paradygmat ( wzorzec ) Forma zwinnego wytwarzania oprogramowania."— 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 s zacunek

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 o d systemu: Unit-Testy i Integration-Testy, programista widzi stan systemu po zmianach Uzyskujemy o d klienta: Testy zgodności, pisane przez klientów i testerów, dają miarodajną ocenę stanu systemu Wreszczie o d 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 U sunię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ęst e z miany 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łada ją 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łówn e opowieści, wartość biznesowa) Sortowanie według ryzyku Sortowanie według przewidywanej czasochłonności Wybieranie zakresu

23 Release Planning - Steering Sterowanie proces em 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


Pobierz ppt "Metodologia XP Husaria. XP – Co to takiego ? Metodologia programowania Paradygmat ( wzorzec ) Forma zwinnego wytwarzania oprogramowania."

Podobne prezentacje


Reklamy Google