Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008.

Prezentacja na temat: "Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008."— Zapis prezentacji:

1 Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008

2 Kartkówka Napisz test dla fragmentu kodu (test first), który ma znajdować największy element w liście.

3 Kartkówka Napisz kod, który pozwala przeprowadzić napisany test

4 Plan Historyjki użytkownika – element XP

5 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

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

7 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

8 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

9 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

10 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

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

12 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

13 Małe Łatwe do zaplanowania Dziel duże, złożone historyjki Łącz zbyt małe historyjki

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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 Powinności testów akceptacji (twórca) Automatyzacja wykonywania testów akceptacji Dodatkowe testy akceptacji Testowanie jednostkowe

26 Powinności testów akceptacji (klient) Pisanie testów akceptacji Wykonywanie testów akceptacji

27 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

28 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)

29 Przewodnik – dobre historyjki (3) Nie numerujemy historyjek Nie zapominamy o celu historyjek

30 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

31 Historyjki to nie jest dokument wymagań są przypadki użycia scenariusze

32 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ę

33 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

34 Projekt - narzędzia Każdy zespół XUnit, Trac, Bugzilla (?) + …

35 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

36 Adresy http://www.surfscranton.com/architecture/SampleStories.htm (przykładowa historyjka użytkownika) http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/index.htmlll (przykładowa historyjka i przypadki użycia) http://web.cs.wpi.edu/~gpollice/cs3733-b05/Project/Stakeholders.html (udziałowcy w projekcie prof.. Pollice)