Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.

1. Jak zostać zwinnym
(Agile) Analitykiem
Mariusz Opaliński
@mariuszop
e-mail: maropalin@gmail.com
Konferencja beIT - 28 marzec 2015

2. O mnie ;)

3. O czym będzie?
 Jak Agile zmienia rolę Analityka?
 Co robi Analityk w projektach AgileScrum?
 Nowe praktyki i techniki
 Czego oczekuje Zespół?

4. Zakładam, że
 Znasz podstawy Agile, SCRUM, RUP,.. BABOK
 Jesteś, bądź kiedyś będziesz:
 Analitykiem
 Product Owner-em (PO)
 Scrum Master-em (SM)
 Członkiem zespołu SCRUM-owego
 Agile menadżerem….

5. IMO Agile … *
 Agile to „duża zmiana” – inna filozofia działania
 Agile nie jest łatwy
 Agile nie jest dla każdego – kompetencje, cechy
 Agile nie jest do wszystkiego – klient, umowy, produkty
 Agile jest męczące, ale efektywne i daje satysfakcję
 Wymagania są nadal największym wyzwaniem IO
 Agile wzmacnia rangę SPI
 Nie trzeba być 100 % Agile żeby z niego czerpać
* Przedstawione informacje są prywatnymi opiniami i doświadczeniami autora i nie muszą być zgodne ze stanem
faktycznym ;)

6. Najpoważniejszy standard branżowy dla BA
 Najbardziej pełny zbiór wiedzy
na temat analizy biznesowej
 Podstawa szkoleń i certyfikacji
 Odpowiednik BAKOK w PM
Uwaga!
To nie jest metodyka!

7. Przewodnik dla analityków w Agile
 Współpraca IIBA i Agile Alliance
 Rola analityka w środowisku Agile
 Aktywności analityczne w
 SCRUM,
 XP,
 Kanban,….
 Nowe praktyki i techniki
 Istotnie uzupełnia metodyki Agile

8. Zwinny (Agile) Analityk
 Posiada warsztat analityczny
 Zna i akceptuje filozofię Agile
 Zna reguły metodyk Agile (SCRUM, XP, Kanban)
 Zna praktyki Agile i kontekst ich użycia
 Zna i odpowiednio stosuje nowe techniki
 Certyfikowany Product Owner (zalecane)

9. Co się zmienia?… chyba jednak sporo
Filozofia działania Nowe techniki
Proces
Użycia starych technik

10. Nowa filozofia
Nowa
filozofia
działania !!!

11. Skupienie na wartości biznesowej

12. Zespół

13. Efektywna komunikacja

14. Podejście adaptacyjne vs tradycyjne

15. Podejście adaptacyjne vs tradycyjne
Adaptacyjnie Tradycyjnie
Dostarczanie funkcjonalności Podział zadań
Plany są hipotezą Plany są przewidywaniem
Sukces jako zdolność adaptacji Sukces jako zgodność z planem
Szczegółowe plany dla
bieżących iteracji, zgrubne
plany dla dalszych etapów
Szczegółowe plany dla całości
projektu
Przyczyny odchyleń są
analizowane i wykorzystywane
do zmiany planu kolejnych
iteracji
Odchylenia od planu traktowane
są jako błędy zarządzania

16. Co się zmienia w praktyce
 Nowy proces → praca w iteracjach
 Analityk w Zespole → współodpowiedzialność
 Komunikacja → bezpośrednia, intensywna
 Modele, dokumenty → tak lekkie jak to możliwe
 Szczegółową analiza → najpóźniej jak to możliwe
 Częsta weryfikacja → bezcenny feedback
 Adaptacja → wreszcie można zmienić wymagania!

17. Oznaki braku zmiany filozofii
 Postrzeganie Agile jako serii
mini-kaskadowych projektów
 Skupianie się na rozwoju
jednego produktu
analitycznego
 Skupianie się bardziej na
dokumentacji niż na
komunikacji
 Postrzeganie swojej roli jako
mostu między ludźmi
biznesowymi i ludźmi IT
 Ochrona swojego terytorium -
„to jest moje zadanie”
 Produkowanie więcej
dokumentów niż to potrzeba
 Brak świadomości jednorazowości
modeli
 Uznawanie tylko jednej słusznej
drogi rozwiązania
 Niechęć do realizacji zadań spoza
własnego obszaru specjalizacji
 Nieuwzględnianie zmian wymagań
i ciągłego doskonalenia się
 Modelowanie w izolacji
 Opór w wykorzystaniu technik
współpracy
 Nie akceptowanie i brak adaptacji
