Rola analityka w projektach SDN

Jaka jest rola analityka? Czym zajmuje się analityk? Czy analityk jest potrzebny w projekcie? Są to pytania, które dość często pojawiają się w różnych organizacjach, artykułach czy podczas konferencji analitycznych. Odpowiedzi na nie są najróżniejsze w zależności od roli osoby udzielającej odpowiedzi, przyzwyczajeń panujących w organizacji, sposobu zarządzania projektami czy wielkości projektów.

Szukając pracy jako analityk można przekonać się, że zakres obowiązków jakie można wykonywać na tym stanowisku w każdej firmie, a nawet w tej samej firmie, ale przy różnych projektach może być zgoła odmienny. Po pierwsze mówiąc o stanowisku analityka możemy wyróżnić: analityka biznesowego, analityka systemowego i IT.

Jednak i te pojęcia są często stosowane zmiennie, bądź też używane w odmiennym znaczeniu.

Zdarzają się przypadki, że w mniejszych projektach brak jest wyznaczonej osoby na stanowisku analityka, dlatego niektórzy uważają, że taka osoba nie jest konieczna. Jednak prawda jest trochę odmienna, ponieważ to inni członkowie po części pełnią rolę analityka. Bez względu na to czy w projekcie mamy analityka czy nie, konieczne jest opracowanie wymagań, zdefiniowanie procesów biznesowych czy opracowanie wymaganej dokumentacji. Ale bez analityka będzie brakowało dodatkowego spojrzenia czy potrzeby biznesu są dobrze rozumiane przez deweloperów, czy pewne funkcjonalności nie zostały pominięte, a w konsekwencji czy opracowywany produkt jest tym co chce biznes.

Rola analityka w metodach pracy i metodykach zwinnych

Stereotypowa rola analityka w informatyce wywodzi się ściśle z podejścia kaskadowego, innymi słowy Waterfall. Przez to, nawet dziś niestety, jest on cały czas utożsamiany z etapem analizy i obszerną dokumentacją jaką trzeba wykonać przy tym sposobie zarządzania projektem. Ustalenia z klientem, które powinny być niezmienne oraz długi czas wdrażania nowych rozwiązań spowodowały, że projekt robił się nieopłacalny i mało elastyczny. Nowsze podejścia do prowadzenia projektów, te „bardziej zwinne”, starają się odpowiadać na tego typu problemy. Stąd też zminimalizowano rolę dokumentacji, nacisk położono na pracę i dostarczanie rozwiązania tak, aby klient mógł widzieć efekty pracy od pierwszego stadium i uczestniczyć w jego tworzeniu. Jednak czy to oznacza, że każdy projekt można tak realizować? Często podawaną metaforą przy tym pytaniu jest budowanie mostu. Ponieważ nikt chyba nie wyobraża sobie budowania go bez „pełnej” bardzo szczegółowej dokumentacji, która przewiduje od samego początku użycie materiałów, które będą odpowiednie. Tak czy inaczej w świecie IT standardowe metody odchodzą do lamusa. Więc co z analitykiem?

W teoretycznych aspektach metodyki Agile analityk nie zginął, tylko jego rola jest inaczej postrzegana. Tak jak przy standardowym podejściu analityk był często mylony ze skrybą, który ma stworzyć 500 stron dokumentacji, tak przy technikach zwinnych została określona jasno jego odpowiedzialność.

Źródło: Role projektowe AgilePM SDSM Consortium [6]

DSDM (Dynamic Systems Development Method) pokazał rolę analityka jako pomost pomiędzy częścią biznesową a częścią techniczną (jedyny punkt na bałwanie według DSDM, który ma dwa kolory) oraz połączenie poziomu zarządzania projektem z zespołem wytwórczym (połączenie głowy z tułowiem). Można powiedzieć, że rola ta staję się kręgosłupem projektu, który ma za zadnie pogodzić ze sobą wiele różnych światów (co można przełożyć na wiele odmiennych potrzeb różnych zespołów i grup użytkowników).

DSDM umiejscowił analityka bardziej przy zespole developerski natomiast AgileBA promuje analityka poza zespołami jednak nie ogranicza zmienności funkcji. Tak więc w praktyce można rozróżnić kilka roli analityka, opisanych poniżej.

Analityk jako Pomocnik Product Ownera
W praktyce analityk wspiera w przygotowaniu historyjek użytkownika i zarządzaniu backlogiem produktowym, zbiera informacje i pomaga układać plan realizacji. Współpraca z Product Ownerem w tym przypadku musi polegać na bieżącej synchronizacji informacji, ponieważ nie można doprowadzić do sytuacji, aby każdy z nich miał swoją wersję prawdy.

