eXtream Programming

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

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

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

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

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

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

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

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

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

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

11. XP - Planowanie iteracji

12. XP – Planowanie projektu

13. Metodyka XP – praktyki • Test drivendevelopent– 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; • Continuousintegration– częsta integracja nowych rozwiązań ze starymi wymusza zapisywanie kodu w repozytorium; • DesigneImprovement– najpierw sprawiamy, by działało, a później optymalizujemy kod; • Smallreleases– krótkie iteracje, szybkie dostarczenie działającego oprogramowania klientowi, natychmiastowa weryfikacja przez klienta; • Collectivecodeownership– każdy w równym stopniu odpowiada za całość kodu; • Simple design – prostsze oznacza lepsze.

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

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

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

17. Źródła • www.extremeprogramming.org • www.xprogramming.com • http://art.webesteem.pl • http://www.slidefinder.net • D. Astels, G. Miller, M. Novak eXtreamprogramming – Helion 2007