Zwinny analityk biznesowy. Zestaw dobrych praktyk AgileBA

Nadszedł czas na przedstawienie kolejnej nowości 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 świeży podręcznik AgileBA. Nowa publikacja jest zgodna z kolorystyką poprzednich publikacji DSDM, co od razu sugeruje jej mocne powiązanie z innymi produktami konsorcjum. Kolor żółty ma podkreślać „apetyt” analityk do zarządzania wymaganiami.

AgileBA oferuje bogate kompendium wiedzy, ukierunkowane pod konkretną rolę Analityka biznesowego. Całość przedstawiona w obszernym kompendium 224 stron podręcznika.

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.

Szerokie spojrzenie na projekt z perspektywy analityka.

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,
• SWOT,
• TOWS,
• Value chain,
• Lean thinking,
• McKinsey 7S Model,
• Balanced ScoreCard (BCS),
• 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 kulturze organizacyjnej, współpracy, a nie na konkretnych narzędziach czy technikach. Te same narzędzia mogą być jak najbardziej wartościowe (użyte wprost lub dostosowane) 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 (dobrze znana rola ze Scruma)? Otóż nie do końca, gdyż w każdy w Scrumie jest odpowiedzialne za analizę czy pisanie kryteriów akceptacji (które nie są częścią Scruma) w tym też zespół Deweloperski!

Jednak rola PO nie występuje w DSDM / AgilePM. Product Owner, to typowa rola w Scrumie, ale nie w metodach konsorcjum DSDM. Najbliższym odpowiednikiem PO jest Business Ambasador. Jest to rola biznesowa, która jest integralną częścią każdego zespołu wytwórczego (Solution Development Team). Każdy zespół SDT posiada dokładnie jednego Ambasadora. Business Ambassador pracuje na poziomie pojedynczego zespołu, natomiast Analityk biznesowy wspiera kilka zespołów, wspierając synchronizację oraz spójność wymagań. Analityk działa również 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ć. A już na pewno bez obserwacji zespołu w pracy i rozmowy z nimi… Na tym etapie możemy tylko teoretycznie dywagować… 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ę. Stąd też DSDM, znany również jako „Agile w krawacie”, znacznie łatwiej adoptuje się do środowiska korporacyjnego niż Scrum. Co jest zarówno wadą i zaletą. Skoro jest łatwo adoptowalny, oznacza to, że organizacja / firma nie musi zmieniać się znacząco i przechodzić procesy transformacyjne a jedynie przemapować już obecne role w organizacji na role z metody DSDM. Niestety jest to droga na skróty… Zdecydowanie jest to temat na odrębną publikację…

“Nie możemy rozwiązywać problemów używając takiego samego schematu myślowego, jakim posługiwaliśmy się w trakcie ich pojawienia się.”

Albert Einstein

Cykl życia wymagań w projekcie DSDM.

Jednym z kluczowych zestawów informacji w każdym projekcie jest uzasadnienie biznesowe (mimo to w świecie zwinnym lub lean zdecydowanie częściej stosuje się hipotyzy i MVP). Jednak projekty zwinne również mogą posiadać uzasadnienie biznesowe. W DSDM, 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 od kogo ma analityk ma pozyskiwać informacje, w celu stworzenia 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.

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 zakorzeniona 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. W samym, czystym Scrumie jest to oczywiste.

AgileBA polecam szczególnie tym, którzy chcą zrozumieć styl pracy analityka w projektach prowadzonych zgodnie z DSDM lub AgilePM lub dla tych są chcą skonfronotwać swoją wiedzę i doświadczenie z tym co oferuje konsorcjum DSDM..

Na koniec spójrzmy na aktualny rok 2015 portfel produktów w ofercie konsorcjum DSDM. Czy tylko ja mam przemyślenia, że małymi krokami rośnie nam pokaźnych rozmiarów portfel dobrych praktyk? Lata pokażą. Póki, co wizja jest obiecująca.