No i stało się. Nastał dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z „Edge of Tomorrow”. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/a kolejnego podejścia w przypadku porażki projektu. Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.

1. Wymagania w Agile
Krystian Kaczor
v. 2.6. 2015-­‐05-­‐30

2. ©QAgile 2

3. Co daje długa i żmudna
analiza wymagań?
©QAgile 3

4. “Jeśli spędzaszzbyt dużo czasu na
myśleniu o czymś,
NIGDY
tego nie zrobisz“
Bruce Lee
©QAgile 4

5. Problemy z wymaganiami
• 65% funkcjonalności rzadko lub wcale używane
• Spisane wymagania są niepoprawnie interpretowane
• Nie pasują do technologii
• Są pisane z punktu widzenia “jedynego mitycznego usera”
• Większość wymagań ma Priorytet 1
• Zmieniają się w trakcie pracy
• Klient nie dostaje tego, co potrzebuje
• Klient nie wie czego chce lub co potrzebuje
©QAgile 5

6. ©QAgile 6

7. O co chodzi w Agile?
©QAgile 7

8. Co to Ci daje?
©QAgile 8
M
ETODA
TRADYCYJNA DUŻA
DELTA
AGILE
MAŁA
DELTA
CZAS
INTERACJA 1 INTERACJA 2 INTERACJA 3 ................. INTERACJA N
OCZEKIWANIAKLIENTA
PRZYROST
FUNKCJONALNOŚCI

9. Scrum = framework
zbudowany na procesie
empirycznym
©QAgile 9

10. ©QAgile 10

11. 11

12. Product Backlog
“Product Backlog
odzwierciedla
świadomość
Product Ownera”
Andy Brandt, 2015
©QAgile 12

13. Lean Canvas – Jak ma działać biznes?
©QAgile 13

14. Wizja Produktu
Wypowiedź w
windzie
Koleżeńska
Jednomyślność
Przyszła Notka
Prasowa
Opakowanie
produktu
© QAgile 14

15. Impact Mapping
©QAgile 15
Cele Persony Wpływ Funkcjonalności

16. ©QAgile 16

17. ©QAgile 17

18. Agile, czyli piszemy User
Story, tak? Nie, ale …
©QAgile 18

19. To co mamy w Product Backlog?
©QAgile 19

20. .. korzystanie z User Story pomaga
©QAgile 20

21. Warunki Satysfakcji
©QAgile 21

22. ©QAgile 22
Warunki Satysfakcji ≠ Definition of Done

23. Definition of Done - przykład
üKażde Story i zadanie są testowalne,
üKod jest napisany i kompletny,
üZadanie kompletnie wykonane,
üWykorzystane TDD
üPrzegląd kodu został wykonany,
üPrzetestowane,
üBrak błędów w Continuous Integration,
üUdokumentowane (JavaDoc jest obowiązkowy)
©QAgile 23

24. Story Mapping
© QAgile 24

25. ©QAgile 25

26. Obrabiamy górę lodową
©QAgile 26
©Mike Cohn

27. Product Backlog Refinement
• Dodawanie Warunków Satysfakcji
• Dzielenie
• Tworzenie nowych
• Sprawdzanie I.N.V.E.S.T.
• Sprawdzanie “Ready state”
• Dzieje się 1-2 Iteracje do przodu
©QAgile 27

28. Nie wszystko musi być zaimplementowane
©QAgile 28
x
x
xx
xx

29. Specification By Example
©QAgile 29
Business Goal
Scope
Examples
Key Examples
Specification with Examples
(Gherkin)
Executable Specification
Living Documentation
Derive the scope
Illustrate using examples
Specify collaboratively
Automate validation
Refine specification
Validate frequently

30. ©QAgile 30

31. 3C by Ron Jeffrie
Card Conversation Confirmation
Impact Mapping
Story Mapping
Refinement
Planning
SBE
Praca w Sprincie
SBE
ATDD
BDD
WYMAGANIE
© QAgile 31

32. Wymagania w Agile to nie jeden
raz spisane User Story, ale
rozmowa i informacja zwrotna
©QAgile 32

33. 33©QAgile

34. Biblio
34© QAgile

35. Dziękuję
Kontakt
krystian.kaczor@qagile.pl
http://www.qagile.pl
@krystian_kaczor
Krystian Kaczor
35©QAgile