Poprzedni Następny

Rola analityka w projektach SDN

Autorami tekstu są:

 Joanna Głowacka
 Analityk IT rozwiązań SDN EXATEL
Grzegorz Linke, Analityk IT EXATEL Grzegorz Linke
Analityk IT rozwiązań SDN EXATEL

O analityku ogólnie

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.


 t Analityk biznesowy
  • osoba, która wykonuje czynności analizy biznesowej [1] [2]
  • analitycy biznesowi oraz konsultanci systemów informatycznych współpracują z klientami, aby zidentyfikować i udokumentować wymagania, przeprowadzają biznesowe i techniczne studium, projektują, budują, integrują i wdrażają informatyczne rozwiązania biznesowe, a także dostarczają porad w zakresie strategii, polityki, zarządzania, bezpieczeństwa i dostaw systemów informatycznych[3];
  • osoba mająca kompetencje do realizacji działań dotyczących uzgodnień i wspomagania interesariuszy (stron) w zakresie rozwoju oraz funkcjonowania (utrzymania) rozwiązania we wszystkich fazach jego cyklu życia[4]. 

Analityk systemowy

  • osoba prowadząca badania, analizująca i oceniająca wymagania klientów względem IT, procedury lub problemy oraz tworząca, wdrażająca propozycje i rekomendacje, a także planująca i udoskonalająca aktualne lub przyszłe systemy informatyczne [5].

Analityk IT

  • analityk pracujący nad rozwojem oprogramowania i systemów komputerowych. W praktyce jest to stanowisko łączące ze sobą analityka biznesowego i systemowego.

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

 

Zakres prac analityka

 

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ść.

Role projektowe AgilePM SDSM Consortium
Na podstawie: 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
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.

Udział analityka w procesie opracowywania materiałów dla deweloperów
Udział analityka w procesie opracowywania materiałów dla deweloperów

 

 

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.


t
  • Wymagania funkcjonalne opisują funkcje (czynności, operacje, usługi) wykonywane przez system
  • Wymagania niefunkcjonalne opisują ograniczenia, przy zachowaniu których system powinien realizować swoje funkcje. Wymagania te nie dotyczą bezpośrednio konkretnych funkcji aplikacji, ale związane są z niezawodnością, efektywnością i wiarygodnością pracy oraz bezpieczeństwem.

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].


t

Metoda MoSCoW

M – wymaganie musi być spełnione,
S – wymaganie powinno być spełnione, jeżeli jest to możliwe, ale sukces projektu nie zależy od jego spełnienia,
C – wymaganie może być spełnione w projekcie,
W – wymaganie nie zostanie spełnione w projekcie.


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).


t

Treść historyjki przedstawiana jest w postaci:
Jako chcę aby gdzie:

  • Aktor – wskazuje konkretny typ użytkownika
  • Czynność – opisuje co dany aktor zamierza zrobić w systemie
  • Wartość – określa sens implementacji, mówi o dostarczanej wartości

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.


t

Schemat given – when – then:

GIVEN – przedstawia dane, które posłużą jako dane wejściowe, na których testowana metoda będzie działać
WHEN – przedstawia testowaną


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”.

Przycisk kierujący na stronę poświęconą programom SDN EXATEL
Przycisk kierujący na stronę poświęconą rekrutacjom w EXATEL

Źródło:
[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