Analityk biznesowy w agile

Nadszedł czas na przedstawienie kolejnego aspektu od konsorcjum DSDM. Tym razem w obszarze zainteresowań znalazła się rola analityka biznesowego, który jeśli już istnieje w projektach zwinnych, to głównie w środowiskach korporacyjnych. Zestaw dobrych praktyk AgileBA wywodzi się z prac ostatnich miesięcy, których wynikiem były metody AgilePM (zwinne projekty) oraz AgilePgM (zwinne programy). Wraz z wprowadzeniem standardów oraz ich obecności na rynku, rola analityka biznesowego, która jest obecna w AgilePM wymagała wyklarowania i jednoznaczności dla nowych osób.

Dzięki uprzejmości konsorcjum DSDM podczas mojej wizyty na konferencji Agile in Business 2015, wpadł w moje ręce podręcznik AgileBA. Nowa publikacja jest zgodna z kolorystyką poprzednich publikacji DSDM, co od razu sugeruje jej mocne powiązanie z innymi produktami konsorcjum. AgileBA oferuje bogate kompendium wiedzy, ukierunkowane pod konkretną rolę Analityka biznesowego. Całość przedstawiona w obszernym kompendium 224 stron podręcznika.

Komu przyda się AgileBA?

Dla wielu zaskakujący może być fakt, poświęcenia ponad 200 stron tylko jednej roli. Roli od dawna istniejącej i znanej w świecie projektowym. Otóż powodem tego jest potrzeba. Niektórzy analitycy biznesowi pracują, tworząc sterty dokumentacji, plików wordowych i excelowych. Precyzując: organizacja, jako wynik ich pracy, oczekuje takich produktów prac. Długofalowo promuje to podejście nie angażowania się w projekt, a podążania za planem.

Analityk to nie tylko komunikacja oraz prezentacja PowerPoint. Od takiej osoby spodziewamy się również standaryzacji wymagań, chociażby w postaci modeli/diagramów, w oparciu o notacje UML czy BPMN. Może się to wydawać zaskakujące, ale w niektórych środowiskach IT pojęcie UML jest wciąż czymś całkowicie nowym (moje prywatne doświadczenie podczas szkolenia dla analityków biznesowych w Kopenhadze; klient korporacyjny). Z taką mentalnością, wchodząc do świata zwinności promującego wizualne zarządzanie, modele, prototypy oraz zbiorową odpowiedzialność zespołu i kreatywność… mogę życzyć jedynie powodzenia.

W mojej opinii AgileBA jest skierowany właśnie do takich osób. Osób pracujących w projektach tradycyjnych, jako analityk (biznesowy czy też systemowy), a które są w trakcie przejścia z tradycyjnego modelu prowadzenia projektów, na zwinny model pracy.

Holistyczne spojrzenie na organizację

Bardzo pozytywnym elementem przedstawionym w AgileBA jest obszerny zakres pracy analityka. Otóż obejmuje on nie tylko wykonanie pracy związanej z analizą potrzeb/życzeń/chęci i zamiany ich na sprecyzowane wymagania projektowe. Praca analityka opiera się również na analizie ograniczeń środowiska zewnętrznego oraz wewnętrznego organizacji z którego wydobędziemy ograniczenia projektowe. Podobnie jak w innych  publikacjach dostępnych na rynku, takich jak BABOK V3 czy PMI-PBA, zakres pracy analityka jest bardzo podobny, co potwierdza ogólnoświatową wspólną definicję tej roli.

W AgileBA Przedstawione zostały klasyczne, choć być może nie wszystkim znane techniki do analizy środowiska projektu. Należą do nich: PESTLE, Poter’s 5 Forces, MOST, Resource Audit, SWTO, TOWS, Value chain, Lean thinking, McKinsey 7S Model, Balanced ScoreCard (BCS) czy Power-Impact Grid. Są to klasyczne techniki stosowane w środowiskach korporacyjnych i nie powinny zaskoczyć żadnego doświadczonego analityka. Dlaczego więc są tutaj obecne, skoro AgileBA ukierunkowuje się na pracę zwinną? Odpowiedź jest prosta – bo są to jedynie techniki. Zwinność opiera się przede wszystkim na tym, jak to robimy, a nie czym. Te same narzędzia są jak najbardziej wartościowe w innym stylu pracy.

„IN AGILE WE GO THROUGH THE ADAPTIVE PLANNING APPROACH. EVERY COUPLE OF WEEKS, WE REPLANT ADJUST, BASE ON WHERE WE ARE” – MARTIN FOWLER

Powstaje jednak pytanie, czy aby przypadkiem za analizę i znajomość biznesu nie odpowiada Product Owner? Otóż tak, jednak ta rola nie występuje w DSDM czy AgilePM. Product Owner, to typowa rola w Scrumie, ale nie w produktach konsorcjum DSDM. Najbliższym odpowiednikiem PO jest Business Ambasador. Jest to rola biznesowa, która jest integralną częścią każdego zespołu. Każdy zespół posiada dokładnie jednego Ambasadora. Jednak Business Ambassador pracuje na poziomie pojedynczego zespołu, natomiast Analityk biznesowy wspiera kilka zespołów, dbając o synchronizację oraz komunikację wymagań. Analityk na poziomie organizacji i jego zadaniem jest zrozumienie szerszego kontekstu projektu, m.in. ograniczeń biznesowych, prawnych, technicznych, itp.

