Autor: Tomasz Karczy ń ski Zaj ę cia: Zarz ą dzanie Projektami Prowadz ą cy: prof. Dorota Kuchta eXtream Programming

Czym jest metodyka XP to styl tworzenia oprogramowania, który zakłada maksymalizacj ę zysków wynikaj ą cych z zastosowania zaawansowanych technik programistycznych, komunikacji i pracy w zespole Jest prób ą pogodzenia człowiecze ń stwa z produktywno ś ci ą. Koncentruje si ę na 3 fundamentalnych poj ę ciach: Warto ś ci Zasady Praktyki 2/17

Metodyka XP – wartości Komunikacja Ułatwienie szybkiego tworzenia i rozprowadzenia niezb ę dnej wiedzy w zespole; Rozpowszechnianie w zespole wizji systemu zgodnej z wizj ą u ż ytkownika; Bazowanie na komunikacji werbalnej; Umo ż liwianie bliskiej współpracy programistów z u ż ytkownikami. Prostota Skupianie si ę na dalekiej przyszło ś ci jest ryzykowne - zespół skupia si ę na tera ź niejszo ś ci; Poprawianie komunikacji w zespole od pocz ą tku do ko ń ca projektu. 3/17

Metodyka XP – wartości Feedback Wprowadzenie testów jednostkowych i integracyjnych pozwala za sprawniejsze zarz ą dzanie zmianami; Ocena systemu dzi ę ki testom zgodno ś ci pisanymi przez klienta; Estymacja czasu wykonania nowych wymaga ń. Odwaga Zachowanie zasady: Koduj na dzi ś a nie na jutro, Brak obaw przed zmian ą struktur aplikacji; Usuwanie przestarzałego kodu. 4/17

Metodyka XP – wartości Szacunek Ka ż dy członek zespołu jest odpowiedzialny za własny kod; Zespół wzajemnie wypracowuje najlepsze rozwi ą zania; Kluczem jest jako ść pisanego kodu aplikacji; Ka ż dy członek zespołu jest akceptowany i doceniany; Fundamentem jest motywacja i wzajemne wsparcie. 5/17

Metodyka XP – czynności Kodowanie Kod musi spełnia ć uzgodnione standardy; Przed napisaniem nowej funkcjonalno ś ci pisane s ą testy jednostkowe; Kod pisany jest w parach, ka ż da z par pracuje w danym momencie nad innym fragmentem aplikacji; Optymalizacja jest wykonywana na ko ń cu prac nad dan ą funkcjonalno ś ci ą. Testowanie Ka ż dy kod musi posiada ć testy jednostkowe; Pojawienie si ę bł ę du skutkuje rozszerzeniem testów jednostkowych; Testy zgodno ś ci wykonywane s ą cz ę sto, a ich wyniki s ą publikowane. 6/17

Metodyka XP – czynności Planowanie Zamiast dokumentacji - zestaw historyjek u ż ytkownika; Projekt dzieli si ę na krótkie iteracje; Przynajmniej raz dziennie zespół spotyka si ę i wymienia problemami, obserwacjami, … Cz ę ste zmiany par; Maksymalne skrócenie czasu dostarczenia nowego oprogramowania klientowi. Projektowanie Prostota; Cz ę ste zmiany struktury kodu; Najpierw to, co musi by ć - nowe funkcje dodawane s ą w pó ź niejszym terminie. 7/17

Metodyka XP – praktyki Programowanie w parach Para u ż ywa jednej klawiatury - Driver pisze, Observer ocenia; Cz ę ste zmiany ról w parze; Ł ą czenie typu nowicjusz – ekspert; Kod musi spełnia ć standardy. Planowanie jako gra Obywa si ę przy ka ż dej z iteracji; Planowanie zarówno wydania, jak i pojedynczej iteracji. 8/17

Metodyka XP – praktyki Planowanie wydania - eksploracja Zebranie wymaga ń klienta; Napisanie historii u ż ytkownika; Estymacja czasu potrzebnego na wykonanie; Podział historii. Planowanie wydania – zatwierdzenie Okre ś lenie zobowi ą za ń ; Posortowanie wymaga ń (warto ść, czas, ryzyko); Wybranie zakresu, który wejdzie do wydania. Planowanie wydania – sterowanie Sterowanie procesem; Wprowadzanie zmian; Poprawa szacowa ń i zało ż e ń. 9/17

Metodyka XP – praktyki Planowanie iteracji – eksploracja Transformacja wymaga ń na karty zada ń ; Estymacja czasu potrzebnego na wykonanie. Planowanie iteracji – zatwierdzenie Akceptacja zada ń przez programistów; Wymiana zada ń ; Estymacja czasu przez programistów. Planowanie iteracji – sterowanie Wybór karty zada ń ; Tworzenie par; Projektowanie zada ń ; Pisanie testów jednostkowych i funkcyjnych; Pisanie kodu; Weryfikacja poprawno ś ci kodu za pomoc ą testów. 10/17

XP - Planowanie iteracji 11/17

XP – Planowanie projektu 12/17

Metodyka XP – praktyki Test driven developent – przed napisaniem kodu nale ż y my ś le ć o mo ż liwych nieprawidłowo ś ciach; Whole Team – klient jest u ż ytkownikiem aplikacji i jest stale dost ę pny dla programistów; Continuous integration– cz ę sta integracja nowych rozwi ą za ń ze starymi wymusza zapisywanie kodu w repozytorium; Designe Improvement – najpierw sprawiamy, by działało, a pó ź niej optymalizujemy kod; Small releases – krótkie iteracje, szybkie dostarczenie działaj ą cego oprogramowania klientowi, natychmiastowa weryfikacja przez klienta; Collective code ownership – ka ż dy w równym stopniu odpowiada za cało ść kodu; Simple design – prostsze oznacza lepsze. 13/17

XP – zalety dla zespołu Jako ść – mniej bł ę dów, czytelniejszy kod; Redukcja kosztów – szybki czas reakcji na bł ę dy; Nauka i trening – przepływ wiedzy; Zwi ę kszenie dyscypliny – mniej czasu na rozrywki podczas pracy; Przezwyci ęż enie trudno ś ci – w my ś l zasady: co dwie głowy to nie jedna. 14/17

XP – zalety zarządzania To zespół tworzy harmonogram; Prostota ułatwia planowanie; Zasada: Co dwie głowy to nie jedna; Łatwo ść integracji; Krótki czas od implementacji do weryfikacji przez u ż ytkownika; Zarz ą dzanie zmian ą dzi ę ki testom jednostkowym; Zapewnienie stabilno ś ci dzi ę ki testom akceptacyjnym. 15/17

XP – kiedy warto, a kiedy nie warto Warto Gdy wyst ę puj ą cz ę ste zmiany wymaga ń ; Ryzyko opó ź nienia projektu; Potrzeba szybkiego posiadania aplikacji, która z czasem b ę dzie rozwijana; Nowatorskie technologie; Innowacyjny charakter projektu. Nie warto Gdy projekt jest du ż y; Projekt ma standardowy charakter – niska innowacyjno ść ; Wymagania klienta s ą sprecyzowane; Brak modelu pracownika jako eksperta wielodziedzinowego. 16/17

Źródła D. Astels, G. Miller, M. Novak eXtream programming – Helion /17