Analityk jako członek zespołu Scrumowego
Analityk realizuje tutaj w pracę w sprintach co powoduje nałożenie ograniczeń czasowych na wykonywaną przez niego pracę, która może na tym ucierpieć. Szybciej nie znaczy lepiej. Przeprowadzana analiza musi też być na tyle granularna, aby praca nad nią zmieściła się w danym sprincie. Przy tym podejściu zaleca się, aby analityk wychodził też ze swojej głównej roli i aby podejmował się innych zadań jak np. testowaniu lub czasem nawet kodowaniu. Niewątpliwie plusem jest bliskość pracy z developerami i stały kontakt z nimi.

Analityk poza zespołem Scrumowym
Będąc niezależnym ogniwem od procesu wytwarzania oprogramowania analityk ma większe możliwości badawcze oraz jest w stanie lepiej zrewidować swoją analizę. Nie jest obarczony tak mocno zakresem czasowym jakie wymuszają kilkutygodniowe sprinty. Niestety w tym wypadku największym minusem jest brak ścisłej współpracy z developerami i dobrego zrozumienia ich potrzeb.

Analityk jako Produkt Owner
Analityk w swojej naturalnej roli odpowiada za wartość rozwiązania dostarczanego dla interesariuszy, posiad wiedzę merytoryczną, zna potrzeby, wymagania i problemy, którym budowane rozwiązanie musi sprostać. Dlatego też w praktyce w sposób naturalny to on najczęściej przejmuje rolę Product Ownera, jeśli zajdzie taka potrzeba. Uzyskana decyzyjność, która określa się w postaci ułożenia zadań w backlogu, priorytetów i kolejności ich wykonywania daje możliwość jak najszybszego dostarczenia wartości w budowanym rozwiązaniu. Dodatkowo dobry analityk cechujący się wysoką facylitacją naturalnie wchodzi w rolę Product Ownera i dzięki temu uwzględnia interesy wielu grup użytkowników, buduje relacje z nimi, rozmawia i negocjuje.

Analityk w projektach Badawczo-Rozwojowych SDN
Jak widać z powyższego, w każdym projekcie rola analityka jest funkcją zmienną i nie ma jednej, ściśle utartej pozycji. Każdy projekt musi ustalić ją sobie wewnętrznie i wyznaczyć osoby, które będą realizowały ogólnopojętą analizę. W projektach SDN, aby zapewnić jak najszerszy zakres w kompetencyjny, analitycy wraz z architektami stworzyli grupę, która jednocześnie jest oddzielnym zespołem (porównanie do „Analityka poza zespołem Scrumowym”) oraz jest wsparciem dla Product Ownera (porównanie do „Analityk jako pomocnik Product Ownera”), a obszar w jakim się poruszają (oznaczony na zielono) przedstawia poniższy rysunek, który pokazuje go w nałożeniu na proces wytwórczy.

Obszar pracy analityka w projekcie SDN

Analitycy wraz architektami w projektach SDN są osobami odpowiedzialnymi za przygotowanie materiału na podstawie, którego możliwa jest implementacja danej funkcjonalności przez deweloperów. Pierwszym zadaniem analityka względem danej funkcjonalności jest opracowanie wymagań, na podstawie których możliwe jest stworzenie opisu wysokopoziomowego rozwiązania przez architekta. Bazując na opisie wysokopoziomowym kolejnym zadaniem analityka jest opracowanie historyjek użytkownika (ang. user story, US) oraz uzupełniających je przypadków testowych (ang. test case), które są przydatne do stworzenia przez architekta opisu niskopoziomowego rozwiązania, tworzonego łącznie z zespołem deweloperów.

Produkty pracy analityka i ich relacje

Opracowywanie wymagań

Jest to pierwsze zadanie wykonywane podczas realizacji danej funkcjonalności. Aby prawidłowo zrealizować produkt konieczne jest poznanie potrzeb biznesu, co chcemy osiągnąć. W tym celu opracowywane są wymagania. Mowa tutaj o wymaganiach funkcjonalnych i niefunkcjonalnych.

Wymagania te są często uzupełnieniem, uszczegółowieniem wymagań biznesowych, które opracowywane są przez Product Ownera. Opracowanie wymagań prócz zebrania potrzeb biznesu często wymaga również zapoznania się z daną funkcjonalnością, ponieważ przedstawione potrzeby biznesu nie zawsze uwzględniają cały wymagany zakresu, który jest oczekiwany przez biznes i będzie konieczny do realizacji. Opracowane wymagania muszą być spriorytetyzowane. Do tego celu wykorzystywana jest metoda MoSCoW (Must, Should, Could and Would)[1].

Opracowywane wymagania dotyczą często całości danej funkcjonalności, która jest realizowane w kilku iteracjach (w ramach kilku epików), dlatego wymagania oznaczane są którego wydania, epiku dotyczą. Dodatkowo wymagania weryfikowane są zgodnie z określonym dla projektu MVP (ang. Minimum Viable Product).

Wymagania weryfikowane są przez architektów, którzy na ich podstawie tworzą opis wysokopoziomowy rozwiązania.

Opracowywanie historyjek użytkownika

