Jak zostać zwinnym (Agile) analitykiem

3,045 views

Published on

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.

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,045
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
60
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Jak zostać zwinnym (Agile) analitykiem

  1. 1. Jak zostać zwinnym (Agile) Analitykiem Mariusz Opaliński @mariuszop e-mail: maropalin@gmail.com Konferencja beIT - 28 marzec 2015
  2. 2. O mnie ;)
  3. 3. O czym będzie?  Jak Agile zmienia rolę Analityka?  Co robi Analityk w projektach AgileScrum?  Nowe praktyki i techniki  Czego oczekuje Zespół?
  4. 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. 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. 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. 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. 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. 9. Co się zmienia?… chyba jednak sporo Filozofia działania Nowe techniki Proces Użycia starych technik
  10. 10. Nowa filozofia Nowa filozofia działania !!!
  11. 11. Skupienie na wartości biznesowej
  12. 12. Zespół
  13. 13. Efektywna komunikacja
  14. 14. Podejście adaptacyjne vs tradycyjne
  15. 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. 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. 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. 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. 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. 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. 21. Analityk dba o komunikację Analityk i PO nie są pośrednikami między biznesem i IT!
  22. 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. 23. SCRUM – nowy tryb pracy
  24. 24. Gdzie analiza w SCRUM? (źródło: BABOK The Agile extension)
  25. 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. 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. 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. 28. Backlog - tu zarządzamy wymaganiami
  29. 29. Różne oblicza Backlog-u  Epika → Historyjka  Epika → Historyjka → Zadanie  Epika → Cecha → Historyjka → Zadanie  Epika → UC → Historyjka → Zadanie → AT
  30. 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. 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. 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. 33. Co można zyskać?
  34. 34. Dziękuję ! @mariuszop Więcej szukaj pod: #agile, #baot

×