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 (przykładowa historyjka użytkownika) (przykładowa historyjka i przypadki użycia) (udziałowcy w projekcie prof.. Pollice)