Autor

Monika Perendyk

Trener, wykładowca, praktyk

Analityk w Scrum

24 maja 2014 • 10 minut

Analityk w Scrum- gdzie go umieścić? Czy w ogóle jest dla niego miejsce? Zanim jednak odpowiemy na to pytanie, sprawdźmy jak to jest w Rugby, gdzie ów „scrum” występuje i to właśnie od tego wszystko się zaczęło….

Jest rok 1986, kiedy Takeuchi i Nonaka publikują swój artykuł: “The New New Product Development Game” w Harvard Business Review, który niewątpliwie przyczynił się do powstania tzw. SCRUM. Mało osób wie, że samo słowo: “SCRUM” zostało zaczerpnięte z terminologii gry rugby.

Wbrew pozorom przyglądając się zasadom gry w rugby można odkryć wiele analogii do zasad rządzącymi podejściem “scrumowym”. Prześledźmy tą analogię odnosząc się od razu do scrum w projektach IT.

Celem gry w rugby jest przeniesienie piłki na pole punktowe przeciwnika, w tym przypadku analogia do IT jest oczywista.
Celem wytworzenia oprogramowania jest dostarczenie Klientowi produktu, który był przedmiotem jego zamówienia. Dalsza analogia wymaga większego skupienia, bowiem samo zdobywanie punktów w rugby z początku wydaje się proste. Jeśli skupimy się na celu, wystarczy przecież, aby zawodnik wykopał piłkę przed siebie, w ten sposób zespół będzie się poruszał do przodu, aż do osiągnięcia celu. Tak jak ma to miejsce w przypadku piłki nożnej. Nic bardziej mylnego. Przewrotność zdobywania punktów w rugby polega na podawaniu piłki do tyłu drużyny, co wymaga od niej samodyscypliny, zaangażowania i współpracy. Sam zawodnik nie jest w stanie osiągnąć wiele, bowiem to drużyna, która niesie piłkę w kierunku pola przeciwnika jest w stanie donieść ją do celu, a tym samym zdobyć punkty.

Zatrzymajmy się na ten moment, aby porównać tą część zasad rugby i scrum. Jeśli naszym celem jest dostarczenie oprogramowania jest dostarczenie Klientowi produktu, który zamawiał, to czym zatem jest piłka? Odpowiedź jest prosta – piłka jest zbiorem wymagań, które musimy donieść jako zespół do celu. Prześledźmy sytuację, o której jest mowa w zasadach gry w rugby, czyli brak skuteczności grania w pojedynkę. Możemy przyrównać tą sytuację do standardowego podejścia do wytwarzania oprogramowania, kiedy zawodnikiem, który wykopuje piłkę jest Analityk. Wykopaniem piłki przez Analityka możemy nazwać przekazanie/opisanie wymagań, a dokładniej ujmując samo skierowanie piłki do celu możemy określić jako wybranie przez Analityka sposobu zrealizowania owych wymagań. Jeśli Analityk posiada wiedzę z zakresu architektury systemu, programowania w określonym języku nie oznacza to jednoznacznie porażki. Podobnie jak w rugby dopuszczalne jest takie zachowanie pod warunkiem, jeśli za zawodnikiem taki stoi cały zespół (dosłownie). Co w przypadku, jeśli zespół nie stoi za takim zawodnikiem? Zazwyczaj sędzia decyduje na uformowanie tzw. “Młyn” ( patrz zdjęcie wcześniej). Co stanie się, jeśli Analityk postanowi sam działać bez znajomości architektury systemu czy języka oprogramowania? Po przekazaniu zespołowi dokumentu, w którym została opisana realizacja wymagań Klienta, albo zespołowi brakuje informacji, bądź może zacząć realizować własne interpretacje zapisów (wiem, wiem niedopuszczalne, ale i takie sytuacje mają miejsce). Co wtedy? Po dostarczeniu Klientowi rozwiązania okazuje się, że nie jest to czego oczekiwał, bo w międzyczasie zmienił mu się np. biznes, a my nie mieliśmy czasu, aby zareagować. Dlaczego? Odpowiem odnosząc się do rugby: ponieważ od kopnięcia piłki w kierunku celu już  nie ma możliwości skorygowania jej lotu. Dopiero po zakończeniu lotu piłki możemy próbować drugiego strzału.

Wspominałam o utworzeniu tzw. “Młyna”, czyli chyba najbardziej rozpoznawalnym elemencie gry w rugby. Tak jak pisałam wyżej sędzia decyduje się na uformowanie młyna po naruszeniu zasad, np. podanie piłki do przodu. Młyn służy również do skoncentrowaniu drużyny w jednym miejscu, co daje zawodnikom możliwość wykonania ataku. Ogólnie ujmując młyn powstaje gdy zawodnicy obu drużyn stroją naprzeciw siebie tworząc 3 rzędy zawodników trzymających się nawzajem. Po sygnale sędziego tzw. “łącznik młyna” (zawodnik z nr 10) wrzuca piłkę w przestrzeń, która utworzyła się pomiędzy zawodnikami z pierwszej linii młyna. W tym czasie “Młynarz” ( zawodnik nr 2) stara się zagarnąć piłkę w tył młyna. Gdy piłka będzie bezpiecznie spoczywać pod nogami zawodników, “łącznik młyna” będzie mógł ją rozegrać.

