Transcript Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008 Kartkówka Napisz test dla fragmentu kodu (test first), który ma znajdować największy element w liście.

Efektywne tworzenie
oprogramowania
2008/2009
cvs.ii.uni.wroc.pl/eto2008
Kartkówka
Napisz test dla fragmentu kodu (test first),
który ma znajdować największy element w
liście.
Kartkówka
Napisz kod, który pozwala przeprowadzić
napisany test
Plan
• Historyjki użytkownika – element XP
Historyjki użytkownika
3 elementy
• zapisany opis historyjki użyty do planowania
• konwersacja - dla uzupełnienia szczegółów
• testy można użyć do ustalenia kiedy
historyjka skończona
Reprezentują funkcjonalności, które
będą oceniane przez użytkownika
Przykłady - wartość
• Dobre:
- „Użytkownik może poszukiwać pracy”
- „Firma może oferować nową pracę”
• Złe:
– „Oprogramowanie powinno być napisane w J”
– „Program będzie się łączył z bazą danych
poprzez ..”
Rozmiary historyjek
• Gdy za duże – trudno testować/kodować
• Za małe – więcej czasu na specyfikacje
niż na implementacje
• Implementacja historyjki od 4 godzin do 2
tygodni
• Podział dużych na mniejsze
• Bez drobnych szczegółów – te w czasie
konwersacji
Pisanie historyjek
• Pisze klient
– w języku biznesu, pomaga w podaniu
priorytetów
• Dobre historyjki są:
– niezależne
– mają wartość dla klientów
– można je oszacować
– małe
– testowalne
Niezależne
• Historyjki zależne jedna od drugiej są
trudne do oszacowania i określenia
priorytetu
• Przykład:
– klient może płacić za przesyłkę kartą Visa
– klient może płacić za przesyłkę Mastercard
– klient może płacić za przesyłkę kartą
American Express
Negocjowalne
• Karty z historyjkami – przypomnienie a nie
kontrakt
• Szczegóły wyjaśnia się w czasie rozmów
• Karty z historyjkami zawierają frazę lub
zdanie dla przypomnienia o konwersacji i
notatkach z konwersacji
Cenne
• Dla osób korzystających z aplikacji i dla
płacących za nią
• Zapobiega wartościowaniu historyjek tylko
przez twórcę oprogramowania
• Przykład
– „wszystkie połączenia do b.d. powinny być
realizowane za pomocą ..” można zastąpić
przez „do 50 użytkowników może korzystać z
aplikacji z licencją na 5 użytkowników b.d.”
Oszacowanie
Historyjek nie można oszacować, bo:
• Twórcy oprogramowania nie mają wiedzy
dot. dziedziny problemu
– wydobywaj szczegóły od klienta
• Twórcom oprogramowania brak
odpowiedniej wiedzy technicznej
– twórz „próbkę” do zbadania technologii
• Historyjka jest za duża
– podziel na mniejsze
Małe
• Łatwe do zaplanowania
• Dziel duże, złożone historyjki
• Łącz zbyt małe historyjki
Duże
Podział
•
•
•
•
W czasie konwersacji odkryto wiele dużych
Podział według twórz/usuń/uaktualnij
Podział według granic danych
Badania
Sprawdzić, że każdy podział daje dobrą
historykę
Powinności historyjek (twórca)
• Pomaga klientom w pisaniu historyjek, które
– pozwalają na konwersację a nie podają szczegółowej
specyfikacji
– stanowią wartość dla klienta
– są niezależne
– mają odpowiedni rozmiar
• Opisują potrzebę technologii/infrastruktury w
terminologii mającej znaczenie dla klienta
• Konieczność konwersacji z użytkownikiem
Powinności historyjek (klient)
• Pisze historyjki, które
– pozwalają na konwersację a nie podają
szczegółową specyfikację
– stanowią wartość dla klienta
– są niezależne
– mają odpowiedni rozmiar
• Konwersuje z twórcą oprogramowania
Użytkownicy
• Może być wiele typów użytkowników
systemu
• Różne typy użytkowników mogą mieć
różne role i różne historyjki
• Można uwzględnić niefaworyzowanych
użytkowników jak i faworyzowanych
Modelowanie ról
• Burza mózgów - początkowy zbiór ról
użytkownika
• Utworzyć ten początkowy zbiór
• Skonsolidować role
• Ulepszyć role
Atrybuty – przy ulepszaniu ról
• Częstość z jaką użytkownik używa
aplikacji
• Poziom znajomości dziedziny przez
użytkownika
• Ogólny poziom biegłości użytkownika
• Ogólny/naczelny cel użytkownika
korzystającego z oprogramowania
Modelowanie dodatkowego
użytkownika
• Identyfikowanie osób
– Powinno być tak opisane, że każdy w zespole
ma odczucie jakby tę osobę znali latami
– Wybrać osobę, która reprezentuje populację
użytkowników
• Ekstremalne charaktery
Modelowanie odpowiedzialności
użytkownika (twórca)
• Uczestniczy w procesie identyfikacji ról
użytkownika i osób
• Rozumie rolę każdego użytkownika i
różnice
• Określa jak różne role użytkownika
preferują określone zachowania
oprogramowania
Modelowanie odpowiedzialności
użytkownika (klienci)
• Szerokie spojrzenie na możliwych użytkowników
i identyfikowanie odpowiednich ról
• Uczestniczy w procesie identyfikacji ról
użytkownika i osób
• Upewnia się, że oprogramowanie nie ogniskuje
się nieodpowiednio na podzbiorze użytkowników
• Upewnia się, że każda historyjka jest powiązana
co najmniej z jedną rolą użytkownika
• Określa jak różne role użytkownika preferują
określone zachowania oprogramowania
Odpowiedzialności zbierania
historyjek
• Zrozumienie i wykorzystanie wielu technik
• Specyfika klienta:
– napisać wcześnie wiele historyjek
– zrozumienie opcji w konwersacji z
użytkownikami
– upewnić się, że są uwzględnione wszystkie
role użytkowników
Testy akceptacji
• Wykorzystaj testy do sprawdzenia i
formułowania szczegółów
• Testy akceptacji są świetnie formułowane
przez klienta
• Nie zastępują testów jednostkowych
Powinności testów akceptacji
(twórca)
• Automatyzacja wykonywania testów
akceptacji
• Dodatkowe testy akceptacji
• Testowanie jednostkowe
Powinności testów akceptacji
(klient)
• Pisanie testów akceptacji
• Wykonywanie testów akceptacji
Przewodnik – dobre historyjki (1)
• Rozpoczynamy z historyjkami celu
• Piszemy zamknięte historyjki
• Umieszczamy ograniczenia dotyczące
systemu na kartach historyjek i na ich
podstawie implementujemy automatyczne
testy
Przewodnik – dobre historyjki (2)
• Rozmiar historyjek odpowiedni do czasu
przeznaczonego na implementację
• Nie zajmujemy się UI jak długo to możliwe
• Nie opieramy się tylko na historyjkach,
jeśli coś można wyrazić lepiej inaczej
• W historyjkach – rola użytkownika a nie
„user” (l. pojedyncza)
• Strona czynna (a nie bierna)
Przewodnik – dobre historyjki (3)
• Nie numerujemy historyjek
• Nie zapominamy o celu historyjek
Wykorzystanie historyjek
• Punktujemy historyjki – trudność implementacji
• Dla każdego wydania klient określa priorytety
• Twórcy oprogramowania określają prędkość
(liczbę punktów na okres przygotowania
wydania) poprzedniego cyklu i planują
implementowanie historyjek o najwyższym
priorytecie, aż do liczby punktów tego cyklu
Historyjki to nie
• jest dokument wymagań
• są przypadki użycia
• scenariusze
Cel użycia historyjek
•
•
•
•
•
•
Zrozumiałe dla każdego
Dobry zakres do planowania
Działa przy tworzeniu iteracyjnym
Wzmacnia odkładanie szczegółów
Zachęca do udziału w projektowaniu
Gromadzi/podbudowuje „milczącą” wiedzę
Błędne historyjki
•
•
•
•
•
•
•
Historyjki są za małe
Są zależne między sobą
Za dużo szczegółów
Zbyt szybko zawierają szczegóły Ui
Wybiegają za daleko w przyszłośc
Klient ma trudności z określeniem priorytetów
Klient nie chce pisać ani określać priorytetów
historyjek
Projekt - narzędzia
Każdy zespół XUnit, Trac, Bugzilla (?)
+…
Projekty - terminy
Strona z danymi: temat, zespól (5.XI)
Gra w planowanie z klientem, plan (13.XI)
Opis, analiza ryzyka, implementacja,
testowanie (I iteracja) – 27.XI
Koniec I wydania (2 iteracji) – 4/5.XII
1. iteracja II wydanie - 18/19.XII
2. Iteracja Ii wydanie – 15/16.I.2009
Adresy
http://www.surfscranton.com/architecture/SampleStories.htm
(przykładowa historyjka użytkownika)
http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/index.htmll
(przykładowa historyjka i przypadki użycia)
http://web.cs.wpi.edu/~gpollice/cs3733-b05/Project/Stakeholders.html
(udziałowcy w projekcie prof.. Pollice)