Wielu analityków zastanawia się jak pogodzić swoją pracę z podejściem agilowym, a zwłaszcza popularnym Scrumem, który nie ma roli analityka. Sprawdźmy co na ten temat mówi teoria, praktyka i statystyka.

W Scrum Guide ani słowa o analityku

W Scrum Guide – 17-stronicowej biblii Scruma nie znajdziesz ani słowa o analityku. Stąd też zrodziło się wiele pytań, wątpliwości i propozycji jak go tam upchnąć.
W Scrumie – najpopularniejszym ze sposobów wprowadzania podejścia zwinnego (Agile) w firmach mamy zespoły Scrumowe składające się z:
  • Product Ownera – roli odpowiedzialnej za wartość rozwiązania dla odbiorców
  • Scrum Mastera – roli odpowiedzialnej za przestrzeganie zasad Scruma,
  • Zespołu Developerskiego – składającego się z osób posiadających kompetencje wystarczające do tworzenia kolejnych wydań/przyrostów rozwiązania.

A co na to teoria, podręczniki i zbiory dobrych praktyk dla analityków?

Tematykę analityka w Agile adresuje:
  • metodyka AgilePM (Agile Project Management),
  • zestaw dobrych praktyk AgileBA (Agile Business Analysis – DSDM Consortium),
  • zestaw dobrych praktyk Agile Extension to BABOK Guide (IIBA – International Institute of Business Analysis).
W dwóch pierwszych znajdziemy wskazówki co do umiejscowienia analityka na tle zespołu. IIBA dotyka tematu mówiąc, że zwinny analityk stosuje dobre praktyki zwinnej analizy, ale nie określa, gdzie ten analityk powinien być i na jakich zasadach współpracować z zespołem.
W Agile PM analityk pojawia się „w szyi bałwanka”, czyli w miejscu łączenia biznesu i IT.
Źródło: Role projektowe AgilePM SDSM Consortium
AgileBA proponuje umiejscowienie analityka poza zespołami Scrumowymi. Analityk synchronizuje i zapewnia jakość wymagań na poziomie organizacji (bierze pod uwagę np. ograniczenia prawne, techniczne, synchronizację potrzeb różnych działów), a nie zespołu. W zespole znajdują się Ambasadorzy Biznesowi – najbliżsi konceptowi Product Ownera.

A co na to praktycy?

Ostatnimi czasy na spotkaniach branżowych temat pojawił się kilka razy. Praktycy przedstawiają opcje:
  • analityk jako Product Owner,
  • analityk jako Developer (członek zespołu Scrumowego),
  • analityk jako pomocnik Product Ownera,
  • analityk zupełnie poza zespołem Scrumowym – doradzający PO na żądanie jak każdy inny specjalista od czegoś.

Jak oceniają te opcje? Pojawiały się różne plusy i minusy.

Analityk jako Produkt Owner

Analityk jako Product Owner odpowiada za wartość rozwiązania dostarczanego do interesariuszy. Brzmi dla analityka jak codzienna praca? Ważna jest tu decyzyjność – jeśli analityk zadecyduje, że coś ma wejść do sprintu z takim a nie innym priorytetem, to tak właśnie ma być. Oczywiście musi przy tym uwzględniać interesy różnych grup. A, żeby je uwzględniać, musi rozmawiać z różnymi ludźmi na spotkaniach, warsztatach, wyjazdach – a przynajmniej dobrze by było, żeby produkt szedł w stronę użytkowników i ich rzeczywistych potrzeb, a nie własnego widzimisię. Utrudnia to codzienną komunikację z zespołem.

Analityk jako Pomocnik Product Ownera

Jako pomocnik Product Ownera analityk może wspierać w przygotowywaniu historyjek użytkownika (User Stories), zbieraniu informacji, wykonywaniu dodatkowych analiz. Jeśli zespół ma kontakt zarówno z PO i analitykiem, trzeba pilnować, żeby każdy z nich nie przedstawiał „swojej wersji prawdy”. Należy szczególnie zadbać o synchronizację, jednomyślność lub jasne wyznaczenie granic odpowiedzialności.

Analityk jako członek zespołu Scrumowego

Jako członek zespołu Scrumowego analityk wpada w tryb pracy w sprintach. Jako, że analiza i definiowanie wymagań ma miejsce zazwyczaj przed kodowaniem, to zaleca się analitykom wykonywanie również innych zadań jak np. testowanie. Główne ograniczenie w takim umiejscowieniu analityka polega na konieczności wykonywania analiz na tyle drobnych, by zdążyły pojawiać się w 2-4 tygodniowych sprintach na tyle wcześnie, by być w nich zakodowanymi. Plusem jest na pewno bliskość developerów i stały kontakt.

Analityk poza zespołem Scrumowym

Plusem na pewno jest spokojna praca. Można analizować do woli i kończyć, kiedy jest skończone, a nie wtedy, kiedy nadchodzi ciśnienie ze strony końca sprintu. Minusem tego podejścia jest mniejszy kontakt z zespołem Scrumowym. Nie będąc członkiem zespołu analityk często nie ma wstępu na Daily Scrumy (tzw. standupy) i na retrospektywy.

A co na to statystyka?

W Badaniu Zarobków i Kompetencji Analityków Biznesowych 2018 pojawiło się pytanie o rolę analityka w Scrumie. Odpowiedziało 401 osób a oto wyniki:
  • 37% analityków nie pracuje w Scrumie,
  • 32% analityków pracuje jako członek zespołu Scrumowego,
  • 19% analityków pracuje jako Product Owner,
  • 8% analityków pracuje jako pomocnik Product Ownera,
  • 4% analityków pracuje jako Scrum Master.

