Agile

Co to jest Scrum: role i zdarzenia w Scrumie (cz. II)

scrum role w scrumie zdarzenia w scurmie

Mogę śmiało powiedzieć, że Scrum to gra zespołowa. Podobnie jak w rugby, każdy ma swoje miejsce na boisku i odpowiednio przydzielone obowiązki, by maksymalizować szansę na zwycięstwo. Tak jak w przypadku organizacji pracy czy terminologii istnieją duże różnice pomiędzy rolami w Scrumie, a tymi znanymi z klasycznych metod zarządzania projektem.

[To druga część serii wpisów o Scrumie. Zobacz poprzedni post: Co to jest Scrum: trzy filary Scruma (cz. I) ]

Na uwagę zasługuje fakt, że w Scrumie nie ma hierarchii ważności. W praktyce oznacza to, że nie występuje pomiędzy członkami zespołu zależność pracownik – przełożony lub junior – senior. Każdy jest istotnym ogniwem w drodze do osiągnięcia celu i ma równą pozycję w trakcie podejmowania decyzji i odpowiedzialnej realizacji zadań.

Role w Zespole Scrumowym

W Scrumie występują trzy specyficzne role:

Product Owner (Właściciel produktu) – pełni rolę reprezentanta klienta. Maksymalizuje wartość produktu i pracy Zespołu Deweloperskiego. Dba o to, by przekazywać jasne oczekiwania i potrzeby klienta/użytkownika. Trzyma stery (backlog produktu), sprawnie zarządzając zadaniami i ustalając priorytety. Wszystko po to, by zespół osiągał założone cele i misje.

Właściciel produktu musi się cieszyć wśród członków zespołu odpowiednim autorytetem. Ważny jest fakt, że Product Owner jest jedyną osobą, która może przekazywać zespołowi wymagania i wskazywać kierunek prac. Zespół nie może też podejmować działań na polecenie innych osób.

Scrum Master – to swoisty przywódca duchowy zespołu i osoba odpowiedzialna za rozumienie teorii Scruma przez zespół oraz przestrzeganie przyjętych zasad. Pomaga członkom zespołu zrozumieć i maksymalizować efekty pracy w oparciu o przyjęte dobre praktyki. Inicjuje i facylituje zdarzenia Scrumowe oraz usuwa przeszkody pojawiające się w trakcie prac zespołu.

Zadaniem Scrum Mastera jest także szerzenie idei Agile w całej organizacji, tak by możliwe było zbudowanie odpowiedniego środowiska dla rozwoju zespołu zwinnego.

Zespół Deweloperski – zespół składa się ze specjalistów w swojej branży posiadających wszystkie niezbędne kompetencje, by z powodzeniem realizować powierzone im zadania. Do cech charakterystycznych Zespołu Scrumowego należy:

  • samoorganizacja – wraz z nabieraniem doświadczenia zespół sam dokonuje inspekcji i adaptacji korygując niedociągnięcia w procesie i usprawniając swoją pracę pod względem produktywności i jakości. Z biegiem czasu zespół powinien być coraz mniej zależny od pomocy z zewnątrz.
  • interdyscyplinarność – w zespole powinny znajdować się osoby, których suma umiejętności i doświadczeń pozwala na dostarczenie wartościowego przyrostu bez konieczności ingerencji osób z zewnątrz. To także cecha indywidualna, mobilizująca specjalistów do samodzielnego poszukiwania nowych ścieżek rozwoju i zdobywania użytecznych kompetencji, przydatnych w pracy całego zespołu.
  • brak tytułowania konkretnych członków zespołu – każdy jest deweloperem. Likwiduje to pojawiające się często podziały, jak np. w świecie  IT między programistami, a testerami.
  • poszczególni członkowie posiadają specyficzne umiejętności, w których się specjalizują, natomiast finalnie cały zespół odpowiada za efekty (pozytywne i negatywne) wykonanej pracy.

role w scrumie

Zdarzenia w Scrumie

Duży nacisk w metodologii stworzonej przez Jeffa Sutherlanda i Kena Schwabera stawia się na oszczędność czasu i energii zespołu, a także ograniczenie niepotrzebnie wykonywanych czynności. W związku z tym Scrum Guide precyzyjnie ustala 4 zdarzenia, które występują w trakcie iteracji. Wszystko po to, by wyeliminować powielanie dużej liczby spotkań zabierających cenny czas.

Wszystkie zdarzenia w Scrumie mają z góry ustalony timebox, czyli nieprzekraczalne ramy czasowe.

Zdarzenia w Scrumie: Sprint Planning

Pierwszym ze zdarzeń przewidzianych w Scrumie jest Sprint Planning. W przypadku 4 tygodniowego sprintu przewidziane jest 8 godzin, które zespół może poświęcić na zaplanowanie kolejnej iteracji. W trakcie planowania, zadaniem zespołu jest znalezienie odpowiedzi na pytania:

  • Co może zostać dostarczone w ramach Przyrostu będącego rezultatem nadchodzącego Sprintu?  
  • W jaki sposób, niezbędna do dostarczenia Przyrostu, praca będzie realizowana?  

Zespół po przygotowaniu prognozy zakresu zadań, które realnie mogą zostać wykonane omawia z Product Ownerem założenia Sprintu i elementy Backlogu, nad którymi zespół będzie pracował. Zgodnie z przyjętymi zasadami empiryzmu w Scrumie, zespół szacuje wielkość możliwej wykonania pracy na bazie dotychczasowych doświadczeń, czyli wyników i inspekcji poprzednich iteracji. Zakres prac, który może zostać wykonany jest samodzielną decyzją członków zespołu. Zgodnie ze Scrum Guidem tylko Zespół Deweloperski może ocenić, co jest w stanie osiągnąć w nadchodzącym Sprincie.

