Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WarszawQA_#9

1,462 views

Published on

Prezentacja sprzed 2 lat po sporym liftingu i ostatniej prezentacji w ramach meetupu dla testerow WarszawQA#9 26.06.2015

Published in: Software
  • Be the first to comment

  • Be the first to like this

WarszawQA_#9

  1. 1. Warszawa, 22.06.2015 Jak technika User story&Acceptance criteria pozwala definiować wymagania w SCRUM… ?
  2. 2. 2 Planowanie, dlaczego to robimy? 1 2 3 Rozwiązania biznesowe Rozwiązania technologiczne Inwestycje
  3. 3. 3 Jeśli nie planujemy lub planujemy zbyt mało? Source: http://www.projectcartoon.com/
  4. 4. 4  Wymagania jako user stories i kryteria akceptacji  Technika estymacji (planning poker)  Wykresy wypalenia (burndown charts)  Tablica scrum (kanban board)  Działający kod na koniec sprintu (shippable code) Jak planować skutecznie w Scrum?
  5. 5. Framework Scrum a środowisko projektowe 5 Inżynieria wymagań, analiza biznesowa
  6. 6. Co to jest user story ? Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci "historyjek" (ang. User Stories). Każda historyjka opisuje jedną cechę systemu. Później Właściciel Produktu (ang. Product Owner) na ich bazie buduje Produkt Backlog. Jakkolwiek sposób przedstawienia itemów produkt backlog zależy od zespołu o tyle technika user stories została uznana jako najlepszą i najpopularniejszą formę zapisu wymagań Produkt Backlog. Mike Cohn 6
  7. 7. Atrybuty 7 Napisane z punktu widzenia użytkownika, zawierają krótki opis interakcji użytkownika z produktem w celu osiągnięcia korzyści (Kto, Co i Dlaczego) Koncentruje się na wartości biznesowej jaką powinien otrzymać użytkownik, obietnica dalszej współpracy zgodnie z manifestem agile istotna „Współpraca z klientem zamiast negocjacji kontraktu” Może napisać ją każdy członek zespołu ale to Produkt Owner odpowiada finalnie za każde user story jako składową jednostkę Produkt Backlog Zazwyczaj tworzone na różnym poziomie szczegółowości (high lub low level), później dzielone na mniejsze w strukturze drzewa -> epic-children Posiadają predefiniowany format zapisu oraz kryteria akceptacji pozwalające zwalidować jej zachowanie
  8. 8. Format zapisu Jako użytkownik X chcę wykonać czynność Y aby osiągnąć cel Z. 8 Identyfikacja użytkownika pozwoli zobaczyć kto i w jaki sposób będzie używał nowej funkcjonalności. Czynność opisuje co ma się stać na stronie/w aplikacji po interakcji z użytkownikiem ale nie jak ma to się stać. Identyfikacja osiągnięcia użytkownika lub celu budowania nowej funkcjonalności pozwoli upewnić się o jej potrzebie.
  9. 9. Przykłady user stories Jako „uczestnik targów” chcę „mieć możliwość rejestracji online na stronie internetowej targów”, ponieważ „rejestracja przebiegnie znacznie szybciej ” i „nie będę musiał wypełniać dokumentów papierowych”. Jako „robot indeksujący google” chcę „mieć dostęp do sitemap xml i html strony internetowej Z” tak abym „mógł w ciągu kilku dni zaindeksować 100k stron w wyszukiwarce Google”. 9 1 2
  10. 10. 10 “The last bug isn’t fixed until the last user is dead” Anonymous
  11. 11. Kim są właściwie użytkownicy? 11 • Wiele projektów mówi o użytkownikach • Plany komunikacji • Ale kim są właściwie użytkownicy naszego produktu ? Czego potrzebują ? • W kontekście wielu projektów – Są napisane z perspektywy jednego użytkownika – Zakłada zbieżne lub takie same cele wszystkich użytkowników • Kończymy często z brakującymi wymaganiami…
  12. 12. Modelowanie użytkowników końcowych (tzw. persona) 12 • Burza mózgów • Organizacja wstępnej listy • Konsolidowanie ról • Filtrowanie po rolach
  13. 13. 13 Symulator ciążowy Pozwala mężczyznom, kobietom, nastoletnim dziewczynkom i chłopcom doświadczyć około 20 symptomów i efektów bycia w ciąży Design musi być zawsze skoncentrowany na użytkowniku!
  14. 14. User story wysokiej klasy I - Independent N - Negotiable V - Valuable E - Estimable S - Small T - Testable 14
  15. 15. 15
  16. 16. 16
  17. 17. 17
  18. 18. 18
  19. 19. 19
  20. 20. 20
  21. 21. User stories ewoluują 21  Nie ma fazy user story w projekcie  Tworzone są w miarę potrzeb, jeśli klient/zespół uzna, że są potrzebne  Należy aktualizować, łączyć , dzielić user story kiedy tylko zajdzie taka potrzeba
  22. 22. Priorytetyzacja 22 • Wartość biznesowa ($, H/M/L) – dostarczona przez klienta • Koszt wytworzenia wymagania (złożoność – story points) – informacja dostarczona przez zespół developerski • Metoda MoSCoW (Must, Should, Could, Would)
  23. 23. Kiedy user story jest gotowe ??  Kryteria akceptacji (acceptance criteria) – czyli co i jak trzeba zrealizować w ramach historyjki  Definicja Przygotowania (Definition of Ready) – kiedy historyjka jest gotowa na tyle aby mogła zostać podjęta  Definicja Ukończenia (Definition of Done) – jakie kryteria jakości zostały spełnione dla każdej z historyjek 23
  24. 24. 24 Przepływ stanów
  25. 25. Przykład historyjki z kryteriami akceptacji Historyjka użytkownika: Jako „uczestnik targów” chcę „mieć możliwość rejestracji online na stronie internetowej targów”, ponieważ „rejestracja przebiegnie znacznie szybciej ” i „nie będę musiał wypełniać dokumentów papierowych”. Potencjalne kryteria akceptacji:  Użytkownik nie może zakończyć procesu rejestracji bez wypełnienia wszystkich obowiązkowych pól w formularzu (pól z gwiazdką)  Wszystkie informacje podane przez użytkownika w formularzu rejestracyjnym będą przechowywane w bazie danych MySql  Email potwierdzający poprawną rejestrację zostanie wysłany do użytkownika po poprawnym wypełnieniu formularza  Płatność za konferencję może być dokonana przez bankowość elektroniczną banku X lub kartą kredytową Visa lub Mastercard 25
  26. 26. User story pachną 26 • Wybieganie zbyt daleko w przyszłość – Mgliste wymagania które bardzo trudno precyzyjnie estymować • Nachodzące na siebie user story – Utrudnione planowanie, – Synchronizacja prac w zespołach • Pozłacanie (ang. gold platting) – Developerzy upiększają dostarczane funkcjonalności – lub po swojemu intepretują wymaganie • Zbyt dużo detali • Dodawanie GUI zbyt wcześnie • Klient sam nie napisze user story i nie da właściwego priorytetu
  27. 27. Zalety i ryzyka wykorzystania techniki 27 Zalety • Tworzy wspólny grunt pod dyskusję całego zespołu • Wyzwala w zespole kreatywność i chęć wejścia w buty klienta, postawienia się w wielu rolach • Ułatwia komunikację w zespole • Pozwala na lepszą selekcję funkcjonalności które warto dostarczyć szybko, dają klientowi potencjalnie duży zysk • Poprawia widoczność i utrzymanie kontroli nad Produkt Backlogiem Ryzyka • Tyrania podejścia Waterfall • Próby przepisywania wszystkiego na historyjki użytkownika (trzeba mieć świadomość, że bugi, spike czy taski mogą być częścią Produkt Backlogu) • Naginanie ustalonych wcześniej zasad Definition of Ready i Definition of Done
  28. 28. 28
  29. 29. 29 29
  30. 30. 30 Rafal Stanczak - Agile Coach, CSM, PSM I Email: rafal.stanczak@hotmail.com Blog: www.scrumdo.pl

×