Analiza w Scrumie

Scrum staje się coraz bardziej popularny w Polskich firmach. Wychodzi z książek i pomaga w rzeczywistych projektach dostarczać szybko wartościowe oprogramowanie. Gdzie w takich projektach miejsce dla analityka? Otóż, jest!

Potrzymam Cię jeszcze chwilę w niepewności i przypomnę jedną ważną rzecz. Zanim podążysz za modą i zapragniesz wszystko robić w Scrumie [:skramie!], zatrzymaj się i pomyśl – „Czy ten projekt nadaje się do Scruma?”. Tutaj znajdziesz kryteria, którymi kierować się w doborze metodyki do projektu: https://analizait.pl/2012/jak-nie-puscic-firmy-z-torbami/.
Zagadkę wykorzystania kompetencji analityka w projektach zwinnych zadawano sobie nie od dziś. W listopadzie 2011 r. dwie organizacje (International Institute of Business Analysis i Agile Alliance) połączyły siły i stworzyły opracowanie – The Agile Extension to the BABOK Guide. Wzięły na tapetę wykorzystanie analizy w metodykach: Scrum, XP Programming, Kanban, opisały też techniki, które kierunkowują analityka na zwinne działanie.

Analityk w Scrumie

No, to do rzeczy. Co ma robić analityk w Scrumie? To samo, co w innych projektach… tyle, że częściej i zwinniej. Co to znaczy?
Przypomnijmy sobie jak wygląda Scrum bez kombinacji: https://analizait.pl/2012/sprint-przez-metodyki-zwinne-agile/. Można to streścić w 4 ważne elementy:

Gdzie w tym cyklu będzie wtrącał się analityk?

Product Backlog. W końcu nikt tak jak on nie zna się na analizie potrzeb organizacji (po co robi oprogramowanie, w czym to pomoże, czy pomoże, co by się przydało). To szczególnie ważne, kiedy robimy projekt zewnętrzny i musimy się wczuć w potrzeby innej organizacji. Łatwiej robić dla siebie (produkt wewnętrzny) lub produkt z półki, gdzie dobrze sprawdzi się Product Owner. Do backlogu wpadają też funkcje po ocenie i walidacji rozwiązania, kiedy zostaną dostrzeżone sposoby na lepsze zapewnienie osiągnięcia wyznaczonych celów.
Sprint. Podczas sprintu ujawnia się wścibska natura analityka, który drąży temat aktualnie opracowywanych funkcji i każdą historyjkę użytkownika odziera z tajemniczości i niejednoznaczności oraz docieka, co musi robić (i jak?) to coś, żeby zostało entuzjastycznie odebrane (kryteria akceptacji). Różnica z innymi metodykami polega na tym, że tu analityk stawia na bezpośrednią komunikację, nie na dokumenty. Informacje przekazywane zespołowi na częstych spotkaniach Scrumowych.

A kiedy ta kombinacja nie działa doskonale…

Bardzo podoba mi się praktyka retrospektyw w Scrumie. Są to spotkania na zakończenie sprintu, na których omawiany jest jego przebieg. Każdy mówi o tym, z czego jest dumny, co go cieszyło, a co boli i podnosi ciśnienie (w negatywnym sensie). Razem szuka się wyjścia, by wszystkim pracowało się sprawniej i żyło lepiej (doskonalenie procesu – piękne słowo).
I tak współdziałnie analityka i zespołu pracującego w Scrumie jest nie tylko możliwe, ale także może stać się wspaniałym doświadczeniem (pod względem szybkości dostarczania i jakości produktu).