User Stories Mity i hity. Kamil Niklasiński IIBA PC Business Analysis Round-tables Warszawa 8 stycznia 2015r.

Wielkość: px

Rozpocząć pokaz od strony:

Download "User Stories Mity i hity. Kamil Niklasiński IIBA PC Business Analysis Round-tables Warszawa 8 stycznia 2015r."

Bronisława Henryka Kołodziej
6 lat temu
Przeglądów:

1 User Stories Mity i hity Kamil Niklasiński IIBA PC Business Analysis Round-tables Warszawa 8 stycznia 2015r.

2 Bravura - Business Facts 2

3 Zanim zaczniemy 3

4 Agenda > Definicja i przykład > Kontekst do metodyk zwinnych > Mity > Typowe problemy > Podsumowanie 4

5 Kontekst i teoria

6 User Story definicja (?) > Nazwa > Konwersacja > Kryteria akceptacji > Notatki 6

7 User Story przykład Jako szukający pracy chcę dodać życiorys do mojego profilu. > Kryteria akceptacji Życiorys można załączyć jako w formie pliku PDF i DOC Plik nie może być większy niż 0.5 MB Można załączyć maksymalnie 2 życiorysy do profilu > Konwersacja > Notatki Potwierdzić komunikat walidacji Potwierdzić wsparcie dla spakowanych życiorysów.zip 7

8 Kontekst do metodyk zwinnych Lean Manufacturing > Toyota Production System (koniec lat 80 ubiegłego wieku) > Muda Wastes of Lean Manufacturing - TIM WOOD Agile > Manifesto 2001 extreme Programming > Pierwowzór w projekcie Merkury NASA lata 60-te ub. wieku >

9 Teoria w praktyce przemyślenia

10 Mit #1 User Stories możemy (nie) stosować w metodykach waterfall 10

11 Mit #2 User Stories (nie) można łączyć z metodami formalnymi 11

12 Mit #3 User Stories (oraz metodyki Agile) uniemożliwiają pracę z projektami fixed price 12

13 Mit #4 User Stories to Use Case y Istotne różnice: > Rozmiar > Planowanie > Używanie po zakończeniu sprintu 13

14 Mit #5 User Stories mogą być tylko na karteczkach i nie zapewniają precyzji wymagań 14

15 Mit #6 Dzięki stosowaniu User Stories nie ma potrzeby posiadać Analityka w zespole projektowym Analityk, czy projektant, czy też może architekt lub konsultant? 15

16 Typowe problemy / objawy Brak gotowości, zrozumienia czym jest Lean / Agile Wielkość User Story Zależności Analiza wszystkich szczegółów Dążenie do perfekcji w estymatach Szablony i Completism, Fowler (1997) 16

17 Podsumowanie i łyk teorii

18 INVEST I ndependent N egotiable V aluable E stimated S mall T estable 18

19 Dlaczego User Stories? (1/3) Nacisk na komunikację werbalną > Zamiast wspólnej dokumentacji, wspólne zrozumienie > Zamiast pisać wymagania, dyskutujmy o nich > Fałszywe poczucie precyzji w pisanych dokumentach > Święty Graal doskonałych wymagań (Tom Popendick 100% perfekcyjny lewy but) Zrozumiałe dla wszystkich uczestników projektu > Historyjki unikają używania specyficznego, technicznego żargonu > Łatwe do zrozumienia dla biznesu oraz programistów > Ludzie łatwiej zapamiętują wydarzenia, które są opisane jako historie (Bower, Black and Turner, 1979) 19

20 Dlaczego User Stories? (2/3) Właściwy rozmiar do planowania > Wymagania są trudne do priorytetyzowania z uwagi na zależności > Przypadki użycia są zbyt duże/ciężkie Wspierają iteracyjne wytwarzanie produktu > Progresywna analiza szczegółów epik historyjka doszczegółowienie > Szczegółowa analiza zaraz przed etapem programowania oraz w trakcie > Unikanie Kompletyzmu (Fowler (1997)) 20

21 Dlaczego User Stories? (3/3) Praca ze wszystkimi wymaganiami opisanymi szczegółowo jest niemożliwa > Parnas and Clemens (1986) Użytkownicy i klienci, zwykle nie wiedzą dokładnie czego chcą Nawet jeśli wszystkie wymagania zostały zdefiniowane, wiele szczegółów pojawi się/zmieni się w trakcie rozwoju oprogramowania Nawet jeśli wszystkie szczegóły będą znane, to ludzie z natury nie są w stanie ogarnąć tyle szczegółów Nawet jeśli wszystkie szczegóły są znane i rozumiane, to zawsze pojawiają się zmiany Ludzie robią błędy 21

22 Traditional vs Lean Analysis Tradycyjna > Wszystkie wymagania są zdefiniowane > Wszystkie detale dot. wymagań muszą być znane > Małe możliwości zmiany, blame game > Tworzone duże ilości dokumentacji, nie czytanej, nie rozumianej > Nacisk na umowy, dużo dokumentacji i formalne procesy > Dokumentacja tworzona z zamysłem ponownego użycia Agile / Lean > Zbieramy na początku wymagania na wysokim poziomie abstrakcji > Nie analizujemy wszystkich szczegółów na początku projektu > Jeśli trzeba chętnie wprowadzam zmiany > Ilość dokumentacji jest ograniczona do minimum > Skupiamy się na dostarczaniu wartości dla Klienta > User Stories nie są utrzymywane, dokumentowane po zakończeniu projektu 22

23 Agile i BABOK v2 BABOK v2.0 > PDF link > Rozdział stronicowe encyklopedyczne podsumowanie Agile Extension to the BABOK Guide > PDF link > Rozdziały : Analiza w SCRUM, XP, Kanban > Rozdziały : Mapowanie technik zwinnych na BABOK Guide. Lista rozdziałów BABOK gdzie można wykorzystać technikę User Story: Prepare for Elicitation (3.1) Manage Solution Scope and Requiremens (4.1) Manage Requirements Traceability (4.2) Maintain Requirements for Reuse (4.3) Prepare Requirements Package (4.4) Define Solution Scope (5.4) Organize Requirements (6.2) Define Assumptions and Constraints (6.4) Verify Requirements (6.5) Allocate Requirements (7.2) Define Transition Requirements (7.4) 23

24 Agile Ext. to the BABOK Guide 24

25 Agile Ext. to the BABOK Guide 25

26 Powtórka Lean Manufacturing > TPS > Mnemotechnika Agile > Manifesto > NASA i XP > Mnemotechnika dot. User Stories 26

27 Tematy nie omówione Szczegółowo IIBA BABOK oraz BABOK v3.0 w kontekście Agile oraz User Stories Używanie metod formalnych z User Stories Story Maps Definiowanie User Roles User Stories Elicitation techniques Planowanie releas ów i projektów z wykorzystaniem User Stories (np. projekty fixed price) Używanie narzędzi do zarządzania User Stories Definition of done 27

28 Objawy zmiany podejścia 28

29 Na koniec 29

30 Czy to już koniec sesji? Ocena sesji Jest możliwość pogłębienia tematu Networking 30

31 Kamil Niklasiński Dziękuję za uwagę

Podobne dokumenty

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów