1 / 40

Metodologia XP

Metodologia XP. Husaria. XP – Co to takiego ?. Metodologia programowania Paradygmat ( wzorzec ) Forma zwinnego wytwarzania oprogramowania. Początki Metodologii XP. Stworzył ją Kent Beck Powstała pod koniec lat 90-tych XX wieku

ziven
Download Presentation

Metodologia XP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

  18. 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.)

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

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

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

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

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

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

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

  26. 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 !

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

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

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

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

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

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

  33. 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 ?”

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

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

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

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

More Related