Które podejście jest lepsze? Z czy bez Analityka? Bez kontekstu oraz konkretnego przykładu nie da się tego ocenić. Prawdą jest, że wiele większych organizacji (w szczególności korporacji) z naturalniej potrzeby, wynikającej ze skali projektów, wytworzyło taką rolę. DSDM, znany również jako „Agile w krawacie”, jest w pełni adoptowany do środowiska korporacyjnego. Metoda posiada rolę analityka już od początku jej istnienia.

Zwinne uzasadnienie biznesowe

Jednym z kluczowych zestawów informacji w każdym projekcie jest uzasadnienie biznesowe. Podobnie projekty zwinne posiadają uzasadnienie biznesowe, które często wywodzi się z wizji projektu i jest ono stopniowo rozwijane, wraz z rozwojem projektu. Jak można podejrzewać w tym miejscu AgileBA przedstawia cykl życia projektu DSDM, co do którego prezentowany jest proces w ramach którego „dojrzewa” uzasadnienie biznesowe.

W dziale Stakeholders in the Agile Project zostały szczegółowo omówione zależności między Analitykiem, a pozostałymi rolami. Pozwala to na wyklarowanie, jaki typ informacji oraz od kogo ma agregować analityk, w celu stworzenia pełnego spisu wymagań projektowych. Szczegółowo została opisana praktycznie każda z ról obecnych w DSDM wraz z ich wpływem na pracę analityka.

Dział Requirements and User Stories daje wskazówki, jakie cechy charakteryzują dobrze opisane wymaganie. Opisana została różnica między Tematami, Epikami i Historyjkami Użytkownika oraz ich rozwój poprzez kolejne fazy cyklu życia projektu DSDM. Ciekawym dodatkiem jest zestaw dobrych porad dla zwinnego analityka, które pojawiają się pod koniec działu. Pod kątem formy oraz przeznaczenia, przypominają one spis zaleceń dla kierowników projektów AgilePM, które możemy spotkać w podręczniku AgilePM.

W kolejnym dziale została omówiona priorytetyzacja wymagań. Klasycznie pojawia się tutaj model Kano, technika MoSCoW, czy mniej znana technika „Will, Want, Wow”. W skrócie, trzy proste techniki, które pomogą określać priorytet wymagań, który ma być powiązany z wartością jaką dostarcza dane wymaganie.

Działy opisujące Warsztaty Facylitowane oraz Modelowanie, dostarczają kluczowej wiedzy jak, kiedy oraz na jakim poziomie szczegółowości przeprowadzać warsztaty oraz tworzyć modele (nie tylko w oparciu o notację UML czy BPMN). W mojej opinii warsztaty oraz modelowanie są kluczowymi narzędziami każdego analityka. W szczególności, że warsztatami zajmie się analityk biznesowy, natomiast analityk systemowy naturalnie w znacznej mierze będzie realizował swoją pracę poprzez tworzenie modeli w celu ułatwienia komunikacji między osobami technicznymi.

Interaktywna mapa myśli AgileBA

Przygotowałem dla Was interaktywną mapę myśli, która zbiera wszystkie najważniejsze informacje o AgileBA. Znajdziecie w niej informacje o filozofi i pryncypiach DSDM, technikach AgileBA, zwinnym business case, podejściu do wymagań i udzałowców. Całość podsumowuje 5 najważniejszymi porad dla zwinnego analityka biznesowego. Mapa jest świetną ściągawka przy zapoznawaniu się z AgileBA.

Jak AgileBA ma się do innych pozycji na rynku?

AgileBA jest nowym produktem na dojrzałym rynku. Mamy dostępny już od wielu lat zestaw dobrych praktyk Agile Modeling (AM) od Scotta Amblera (twórcy Disciplined Agile Delivery, obecnie najnowsza wersja 2.0). Jest również dobrze rozpoznawalne na rynku rozszerzenie do BABOK V2 o nazwie Agile Extension to BABOK Guide. Obie pozycje ukierunkowane są na rolę analityka biznesowego i wiele zawartych w nich pozycji pokrywa się lub jest zbieżnych.

W przypadku Agile Extension to BABOK Guide zasadnicza jest perspektywa, z której należy patrzeć na to rozszerzenie. Otóż jest ono oficjalnym rozszerzeniem BABOKa, więc jego zadaniem jest zarazem dostosowanie BABOKa do stylu pracy w zwinnych projektach oraz udowodnienie, że jest to możliwe, a sam BABOK jest kompatybilny z Agilem. Pozycja IIBA jest publikacją mająca na celu zmapowanie zwinnych technik pracy na konkretne procesy oraz aktywności obecne w BABOK. Jednak jest to jedynie (oraz aż) publikacja. Zestaw dobrych praktyk zawartych w tym rozszerzeniu nie jest częścią certyfikacji CBAP oferowanej przez organizację IIBA. Ta certyfikacja jest ukorzeniona w tradycyjnym modelu zarządzania projektami. Natomiast AgileBA jest dodatkowo wspierana certyfikacją w ramach współpracy z firmą APMG International, dzięki której analitycy zwinnych projektów mogą potwierdzić swoje kompetencje.

AgileBA stanowi solidne kompendium wiedzy. Klaruje oraz podkreśla znaczenie roli zwinnego analityka biznesowego. Mimo, że jest on rzadko spotykany w świecie Agilowym, to jednak po przeczytaniu podręcznika powinniśmy zobaczyć miejsce, gdzie taka rola powinna być zaangażowana.

AgileBA polecam szczególnie tym, którzy chcą zrozumieć styl pracy analityka zwinnego w projektach prowadzonych zgodnie z DSDM lub AgilePM.