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

1. Warszawa, 22.06.2015
Jak technika User story&Acceptance
criteria pozwala definiować
wymagania w SCRUM… ?

2. 2
Planowanie, dlaczego to robimy?
1
2
3
Rozwiązania biznesowe
Rozwiązania technologiczne
Inwestycje

3. 3
Jeśli nie planujemy lub planujemy zbyt mało?
Source: http://www.projectcartoon.com/

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. Framework Scrum a środowisko projektowe
5
Inżynieria wymagań,
analiza biznesowa

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. 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. 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. 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
“The last bug isn’t fixed until the last
user is dead”
Anonymous

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. 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
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. User story wysokiej klasy
I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable
14

15. 15

16. 16

17. 17

18. 18

19. 19

20. 20

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. 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. 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
Przepływ stanów

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

29. 29
29

30. 30
Rafal Stanczak - Agile Coach, CSM, PSM I
Email: rafal.stanczak@hotmail.com
Blog: www.scrumdo.pl