menu

// Analityk biznesowy w Scrumie

Która rola w świecie IT jest obecnie jedną z najbardziej pożądanych? To analityk* biznesowy (Business Analyst, BA). Świadczy o tym m.in. częstotliwość sięgania do tematu analizy przez autorów serwisów branżowych i książek czy organizatorów konferencji. Zmienia się świadomość pracodawców, którzy coraz chętniej zatrudniają specjalistów w tym zakresie. Jednocześnie popularność zyskuje też realizowanie projektów w sposób zwinny: w oparciu o metodyki z rodziny Agile takie jak np. Scrum, TDD, BDD, lean.

Co łączy te dwa popularne trendy? Aby odpowiedzieć na to pytanie, przypomnijmy sobie  trochę teorii nt. Scrum.

Role
W projektach realizowanych z użyciem tego podejścia wyróżnia się trzy role. Każda z nich stanowi element niezbędny dla osiągnięcia sukcesu. Członkowie zespołu projektowego zostają przypisani do jednej z ról, otrzymując tym samym określony zakres odpowiedzialności:

– ZESPÓŁ DEVELOPERSKI (Zespół Projektowy) – wycenia zadania i realizuje przyrostowy rozwój projektu w ramach ustalonych iteracji, czyli Sprintów
– SCRUM PRODUCT OWNER (PO) – odpowiada za rozwój projektu i zarządzanie zadaniami (wprowadzanie zmian oraz ich priorytetyzacja)
– SCRUM MASTER – monitoruje procesy i edukuje pozostałych członków w zakresie Scruma

Warto zauważyć, że w metodologii Scrum funkcja analityka biznesowego nie jest uwzględniona. W praktyce jednak coraz więcej firm pracujących w duchu Agile decyduje się na zaangażowanie minimum jednego analityka. Gdzie zatem w tym podejściu znajduje się dla niego miejsce? Co ciekawe, analityk może zarówno pełnić każdą z funkcji zdefiniowanych w ramach Scruma, jak i realizować swoją pracę poza samym procesem.

Analityk w Zespole Projektowym
W tym modelu analityk jest pełnoprawnym członkiem zespołu wykonawczego. Oznacza to, że jego praca jest monitorowana i rozliczana w trakcie Sprintów i może obejmować:

– pracę analityczną – dostarczenie określonej liczby gotowych User Stories do realizacji w przyszłych Sprintach, wykonywanie Spike w ramach rozeznania pewnego tematu
– pracę testerską – testowanie bieżących zadań w Sprincie.

W tym trybie praca analityka musi być bardzo dobrze zaplanowana i monitorowana, nie ma zbytniego miejsca na wykonywanie rzeczy „na boku”. Najważniejszym zadaniem jest realizacja zadań, które cały zespół dostarczający zgodził się dostarczyć w ramach aktualnie trwającego Sprintu.

 Analityk jako Scrum Product Owner
Przy takim podejściu analityk zarówno zarządza zadaniami realizowanymi w ramach projektu/Sprintów, jak również tworzy ich specyfikacje. Takie rozwiązanie ma sens w przypadku projektów wewnętrznych, w których PO nie jest reprezentowany przez przedstawiciela klienta.

Ogromną zaletą takiego podejścia jest fakt, że jedna osoba nie tylko odpowiada na pytania Zespołu Developerskiego. Jest to możliwe z tego względu, że zarządza funkcjonalnościami i ich zakresem w ramach roli Product Ownera. W tym systemie nie jest zatem wymagany dodatkowy narzut czasowy związany z konsultacją na linii analityk-Product Owner. Doświadczenie w obszarze analizy pomaga jednocześnie ocenić, na ile wspomniane pytania – oraz zmiany będące ich następstwem –  znacząco wpływają na aktualnie funkcjonujące rozwiązania. Mowa tak o zmianach złożoności, jak i procesów czy konieczności dodatkowego nakładu pracy.

Na analityku spoczywa zatem duża odpowiedzialność – w końcu to on określa, które funkcjonalności i w jakiej kolejności będą wprowadzane do produktu, a które potencjalnie nie zostaną zrealizowane z uwagi na różne okoliczności (terminy, dostępność ludzi, koszt etc.).

Analityk jako pomocnik Scrum Product Ownera
Model ten często spotykany w ramach projektów, gdzie PO znajduje się po stronie klienta i jego dostępność jest ograniczona dla Zespołu Projektowego. W tym wypadku analityk (określany tu także jako Proxy Product Owner) może podejmować kluczowe decyzje bez konieczności konsultacji z formalnym PO. Oczywiście znacznie ułatwia to pracę zespołu, skracając czas odpowiedzi niezbędnej do realizacji bieżących zadań. W tym przypadku także rola ta wiąże się z dużą odpowiedzialnością po stronie analityka. Zatem powinien on bardzo dobrze znać domenę klienta, jego plany/roadmapę oraz priorytety. Wiedza ta pozwoli trafnie ocenić zakres zmian wynikających z podejmowanej decyzji projektowej i ich zgodność z wizją Product Ownera.

Analityk poza Scrumem
W tym podejściu analityk biznesowy traktowany jest jak każdy inny zewnętrzny doradca/specjalista, który wspiera realizację projektu. Nie realizuje on żadnych specyficznych zadań w ramach Sprintu. Jego rola wiąże się raczej z doradzaniem klientowi, byciem z nim w ciągłym kontakcie i dostarczaniem specyfikacji do zadań dla Zespołu Projektowego. Teoretycznie, w takim modelu analityk nie powinien uczestniczyć w ceremoniach sprintowych (demo, retrospektywa, planowanie). Niemniej w praktyce jego obecność jest mocno wskazana – jest bowiem jednym z „zewnętrznych specjalistów” najbardziej zaangażowanym w projekt ze względu na współpracę zarówno z klientem, jak i z Zespołem Projektowym i/lub Product Ownerem.

(bonus) Analityk jako Scrum Master
Warto wspomnieć, że żadne z powyższych rozwiązań nie wyklucza możliwości pełnienia przez analityka dodatkowej funkcji, czyli bycia Scrum Masterem. Są to na tyle różne od siebie role, że jedna osoba może spokojnie zajmować się oboma obszarami w ramach projektu, tak analizą biznesową i nadzorowaniem procesów, jak i edukacją zespołu w zakresie Scrum.

Co wybrać?
Analizując powyższe podejścia, wyraźnie widać, że nie ma uniwersalnej metody na łączenie roli analityka ze Scrumem. Każda z możliwości ma tyle zalet, co wad. Wybrane podejście jest znacząco determinowane przez czynniki, na które nie zawsze mamy wpływ, jak dostępność klienta i jego zespołu, charakterystyka projektu, doświadczenie zespołu itp.

Doświadczenie pokazuje, że optymalnie jest ustalić zasady współpracy analityka z resztą zespołu realizującego projekt już w początkowej fazie jego planowania, tj. na etapie definiowania składu Zespołu Projektowego lub strategii implementacji poszczególnych funkcjonalności. W idealnym świecie to zespół powinien określić, jak chce współpracować z analitykiem. Koniec końców, według Scrum zespół to samoogranizujący się zbiór ekspertów, którym nie należy narzucać gotowych rozwiązań.

Więcej o rolach w Zespole Developerskim tutaj

*Forma męska stosowana jest dla uproszczenia

// Partnerzy