Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zwinny_Analityk_SIW_Panel

1,027 views

Published on

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).

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Zwinny_Analityk_SIW_Panel

  1. 1. Jak technika User story/Acceptance Criteria pozwala zgrabnie definiować wymagania w SCRUM Warszawa, 28.11.2016 1
  2. 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. 3. Jeśli nie planujemy lub planujemy zbyt mało? Source: http://www.projectcartoon.com/ 3
  4. 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. 5. Framework Scrum a wymagania Inżynieria wymagań, analiza biznesowa 5
  6. 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. 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. 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. 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. 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. 11. “The last bug isn’t fixed until the last user is dead” Anonymous 11
  12. 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. 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. 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. 15. Przykładowy szablon person 15
  16. 16. Historyjki wysokiej jakości I - Independent N - Negotiable V - Valuable E - Estimable S - Small T - Testable 16
  17. 17. Niezależne od siebie... 17
  18. 18. Negocjowalne... 18
  19. 19. Wartościowe dla biznesu 19
  20. 20. Szacowalne przez zespół 20
  21. 21. Wystarczająco małe 21
  22. 22. Możliwe do przetestowania 22
  23. 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. 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. 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. 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. 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. 28. Rafal Stanczak - Agile Coach, CSM, PSM I, PSPO I Email: rafal.stanczak@hotmail.com Blog: www.scrumdo.pl 28

×