User Stories Mity i hity Kamil Niklasiński IIBA PC Business Analysis Round-tables Warszawa 8 stycznia 2015r.
Bravura - Business Facts 2
Zanim zaczniemy 3
Agenda > Definicja i przykład > Kontekst do metodyk zwinnych > Mity > Typowe problemy > Podsumowanie 4
Kontekst i teoria
User Story definicja (?) > Nazwa > Konwersacja > Kryteria akceptacji > Notatki 6
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
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 > 1999 8
Teoria w praktyce przemyślenia
Mit #1 User Stories możemy (nie) stosować w metodykach waterfall 10
Mit #2 User Stories (nie) można łączyć z metodami formalnymi 11
Mit #3 User Stories (oraz metodyki Agile) uniemożliwiają pracę z projektami fixed price 12
Mit #4 User Stories to Use Case y Istotne różnice: > Rozmiar > Planowanie > Używanie po zakończeniu sprintu 13
Mit #5 User Stories mogą być tylko na karteczkach i nie zapewniają precyzji wymagań 14
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
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
Podsumowanie i łyk teorii
INVEST I ndependent N egotiable V aluable E stimated S mall T estable 18
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
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
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
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
Agile i BABOK v2 BABOK v2.0 > PDF link > Rozdział 9.33 1 stronicowe encyklopedyczne podsumowanie Agile Extension to the BABOK Guide > PDF link > Rozdziały 2.1 2.3: Analiza w SCRUM, XP, Kanban > Rozdziały 3.1 3.6: 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
Agile Ext. to the BABOK Guide 24
Agile Ext. to the BABOK Guide 25
Powtórka Lean Manufacturing > TPS > Mnemotechnika Agile > Manifesto > NASA i XP > Mnemotechnika dot. User Stories 26
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
Objawy zmiany podejścia 28
Na koniec 29
Czy to już koniec sesji? Ocena sesji Jest możliwość pogłębienia tematu Networking 30
Kamil Niklasiński kamil@niklasinski.com 884 30 8894 @KNiklasinski Dziękuję za uwagę