płynnej natury projektów

18. Ale w SCRUM jest tylko Product Owner?!
 Określa i komunikuje wizję
 Definiuje cechy produktu
 Określa plan wydań i ich zakres
 Odpowiada za zwrot z inwestycji (ROI)
 Priorytetyzuje backlog wg. wartości biznesowej
 Akceptuje bądź odrzuca wyniki prac

19. Kiedy potrzebny analityk?
 Duży projekt
 Złożone procesy biznesowe i logika produktu
 Zespół nie zna dziedziny
 Wielu udziałowców – wymagane zarządzanie
 Właściciel biznesowy Produktu nie może być 100% PO
 PO nie ma doświadczeń projektowych i analitycznych

20. Analityk i Product Owner
 Bez wydzielonego analityka
 te rolę pełni ktoś z zespołu
 Koordynuje udziałowców
 wsparcie dla PO, budowa wizji, modelowanie
 Pełnomocnik PO
 ograniczone możliwości decyzyjne, PO w iteracjach
 Coach dla PO
 PO o słabych kompetencjach w projektach IT, Agile
 Zastępczy PO
 gdy nie ma PO

21. Analityk dba o komunikację
Analityk i PO nie są pośrednikami między biznesem i IT!

22. Analityk w cyklach Agile
Zwinny (Agilowy) analityk troszczy się o to aby
Zespół w odpowiednim czasie posiadał
odpowiednie informacje na właściwym poziomie
szczegółowości tak aby mógł budować właściwy
Produkt
(źródło: BABOK The Agile extension)

23. SCRUM – nowy tryb pracy

24. Gdzie analiza w SCRUM?
(źródło: BABOK The Agile extension)

25. • Utrzymanie backlogu projektu
• Regularna estymacja
• Plan wydań i iteracji
• Adaptacja i potwierdzanie zakresu
• Praca z Kientem i udziałowcami
• Wypracowanie wizji produktu
• Business Case
• Analiza, modelowanie – aby zrozumieć
• Identyfikacja Epics, UserStory
• Backlog – identyfikacja wartości biz.
Planowanie strategii i wydań

26. • Backlog Iteracji
• Planowanie iteracji z
Zespołem
• Szczegółowe wymagania
do iteracji bieżącej
• Szczegółowe wymagania
do iteracji przyszłej
• Intensywna komunikacja
z Zespołem,
• Akceptacja historyjek
• Retrospektywa
• Adaptacja
Planowanie i realizacja iteracji

27. Analiza w iteracjachsprintach
Identyfikacja
nowych wymagań
Utrzymanie
spriorytetyzowanej
listy wymagań
Potwierdzenie
zakresu z PO
Przygotowanie
Szczegółowych
wymagań
Weryfikacja
i adaptacja
Adaptacja i ciągłe planowanie – zmiana wymagań może być dobra!

28. Backlog - tu zarządzamy wymaganiami

29. Różne oblicza Backlog-u
 Epika → Historyjka
 Epika → Historyjka → Zadanie
 Epika → Cecha → Historyjka → Zadanie
 Epika → UC → Historyjka → Zadanie → AT

30. User Story – historyjki użytkownika
 Wygodne - szybko definiują zakres
 Pokazują co i dlaczego
 Łatwo estymowalne
 Możliwy podział
 Obietnica rozmowy a nie specyfikacja
 Historyjki nie są dokumentacją wymagań
 Historyjka to produkt końcowy analizy
 Potrzebne grupowanie historyjek

31. Typowe troski Scrum Mastera
 Czy analityk jest prawdziwym członkiem Zespołu
 Komunikacja, współpraca, postawa
 Skuteczne przekazanie wizji produktu
 Angażowanie PO i udziałowców w prace
 Wsparcie przy planowaniu i estymacji
 Retrospektywy – doskonalenie metody
 Product Owner i Analityk
 Dayli Scrum
 Akceptacja historyjek
 Efektywność modelowania
No i co mam z
Tobą zrobić
Analityku?

32. Czego zespół oczekuje od Analityka?
 Kompetencji
 Decyzyjności
 Dostępności
 Bycia w drużynie
 Objaśniania wymagań, modeli
 Przestrzegania przyjętych reguł
 Jasnych kryteriów akceptacji
 Uznania gdy są efekty
 Bycia aktywnym animatorem planowania,
analizowania, testowania i demonstrowania działania
produktu
Jesteś nam
potrzebny !!!

33. Co można zyskać?

34. Dziękuję !
@mariuszop
Więcej szukaj pod: #agile, #baot