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

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

Wartości XP Komunikacja Prostota Feedback Odwaga Wzajemny szacunek

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

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

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

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

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

Czynności XP Kodowanie Testowanie Planowanie Projektowanie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 !

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.

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

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.

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

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

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

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

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

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

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

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