Warszawa, 23 listopad 2013

Jak technika User story/Acceptance Criteria pozwala definiować wymagania w SCRUM… ?

2

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

Planowanie

3

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

Jak można planować skutecznie?

4

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)

Jak planować skutecznie w projektach

scrumowych?

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

Atrybuty historyjek

6

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

Format zapisu user stories

Jako użytkownik X chcę wykonać

czynność Y aby osiągnąć cel Z.

7

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.

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

Historyjki wysokiej jakości

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

9

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

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

Cykl życia historyjki w Scrum Framework

13

Zalety i potencjalne ryzyka wykorzystania techniki

14

Zale

ty

• 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

Postaw wartość i jakość Swojego

produktu na pierwszym planie dzięki

tworzeniu wartościowych historyjek

użytkownika

Rafał Stańczak

15

16

17