Analiza w podejściu zwinnym według BABOK – praktyczna realizacja

Od pół roku mam okazję pracować jako analityk w projekcie, który przechodzi zwinną transformację według BABOK Guide. To wyjątkowe doświadczenie, dające dużo satysfakcji i bardzo rozwijające. Obserwuję, jak przeobrażeniu podlega podejście do realizacji zmian wszystkich zaangażowanych osób, od biznesu do programistów. Nie mniej ważne są zmiany wprowadzane w całej organizacji. Rośnie zrozumienie, że system informatyczny jest tylko jednym z elementów, które składają się na wypracowanie wartości dla biznesu klienta. 

W poprzednim artykule przedstawiłam, w jaki sposób BABOK Guide podchodzi do analizy biznesowej z perspektywy zwinnego wytwarzania oprogramowania. W tym wpisie chcę przedstawić jak w projekcie, w którym pracuję, w praktyce realizujemy wskazówki zawarte w BABOK Guide.

Zanim organizacja zdecydowała się na transformację, zmiany w systemie wprowadzane były iteracyjnie. Tym, co budziło największe niezadowolenie w biznesie, był bardzo długi czas od pomysłu na nową funkcjonalność do jej wdrożenia na produkcję. Czas ten wynosił kilka miesięcy, niezależnie od wielkości zmiany. W największym stopniu było to spowodowane przez czas poświęcony na analizę systemową i uzgodnienia szczegółów zmiany. Te prace były realizowane, zanim zespół wytwórczy przystąpił do implementacji pomysłu.

Role w projekcie według BABOK

Product Owner – zrozumienie strategii

Aktualnie wytwarzanie nowych funkcjonalności jest realizowane przez kilka zespołów pracujących w metodyce Scrum. Nad całością prac czuwa jeden Product Owner, którego zadania koncentrują się na przekazywaniu potrzebnych informacji do zespołów deweloperskich. Product Owner ściśle współpracuje z biznesem i kierownictwem organizacji. Uczestniczy w spotkaniach, na których podejmowane są decyzje co do kierunku i priorytetów zmian całej firmy. Na tych spotkaniach biznes opowiada, jaka jest jego wizja zmiany, jakich korzyści się spodziewa i jakie jest uzasadnienie biznesowe podejmowanych prac. Zdobyte informacje pozwalają Product Ownerowi na odpowiednie, zgodne z oczekiwaniami organizacji, ukierunkowanie prac zespołów. Można powiedzieć, że Product Owner realizuje zadania analityka biznesowego na wysokim poziomie. Zgodnie z BABOK: „Business analysts working on agile initiatives engage with the business sponsor on a strategic level and assist with defining how the proposed product or feature aligns with the organization’s objectives.”

Analityk wiodący – przygotowanie historyjek użytkownika

Konieczność realizacji wielu inicjatyw jednocześnie sprawiła, że w naszym projekcie Product Owner nie jest w stanie jednoosobowo prowadzić realizacji tych zmian w kilku zespołach deweloperskich. Dlatego powołana została rola Analityka Wiodącego, który zajmuje się konkretną inicjatywą. Zadania dla niego są przydzielane przez Product Ownera. On też określa priorytet i termin realizacji zmiany. I co ważniejsze, przekazuje strategiczną wizję, dlaczego zmiana jest realizowana i jakie korzyści są po niej spodziewane. Jak to jest zapisane w BABOK: „They collaborate with various stakeholders and the change team to break the product vision down into a prioritized list of desired work items to be completed”. Lead Analyst spotyka się na warsztatach z interesariuszami, uzgadnia zakres wprowadzanych modyfikacji i sposób ich realizacji.

Rezultatem współpracy jest rozbicie zadania na historyjki użytkownika z przypisaniem im priorytetów oraz wstępne określenie kryteriów akceptacji dla każdej historyjki. Dzieje się to zgodnie z sugestią zawartą w BABOK Guide. Czyli: „Business analysts conduct analysis and deliver work products at the last responsible moment to continually allow flexibility for change; detailed analysis work is not done ahead of time, but just in time to be effectively utilized by the agile team”. Zatem analityk wiodący pracuje nad funkcjonalnościami, które zespół zrealizuje w najbliższych 2-4 sprintach. Jednak zanim zacznie omawiać historyjki użytkownika z zespołem deweloperskim, są one tylko wstępnie nakreślone, nie zawierają szczegółów realizacyjnych. Te zostaną wypracowane wspólnie w ramach prac zespołu. Analityk wiodący jest członkiem zespołu deweloperskiego, dlatego może czuwać nad realizacją prac zgodnie z wizją zmiany przekazaną przez Product Ownera i potwierdzoną na warsztatach z biznesem.

Zdarzenia scrumowe

Product Backlog Refirement – lepsze zrozumienie zmiany

