Warszawa, 22.06.2015

Jak technika User story&Acceptance criteria pozwala definiować wymagania w SCRUM… ?

2

Planowanie, dlaczego to robimy?

1

2

3

Rozwiązania biznesowe

Rozwiązania technologiczne

Inwestycje

3

Jeśli nie planujemy lub planujemy zbyt mało?

Source: http://www.projectcartoon.com/

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?

Framework Scrum a środowisko projektowe

5

Inżynieria wymagań,analiza biznesowa

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

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

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.

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

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

Anonymous

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…

Modelowanie użytkowników końcowych(tzw. persona)

12

• Burza mózgów • Organizacja wstępnej listy• Konsolidowanie ról• Filtrowanie po rolach

13

Symulator ciążowyPozwala 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!

User story wysokiej klasy

I - IndependentN - NegotiableV - ValuableE - EstimableS - SmallT - Testable

14

15

16

17

18

19

20

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

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)

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

Przepływ stanów

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

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

Zalety i ryzyka wykorzystania techniki

27

Zal

ety • 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

Ryz

yka • 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

2929

30

Rafal Stanczak - Agile Coach, CSM, PSM I

Email: rafal.stanczak@hotmail.com

Blog: www.scrumdo.pl