Opracowana przez architektów wizja rozwiązania dotyczy pełnej jego funkcjonalności. Niestety na tej podstawie często ciężko jest dokonać wyceny czasochłonności prac związanych z realizacją danej funkcjonalności, czy zdefiniować zadania deweloperskie jej dotyczące. W celu ułatwienia zrozumienia danego problemu (wymagania) oraz wskazania możliwości podziału na części oraz kolejności ich wykonywania opracowywane są historyjki użytkownika (ang. user story).

Zgodnie z definicją historyjki powinna ona spełniać następujące kryteria:

• Independent – niezależność,
• Negotiable – negocjowalność,
• Valuable – wartościowość,
• Estimatable – ocenialność,
• Sized correctly – dobry rozmiar,
• Testable – testowalność.

W przypadku historyjek opracowywanych w ramach projektów SDN, większość z tych cech jest spełniana, jednak nie wszystkie. Odstępstwa te wynikają z chęci jak największej użyteczności opracowanego materiału oraz chęci zachowania pozostałych kryteriów. Opracowywane historyjki bardzo często zależne są od pozostałych, w celu zachowania ich odpowiedniego rozmiaru, tak aby ich realizacja był możliwa w trakcie jednego sprintu (2 tygodnie).

Dla każdej historyjki użytkownika definiowane są kryteria akceptacji, czyli lista wymagań i warunków do spełnienia, które określają, czy historyjka została poprawnie wykonana z biznesowego punktu widzenia. Prócz kryteriów akceptacji przy opisie historyjek opisywane są również:

• powiązanie z wymaganiami – odniesienie do wymagań, które realizowane są w ramach danej historyjki użytkownika (US), co umożliwia weryfikację czy wszystkie określone wymagania dla danej funkcjonalności zostały pokryte w ramach historyjek użytkownika;
• warunki wstępne – warunki jakie muszą być spełnione, aby możliwa była realizacja danej historyjki;
• zależność między historyjkami – wskazanie zależności, które historyjki są warunkowe, zależne bądź powiązane z konkretną historyjką; ułatwia określenie kolejności wykonywania zadań dotyczących konkretnych historyjek;
• informacje dodatkowe – wskazanie materiałów, które ułatwią, dodatkowo wyjaśnią realizację danej historyjki;
• zidentyfikowane przypadki testowe – określenie możliwych do wykonania przypadków testowych weryfikujących wykonanie historyjki.

Historyjki użytkownika recenzowane są przez architektów oraz zespół deweloperów zajmujący się daną funkcjonalnością. Historyjki te wymagają zaakceptowania przez deweloperów, którzy na ich podstawie dokonują wyceny czasochłonność realizacji danej funkcjonalności.

Opracowywanie przypadków testowych

Jednym z kryteriów, które muszą spełniać historyjki jest ich testowalność. W celu uzupełnienia opisu historyjek oraz określania jakie dokładnie warunki i wymagania mają być w nich spełnione oraz jakie wyjątki powinny być uwzględnione analitycy opracowują przypadki testowe. Przypadki testowe tworzone są zgodnie ze schematem given – when – then.

Przypadki testowe mają na celu:

• przedstawienie deweloperom realizującym daną funkcjonalność jak powinna się zachowywać w różnych przypadkach, uszczegółowić opis historyjek;
• przedstawić deweloperom testującym rozwiązanie na co powinni zwrócić uwagę, co uwzględnić podczas testowania danej funkcjonalności;
• wskazać Product Ownerowi jakie warunki muszą być spełnione przez daną funkcjonalność.

Podsumowanie

Rola analityka i praca na tym stanowisku nie należy do prostych. Często należy wypracowywać własny system pracy dostosowany do potrzeb konkretnego projektu. Tak też jest to realizowane w projektach SDN. Podział pracy nie jest sztywnym kryterium i często wchodzimy w rolę innych odpowiedzialności. Prócz ram jakie zostały wypracowane wykonujemy wiele czynności związanych z zapoznaniem się z nowymi standardami na rynku, możliwościami ich zastosowania, a także badaniu gotowych rozwiązań. Z całym zespołem badamy, szukamy, weryfikujemy i projektujemy rozwiązanie, które ma na celu dokonać telekomunikacyjnej rewolucji i stworzyć „sieć przyszłości”.

***

1. A Guide to the Business Analysis Body of Knowledge®, Version 2.0, International Institute of Business Analysis, Toronto 2009, http://www.theiiba.org.
2. A Guide to the Business Analysis Body of Knowledge®, Version 3 Public Review, International Institute of Business Analysis, Toronto 2014, http://www.theiiba.org.
3. The National Occupational Classification 2011 (NOC 2011), Human Resources and Skills Development Canada and Statistics Canada, s. 214.
4. Jerzy Leyk: Role analityka biznesowego – standard ITIL versus BABOK.
5. ISCO-08 Draft definitions, ISCO International Standard Classification of Occupations, July 2009, http://www.ilo.org/public/english/bureau/stat/isco/docs/gdstruct08.doc.
6. Agile Buisiness Consortium, Chapter 7: Roles and Responsibilities https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities.