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
Top Related