“Łącznik młyna” nazywany czasem: “bezpiecznikiem w grze ataku“. Łącznik młyna skupia wszystkie informacje, które analizuje, aby móc wybrać kierunek gry. Najważniejszą cechą łącznika młynu nie jest kreowanie gry, lecz dostarczanie piłek zawodnikom. Ponadto jest to zawodnik wszechstrony, dzięki czemu może zrozumieć innych zawodników, jak również pokazywać różne punkty widzenia gry.

“Młynarz” jest tzw. “dynamitem drużyny“, bowiem nadaje tempo drużynie. “Młynarz” ma bardzo ważną pozycję w drużynie. Jego rola jest bardzo precyzyjnie określona. Musi to być osoba, która bierze na siebie całą presję dwóch formacji młyna, w grze powinien być w ciągłej dyspozycji swojej drużyny.

“Filar młyna” jest najcięższym zawodnikiem na boisku, na tle drużyny musi być najsilniejszy. Jego głównym zadaniem jest utrzymanie młyna oraz usuwanie wszelkich przeszkód stojących na drodze do celu ( głównie ze względu na to, że stoi w pierwszej linii ataku).

Młyn to nic innego jak nasz “Scrum”. Powstaje pytanie, jak odnieść role wynikające z zasad gry w rugby do ról jakie zostały opisane w “Scrum” jako: “Scrum Master” czy “Product Owner”, ba (!) jak przypisać role wynikające z kaskadowego modelu wytwarzania oprogramowania do ról scrum, aby zrozumieć zakres swoich obowiązków? Odpowiedzi na te pytania pozwolą na lepsze zrozumienie podstawowych zasad scrum szczególnie dla tych, którzy dopiero się przymierzają do przejścia na zwinne podejście.

Przyjrzyjmy się zatem rolom, jakie mamy w SCRUM:

Product Owner (Właściciel Produktu) –  przede wszystkim rozumie ideę projektu, zatem ma sprecyzowany cel, do którego będzie dążył zespół. Najważniejszym zadaniem właściciela produktu jest zrozumienie wymagań oraz nadawanie im priorytetów. Dodatkowo decyduje o kolejności realizacji wymagań, czy czasie i terminie wydania. Czy od razu nie nasuwa nam się skojarzenie z pozycją, jaką odgrywa Młynarz? To on jest siłą napędową całej drużyny i to on kreuje grę, narzuca taktykę.

Scrum Master ( Mistrz Młyna) – już samo tłumaczenie powoduje wiele nieporozumień. Bowiem patrząc na pozycję w rugby możemy odnieść wrażenie, iż odpowiednikiem scrum mastera jest pozycja: Młynarza. Nic bardziej mylnego. Wg Scrum Mistrz Młyna jest odpowiedzialny za trzymanie się zasad Scrum oraz usuwanie wszelkich blokad uniemożliwiających realizację wyznaczonego celu przez Właściciela Produktu. Taka charakterystyka od razu nasuwa nam skojarzenie z pozycją: “Filar Młyna”.

No dobrze, a gdzie w tym wszystkim Analityk? Najczęściej przypisywany jest do roli właściciela produktu, ze względu na to, że w zadaniach właściciela produktu znajdują się zapisy związane z wymaganiami, co powoduje, że w większości przypadków przypisywany jest do tej roli. W mojej ocenie, oczywiście wychodząc od pozycji rugby najlepszym odpowiednikiem Analityka w Scrum jest pozycja: “Łącznik Młyna”, ponieważ to on jest źródłem informacji (wymagań), które przekazuje do Właściciela Produktu, który może na ich podstawie wskazać, które z nich będą realizowane w jakim czasie, w jakiej kolejności. Dopiero taki podział ról pozwoli nam w pełni zrozumieć i odnaleźć się w zwinnym podejściu myśląc na początku jednak troszkę schematycznie.

Od razu nasuwa się pytanie: Kto powinien być zatem Właścicielem Produktu? Odpowiedź jest bardzo prosta, w zależności od celu jaki chcemy osiągnąć w danym sprincie Właściciel Produktu może się zmieniać, bowiem raz celem może być np. oprogramowanie połączenia dwóch systemów, innym razem celem może być tylko ( albo aż) skonfigurowanie już istniejącej funkcjonalności zgodnie z wytycznymi Klienta.

 

Udostępnij




Aby pogłębić wiedzę po artykule zalecam szkolenie:

Wymagania w Scrum

Zobacz