Oprócz określenia ram pracy w najbliższych tygodniach zadaniem zespołu jest ustalenie w jaki sposób wybrane elementy Backlogu zostaną zamienione na przyrost. Na tym etapie ważna jest współpraca z Właścicielem Produktu, którego zadaniem jest wyjaśnienie wszystkich wątpliwości związanych z nadchodzącymi zadaniami. Aby ułatwić rozpisanie planu na najbliższe dni możliwe jest zaproszenie na spotkanie planningowe inne osoby spoza zespołu, które mogą swoją wiedzą wpłynąć na lepsze zrozumienie tematu oraz przyczynić się do efektywniejszego rozwiązania problemu.

Przed końcem spotkania członkowie zespołu powinni przedstawić zrozumiałą wizję pracy, która umożliwi osiągnięcie Celu Sprintu i dostarczenie oczekiwanej wartości dla użytkownika.

Po co nam Cel Sprintu?

Aby z dobrą energią mierzyć się z nowymi wyzwaniami warto znać kierunek, dokąd się zmierza. Ustalenie Celu Sprintu ma za zadanie zbudowanie świadomości i być drogowskazem dla zespołu w jakim celu jest tworzony Przyrost. Chociaż Właściciel Produktu pozostawia zespołowi wolną rękę, co do sposobu realizacji zaakceptowanego zakresu zadań, to Cel Sprintu stanowi istotną wskazówkę w trakcie samoorganizacji pracy.

Zdarzenia w Scrumie: Codzienny Scrum (Daily Scrum)

Pod terminem Codziennego Scruma kryje się nic innego jak popularne wśród zespołów deweloperskich spotkania daily. Ich istota jest bardzo prosta. To odbywające się każdego dnia, krótkie (według wyznaczonych ram czasowych w Scrum Guide jest to 15 minut) zebrania zespołu developerskiego.

Podczas daily deweloperzy wymieniają się najważniejszymi informacjami dotyczącymi obecnej sytuacji.  Dla utrzymania konkretnego, zwięzłego charakteru komunikacja powinna trzymać się schematu trzech pytań:

  • co robiłem/am wczoraj?
  • co będę robił/a dzisiaj?
  • na jakie problemy natrafiłem/am, które uniemożliwiają lub utrudniają dalszą pracę

Nie należy mylić Codziennego Scruma ze spotkaniami raportującymi status prac przełożonemu. To przede wszystkim sprawne narzędzie poprawiające komunikację w zespole i zrozumienia bieżącej sytuacji w kontekście realizacji Celu Sprintu. To także doskonała okazja do zwiększenia transparentności procesu i przeprowadzenia inspekcji oraz adaptacji (podstawowe wartości Scruma).

Więcej praktycznych informacji na temat Codziennego Scruma znajdziesz w tym wpisie.

Zdarzenia w Scrumie: Przegląd Sprintu (Sprint Review)

Przegląd sprintu to zdarzenie wieńczące każdy Sprint. W jego trakcie zespół Scrumowy wraz z interesariuszami (klienci, udziałowcy, zarząd)  dokonuje inspekcji Przyrostu. Zespół prezentuje wartość dostarczoną w zakończonym Sprincie i wspólnie z osobami zaproszonymi przez Product Ownera określania kierunki dalszego rozwoju.

Nie jest to formalne spotkanie statusowe, a zaprezentowanie dotychczasowych efektów prac mające na celu zebranie informacji zwrotnej pomocnej w dalszych etapach tworzenia wartości dla użytkowników.

Zdarzenia w Scrumie: Retrospektywa Sprintu

Zatrzymaj się, weź głęboki oddech, pomyśl i działaj dalej. Tak w skrócie mógłbym opisać spotkanie retrospektywne Sprintu, które (moim zdaniem) jest najważniejszym w drodze kształtowania zwinności i podejścia empirycznego w zespole.

Retrospektywa to czas do wspólnego zastanowienia się nad tym:

  • co działo się w ostatnim Sprincie,
  • jak wyglądały relacje między ludźmi,
  • czy stosowane narzędzia i procesy wpływały pozytywnie czy negatywnie na pracę,
  • co sprawdziło się w trakcie działania, co można ulepszyć,
  • w jaki sposób można wprowadzić usprawnienia w życie

Zmiany i usprawnienia mogą zostać wdrożone w każdym momencie Scruma. Jednak to retrospektywa jest formalnym momentem, który pozwala skoncentrować się na elementach inspekcji i adaptacji, na których opiera się ta metodyka.

O retrospektywie pisałem więcej w jednym z poprzednich wpisów na blogu.  Zobacz też mój artykuł opublikowany na Product Vision i dowiedz się, jakich błędów unikać podczas przeprowadzania retrospektyw.

***

W kolejnym artykule przedstawiłem najważniejsze informacje na temat artefaktów w Scrumie oraz czym jest Definicja Ukończenia i dlaczego jest taka ważna w pracy zespołowej. Przeczytasz go tutaj!

Tymczasem, jeżeli spodobał ci się ten post to udostępnij go znajomym 🙂

You may also like
Scrum scala zespół i ułatwia samodoskonalenie – Marta Smyrska o wdrażaniu Scruma w agencji PR
daily scrum
Daily, czyli 3 pytania, które zaoszczędzą kilka godzin pracy

Leave Your Comment

Your Comment*

Your Name*
Your Webpage