Analityk w Scrumie - Analiza IT

Co sprawdza się u Ciebie?

10 KOMENTARZE

    • Racja. Mój błąd. Muszę poprawić na obrazku.
      37% analityków nie pracuje w Scrumie,
      32% analityków pracuje jako członek zespołu Scrumowego,
      19% analityków pracuje jako Product Owner,
      8% analityków pracuje jako pomocnik Product Ownera,
      4% analityków pracuje jako Scrum Master.

  1. Pani Haniu,
    „W Scrum Guide – 17-stronicowej biblii Scruma nie znajdziesz ani słowa o analityku. ”

    czyżby? Cytat:
    „Scrum recognizes no sub-teams in the Development Team, regardless of domains that need
    to be addressed like testing, architecture, operations, or business analysis”

    Co więcej, „Scrum Guide” nie jest dokumentem, mającym dawać ścisłe reguły, tak jak np. BABOK. W tym cała jego siła. Cytat już z polskiej wersji:
    „Scrum nie jest procesem czy techniką wytwórczą, czy też wyczerpującym opisem sposobu działania. Definiuje jedynie ogólne reguły postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju
    procesów i technik.”

    Nie ma okazji przegadać z Panią tematu Agile i Analiz, żeby przeciągnąć jednego z bardziej znanych Analityków w tym kraju, na jasną stronę mocy :-)

    Pozdrawiam
    Artur B.

    • > czyżby? Cytat:
      > „Scrum recognizes no sub-teams in the Development Team, regardless of domains that need
      > to be addressed like testing, architecture, operations, or business analysis”
      Analiza biznesowa to chyba coś innego niż analityk. Jedno to rola, a drugie dziedzina/aktywność. Scrum Guide nic o ANALITYKU nie mówi.

      > Co więcej, „Scrum Guide” nie jest dokumentem, mającym dawać ścisłe reguły, tak jak np. BABOK. W tym cała jego siła.

      BABOK nie daje ścisłych reguł. Wprost wręcz mówi: „It does not describe the processes that people will follow to do business analysis.” Scrum Guide natomiast nadaje właśnie ścisłe ramy, których trzeba przestrzegać, bo inaczej Scruma się nie realizuje (Scrum Guide jest definicją Scruma, jeśli chcemy coś robić Scrumowo, trzeba się jego definicji trzymać).

      Na koniec dodam jeszcze opinie od siebie – nie ma czegoś takiego jak jasna strona mocy. Są różne projekty i w różnych sposób (w zależności od kontekstu projektu i organizacji) powinny być realizowane. Nie ma jednej słusznej drugi. I nie jest ją ani Scrum, ani PMBOK itp. One są tylko narzędziami, które trzeba dobrać do okoliczności i potrzeb.

      • @Pierwszy akapit
        W mojej ocenie, jednak mówi o analityku, tak samo jak o innych rolach, takich jak Tester, Architekt, Deweloper, Dokumentalista etc. Krótko mówiąc: zespół, samoorganizacja, między-funkcjonalność (to z polskiego Guida).

        @Drugi akapit
        Też pozwolę sobie, nie zgodzić się.
        Gdzie w Scrum Guide napisane jest: czy i jak zbierać wymagania, czy i jak tworzyć dokumentację (tak już skrajnie). W tym cała magia, że w ramach organizacji, projektu, produktu etc. należy to dostosować, dla „maksymalizacji wartości produktu ”

        @Trzeci akapit
        „jasna strona mocy” to oczywiście żart. Ale zgadzam się z tym całkowicie, że Scrum oraz wszelkie inne podejścia to tylko/aż narzędzia, które warto znać i dobierać w zależności od aktualnych potrzeb. I tu też cytat ze Scrum Guide: „Poszczególne zastosowania Scruma mogą się między sobą różnić i z tego względu wykraczają poza zakres tego przewodnika.”

        Pozdrawiam :-)

    • Chodziło o to, że nie jest tam napisane co z tym analitykiem zrobić, gdzie go umiejscowić. Stąd tyle pytań, różnych pomysłów i rozwiązań.

      BABOK Guide to zbiór dobrych praktyk. One są dość ogólne. Nie ma tam ścisłych reguł.

      A co w tym artykule jest po ciemnej stronie mocy?
      Jak jest chęć rozmowy o analizie to zapraszam na kawę 🙂

  2. Ciekawy art. Nie wiem po co te akademickie rozkminki w komentarzach. Agiele i to branie tego co działa i usuwanie tego co nie działa. Artykuł przedstawia różne koncepcje albo idąc dalej jest do inspiracją to przemyślenia tego. Jeżeli w iteracji i po retrospekcji okazuje się ze analityk w zespole bardziej przeszkadza niż pomaga dowozic kod to się go w ogóle usuwa. Jeżeli developerzy świetnie sobie radzą jako analitycy to tą rolę przejmuje developer. Jeżeli business owner świetnie radzi sobie w roli analityka to nie ma sensu tworzyć jakiegoś dodatkowego bytu. To co szybciej działa a co nie działa wychodzi w retrospekcji. Po co rozmyślać teraz gdzie ma być analityk. W jednym projekcie z danym zespole tu. A w innym zespole w innym projekcie tam. Artykuł daje spektrum możliwości a w komentarzach czytam jakieś madrowanie gdzie powinno być i która metodyka co mówi. W mojej opinii Najlepsza metodyka jest taka która z tego bierze coś z tamego coś innego a ktoś kto zarządza projektem potrafi po każdej iteracji wziąć z różnych metodyk coś co poprawi „velocity” #IMHO.

ZOSTAW ODPOWIEDŹ