www.scrumdo.pl: prezentacja wygłoszona w ramach targów kariera testera i programisty w Warszawie 23 listopada 2013 roku

1. Jak technika User story/Acceptance
Criteria pozwala definiować
wymagania w SCRUM… ?
Warszawa, 23 listopad 2013

2. Planowanie
Po co planujemy ???
Żeby móc podejmować
trafne decyzje w kontekście:
• Rozwiązań technicznych
• Korzyści biznesowych
• Decyzji inwestycyjnych
Żeby móc koordynować
pracę zespołu oraz
efektywnie współpracować z
Interesariuszami
Żeby jakość produktu
była lepsza
2

3. Jak można planować skutecznie?

Planuj tak daleko jak jesteś w stanie

Oszacuj rozmiar i estymuj prace
zespołowo

Postaw jakość na pierwszym planie,
nie skupiaj się wyłącznie na realizacji

Gromadź dane historyczne, umiej je
czytać i wykorzystać

Monitoruj wyniki prac na wielu
płaszczyznach
3

4. Jak planować skutecznie w projektach
scrumowych?

Historyjki użytkownika (user stories)

Technika estymacji
(planning poker)

Wykresy wypalenia (burndown charts)

Tablica scrum (scrum board)

Działający kod na koniec sprintu (shippable code)
4

5. 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 backlogu zależy od zespołu
o tyle technika user stories została uznana jako najlepsza i najpopularniejsza
forma zapisu wymagań Produkt Backlogu. Mike Cohn
5

6. Atrybuty historyjek
Napisane z punktu widzenia użytkownika, zawierają krótki opis interakcji użytkownika
za stroną internetową lub aplikacją w celu osiągnięcia zysku/jakiejś korzyści
Koncentruje się na wyniku działania/wartości biznesowej jaką powinien otrzymać
użytkownik
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
Może być tworzone na różnym poziomie szczegółowości (high lub low level), w razie
potrzeby dzielone na mniejsze historyjki (struktura drzewa, epic-child)
Posiadają predefiniowany format zapisu
6

7. Format zapisu user stories
Identyfikacja osiągnięcia
użytkownika lub celu
budowania nowej
funkcjonalności pozwoli
upewnić się o jej
potrzebie.
Identyfikacja
użytkownika pozwoli
zobaczyć kto i w jaki
sposób będzie używał
nowej funkcjonalności.
Jako użytkownik X
chcę wykonać
czynność Y
aby osiągnąć cel Z.
Czynność
opisuje co ma się stać
na stronie/w aplikacji
po interakcji z
użytkownikiem ale
nie jak ma to się stać.
7

8. Przykłady kilku historyjek
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”.
Jako „osoba regularnie kupująca książki przygodowe” chcę móc
przeczytać recenzję wybranych książek przygodowych na stronie XXX
aby zdecydować którą książkę warto kupić.
8

9. Historyjki wysokiej jakości
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
9

10. Kiedy historyjki są 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 Wykonania
(Definition of Done) – jakie
warunki zostały spełnione
dla każdej z historyjek?
10

11. 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ą lub kartą kredytową
11

12. Przepływ stanów historyjki
12

13. Cykl życia historyjki w Scrum Framework
13

14. • 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
Ryzyka
Zalety
Zalety i potencjalne ryzyka wykorzystania techniki
• 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)
• Ułatwia komunikację w zespole
• Pozwala na lepszą selekcję
funkcjonalności które warto dostarczyć
szybko, dają klientowi potencjalnie duży
zysk
• Naginanie ustalonych wcześniej
zasad Definition of Ready i
Definition of Done
• Poprawia widoczność i utrzymanie kontroli
nad Produkt Backlogiem
14

15. Postaw wartość i jakość Swojego
produktu na pierwszym planie dzięki
tworzeniu wartościowych historyjek
użytkownika
Rafał Stańczak
15

16. 16

17. 17