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