Transcript Slajd 1

eXtream Programming
Autor: Tomasz Karczyński
Zajęcia: Zarządzanie Projektami
Prowadzący: prof. Dorota Kuchta
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






10/17
Wybór karty zadań;
Tworzenie par;
Projektowanie zadań;
Pisanie testów jednostkowych i funkcyjnych;
Pisanie kodu;
Weryfikacja poprawności kodu za pomocą testów.
XP - Planowanie iteracji
11/17
XP – Planowanie projektu
12/17
Metodyka XP – praktyki
 Test driven developent – przed napisaniem kodu należy myśleć o






13/17
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.
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




16/17
Gdy projekt jest duży;
Projekt ma standardowy charakter – niska innowacyjność;
Wymagania klienta są sprecyzowane;
Brak modelu pracownika jako eksperta wielodziedzinowego.
Źródła
 www.extremeprogramming.org
 www.xprogramming.com
 http://art.webesteem.pl
 http://www.slidefinder.net
 D. Astels, G. Miller, M. Novak
eXtream programming – Helion 2007
17/17