Zwinne metodyki zawdzięczają swoje powstanie dzięki potrzebie elastycznej obsługi szybko zmieniających się wymagań klienta w czasie trwania projektu oraz tworzeniu wysokiej jakości programów, aplikacji czy serwisów internetowych. Prezentacja ukazuje jedną z najpopularniejszych technik wspierających zbieranie i opisywanie wymagań użytkownika w postaci historyjek (User Stories) oraz ich późniejszą projekcję na codzienną pracę zespołu poprzez zbiór kryteriów akceptacji (Acceptance Criteria).

1. Jak technika User story/Acceptance Criteria
pozwala zgrabnie definiować wymagania w
SCRUM
Warszawa, 28.11.2016
1

2. Dlaczego warto planować?
3
Pozwala efektywniej gospodarować ludzką
energią i innymi zasobami, ułatwia współpracę
2
Zmusza do myślenia o przyszłości w kontekście
podejmowanych decyzji (biznesowych,
technologicznych, inwestycyjnych)
1
Pozwala na robienie błędów na przysłowiowym
papierze zamiast w życiu...
2

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

4. Dlaczego projekty IT się nie udają?
Source: ESI International survey of 2000 business professionals, 2005
Poor Requirement Definition 50%
Poor Scope Definition 15%
Inadequate Risk Management 17%
Communication Problems 14%
Lack of Qualified Resources 3%
Other 1%
4

5. Framework Scrum a wymagania
Inżynieria wymagań,
analiza biznesowa
5

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. Charakterystyki historyjek
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 są na różnym poziomie szczegółowości (począwszy od
wysokiego a później dzielone na mniejsze w strukturze drzewa -> epic-story
Posiadają predefiniowany format zapisu oraz kryteria akceptacji pozwalające
zwalidować jej zachowanie
7

8. Format zapisu
Jako
użytkownik
X
chcę
wykonać
czynność Y
aby osiągnąć
cel Z.
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.
8

9. Priorytetyzacja historyjek
• Wartość biznesowa ($, H/M/L, skala liczbowa)
- dostarczona przez klienta/roadmapę
• Koszt wytworzenia wymagania (złożoność, kompleksowość –
story points)
- informacja dostarczona przez zespół developerski
• Metoda MoSCoW (Must, Should, Could, Would)
9

10. Przykłady historyjek
Jako „uczestnik targów” chcę „mieć możliwość rejestracji
online na stronie internetowej targów”, ponieważ „nie
będę musiał wypełniać dokumentów papierowych” oraz
rejestracja przebiegnie znacznie szybciej.
1
2
Jako „robot indeksujący google” chcę „mieć dostęp do
sitemap xml i html strony internetowej Z” abym „mógł w
ciągu 7 dni zaindeksować przynajmniej 100k stron w
wyszukiwarce Google”.
10

11. “The last bug isn’t fixed until the last
user is dead”
Anonymous
11

12. Kim są użytkownicy?
• Wiele projektów mówi o użytkownikach
• Plany komunikacji
• Ale kim są właściwie użytkownicy naszego produktu ? Po co i
jak używają produktu ? Czego potrzebują?
• W kontekście wielu projektów historyjki są:
- Napisane z perspektywy jednego użytkownika
- Zakładają zbieżne lub takie same cele wszystkich userów
- Dlatego kończymy często z brakującymi wymaganiami…
12

13. Symulator ciążowy
Pozwala mężczyznom, nastoletnim
dziewczynkom i chłopcom doświadczyć około
20 symptomów i efektów bycia w ciąży.
Nauka przez dośwadczenie...!
Proces wytwórczy musi być zawsze
skoncentrowany na użytkowniku!
13

14. Modelowanie użytkowników końcowych
• Burza mózgów
• Organizacja wstępnej listy
• Konsolidowanie ról
• Filtrowanie po rolach
• Max. 4-6 person
14

15. Przykładowy szablon person
15

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

17. Niezależne od siebie...
17

18. Negocjowalne...
18

19. Wartościowe dla biznesu
19

20. Szacowalne przez zespół
20

21. Wystarczająco małe
21

22. Możliwe do przetestowania
22

23. Pamiętaj user stories ewoluują
• Nie ma tzw. 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
23

24. Kiedy user story jest gotowe ?
§ Kryteria akceptacji (Acceptance Criteria)
– mówi co trzeba zrealizować w ramach historyjki
§ Definicja Gotowości (Definition of Ready)
– kiedy historyjka jest gotowa aby mogła zostać
kandydatem na sprint/release
§ Definicja Ukończenia (Definition of Done)
– jakie kryteria jakości muszą zostać
spełnione dla każdej z historyjek
24

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ż „nie będę musiał wypełniać dokumentów
papierowych” i „rejestracja przebiegnie szybciej ”.
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ą banków X,Y lub kartą kredytową Visa lub MasterCard
25

26. Zalety wykorzystania techniki
• Tworzy wspólny grunt pod dyskusję całego zespołu, ułatwia
komunikację
• Wyzwala w zespole kreatywność i chęć wejścia w buty
klienta, postawienia się w wielu rolach
• Pozwala na lepszą selekcję funkcjonalności, które warto
szybko dostarczyć i które dają klientowi potencjalnie duży
zysk (e.g. ROI, TCO)
• Znacznie poprawia widoczność zakresu i utrzymanie kontroli
nad Rejestrem Wymagań (ang. Product Backlog)
26

27. User story „pachną”
• Wybieganie zbyt daleko w przyszłość
- Mgliste wymagania które bardzo trudno precyzyjnie
estymować
• Nachodzące na siebie user story
- Utrudnione planowanie i 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
• Próby przepisywania wszystkiego
• Naginanie wcześniej ustalonych zasad
Definition of Ready i Definition of Done
27

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