Tu dochodzimy do kolejnego ważnego etapu prac analitycznych, czyli Product Backlog Refirement. W naszym przypadku są to spotkania przede wszystkim zespołu deweloperskiego, a więc również Analityka wiodącego, w których uczestniczy także Product Owner. Ich rola jest taka, jak opisano w BABOK: „During agile initiatives, scope is constantly evolving. This is managed by the backlog list which is continually reviewed and re-prioritized. This process contributes to the refinement and redefinition of scope in order to meet the evolving and emerging business need”. Uczestnicy omawiają historyjki użytkownika, doprecyzowują je, ustalają sposób zrealizowania potrzeby biznesowej i wyceniają koszt wykonania. Niejednokrotnie historyjki są przebudowywane, a kryteria akceptacji ulegają zmianie.

Najczęściej PBR odbywa się bez udziału przedstawicieli biznesu, ponieważ Analityk wiodący powinien znać na tym etapie oczekiwania interesariuszy. Dodatkowo obecność Product Ownera pozwala znaleźć odpowiedź na większość pojawiających się pytań. Zazwyczaj jednak przynajmniej raz dla każdej funkcjonalności, pojawiają się zaproszeni interesariusze, żeby potwierdzić z nimi podejście realizacyjne, które wypracował zespół. Jest to ważny element współpracy z biznesem. Gdyż jak to jest zapisane w BABOK „The sponsor’s active involvement with the agile team is critical to providing the sponsor with the ability to preview and understand the product being developed, as well as allowing an opportunity for the sponsor to provide continuous feedback to the team and adjust the product as needs change”.

Sprint Review – prezentacja dokonań

Ważnym etapem współpracy z biznesem są dla nas także Sprint Review, które odbywają się na koniec każdego sprintu. Na spotkaniu tym „Stakeholders get the opportunity to frequently review the product, which allows them to identify any missed requirements early”. W trakcie spotkania zespół demonstruje zrealizowane funkcjonalności, a osobą prezentującą jest najczęściej analityk wiodący. Pokazuje, w jaki sposób potrzeba biznesowa wyrażona w kryteriach akceptacji zostaje zaspokojona. Zbiera również uwagi od uczestników, co jeszcze należy zrealizować. W tym miejscu ważną rolę odgrywa Product Owner, do którego należy ostateczna decyzja co do priorytetów i zakresu planowanych prac.

Dokumentacja w projekcie – tylko to, co niezbędne według BABOK

Razem z przejściem do zwinnego wytwarzania oprogramowania zmieniło się także w naszym projekcie podejście do tworzenia dokumentacji systemu. Wcześniej była to dokumentacja dosyć „ciężka”, zawierała szczegółowe opisy procesów, ekranów, czy model danych. Taka dokumentacja, chociaż przydatna na etapie utrzymywania systemu, była trudna do pielęgnowania. Wymagała dużej pracy także przy niewielkich zmianach funkcjonalności, a zapoznanie się z nią dla nowych osób było sporym wyzwaniem. Obecnie odeszliśmy od szczegółowego dokumentowania na rzecz lepszego opisywania historyjek użytkownika.

Tak jak sugeruje BABOK Guide: „Models and other analysis and design techniques are typically used informally, and may not be maintained once they have served their purposes. The analysis and design approach used should support progressive elaboration, be adaptable to change based on learning, and not cause the team to select solutions prematurely. Agile teams tend to use user stories at the lowest level of decomposition. Usually supported by acceptance criteria which capture the analysis and design details regarding how the stories should behave when implemented”. Podobny sposób opisywania wymagań, z położeniem dużego nacisku na historyjki użytkownika, stosujemy w Altkom Software & Consulting również w innych projektach, opierając się na opracowanym przez nas szablonie dokumentu „Specyfikacja Wymagań I Architektura Rozwiązania”.

Współpraca z biznesem według BABOK – niezbędna dla sukcesu

Pragnę podkreślić, że zwinne wytwarzanie oprogramowania nie byłoby możliwe bez dobrej współpracy z biznesem. W naszym projekcie przedstawiciele biznesu chętnie biorą udział w warsztatach z Analitykami wiodącymi czy w PBR-ach. Odpowiadają na pytania zgodnie z posiadaną wiedzą, rozstrzygają wątpliwości. Większość aktywnie uczestniczy w demo i udziela informacji zwrotnej co do wytworzonej zmiany. Niekiedy pojawiają się pytania, na które biznes nie jest w stanie odpowiedzieć, często nie ze swojej winy.

I wtedy konieczne jest szybkie podejmowanie decyzji co do zakresu realizowanych prac oraz jest ścisła współpraca w trakcie sprintu. W przeważającej większości przypadków wspólnie realizujemy postawione cele. Dzieje się trochę tak, jak zapisano w BABOK: „For organizations new to the agile mindset and practices, a focus on continuous improvement, ongoing changing behaviour, and making progress enables the organization to move towards culturally adopting the agile mindset”.

W zwinnym podejściu, które teraz realizujemy, jest tak, jak zapisano w BABOK: „Business analysts are active members of an agile team and often facilitate planning, analyzing, testing, and demonstrating activities”. Muszę przyznać, że taki sposób pracy daje dużo satysfakcji. Przede wszystkim z dobrej współpracy z pozostałymi członkami zespołu oraz możliwości rozwijania swoich umiejętności.

Joanna Kępka, Starszy Analityk Altkom Software & Consulting