5 ceremonii Scruma: czym są, cel & wskazówki
Ceremonie Scrum są podstawowym elementem praktyki wdrażania podejścia Agile, czyli sposobu myślenia, który ceni ludzi, funkcjonalne produkty pracy, współpracę z interesariuszami oraz dostosowywanie się do zmian.
Metodyka Scrum i ceremonie Scrum opierają się na Manifeście Agile, w ramach którego funkcjonuje wiele metodyk umożliwiających współpracę i działanie zespołowe, z uwzględnieniem zwinnego sposobu myślenia i manifestu.
Jeśli pracowałeś(-aś) w zespole, w którym mówiono o „wydarzeniach Scrum”, „sprintach”, „porządkowaniu rejestru zadań” i „przeglądach sprintu”, prawdopodobnie pracowałeś(-aś) z zespołem, który próbował działać zgodnie z metodyką Scrum. Pamiętaj, że zwinne ramy pracy to sposób myślenia, a Scrum to metodyka.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Czym są ceremonie Scrum?
Ceremonie Scrum (czasami nazywane wydarzeniami Scrum) to ważne wydarzenia lub elementy metodyki Scrum, które opierają się na zwinnym sposobie myślenia i są często wykorzystywane w tworzeniu oprogramowania lub projektach realizowanych iteracyjnie.
Istnieje pięć konkretnie zdefiniowanych ceremonii Scrum, które szczegółowo omówię w następnej części tego artykułu.
Ceremonie Scrum nie są po prostu spotkaniami organizowanymi dla samego organizowania spotkań. Zapewniają raczej zespołom ramy umożliwiające realizację pracy w uporządkowany sposób, pomagają ustalać oczekiwania, wspierają skuteczną współpracę zespołu i ostatecznie prowadzą do osiągania rezultatów.
Jeśli nie są odpowiednio zarządzane, mogą przepełnić kalendarze i przesłonić wartość, którą mają zapewniać. Jednocześnie sam Scrum, podobnie jak ceremonie Scrum, jest celowo lekki i prosty.
Dowiedz się więcej z naszego przewodnika wideo:
Czym jest 5 ceremonii Scrum?
Gotowy(-a), aby poznać pięć ceremonii i wydarzeń Scrum? Przyjrzyjmy się ich celom, uczestnikom oraz wskazówkom i trikom, które pomogą zwiększyć ich skuteczność.
Warto zwrócić szczególną uwagę na to, że każde z tych wydarzeń ma określone ramy czasowe, konkretny cel i służy całemu zespołowi Scrum. Innymi słowy, istnieją po to, aby umożliwić dostarczanie rezultatów.
Uwaga: przeprowadzanie tych wydarzeń w oderwaniu od siebie nie sprawi automatycznie, że zespół stanie się zwinny, ani nie zagwarantuje, że będzie działał zgodnie z metodyką Scrum. Aby skutecznie stosować Scrum, wydarzenia te muszą być częścią większego, dobrze rozumianego i jasno opisanego procesu.
Powinny ułatwiać rozmowy w ramach zwinnego zespołu, aby umożliwiać realizację zadań. A jaki kierownik projektu nie lubi doprowadzać spraw do końca?
Sprint
Sprint w Scrumie to określony odcinek czasu (zwykle trwający miesiąc lub krócej), w którym pomysły zamieniają się w wartość. Sprinty następują po sobie aż do ukończenia produktu (lub trwają bez końca). Zespoły często mierzą swoją przyszłość w sprintach.
Cel sprintu
Celem sprintu jest wyznaczenie ram czasowych pracy i doprowadzenie do realizacji zobowiązań przez zespoły. Sprinty pozwalają ustalać cele krótkoterminowe, ale konkretne. W trakcie sprintu nie powinno się zmieniać niczego, co mogłoby zagrozić realizacji celu sprintu.
Uczestnicy sprintu
Cały zespół Scrum — właściciel produktu, zespół deweloperski i Scrum Master.
Czas trwania sprintu
Sprint trwa od 1 do 4 tygodni, nie dłużej. To ograniczenie pozwala zespołom rozpocząć pracę i dostarczać przyrostowe postępy bez doprowadzania ludzi do szaleństwa.
Gdy wdrażam Scrum w nowym zespole, często zaczynam od sprintów trwających 1 tydzień, ponieważ zazwyczaj możemy zaplanować pracę z tygodniowym wyprzedzeniem. Bardziej zaawansowane zespoły, zwłaszcza te dostarczające oprogramowanie, często realizują 2-tygodniowe sprinty, aby w ramach ograniczonego czasu mieć więcej możliwości wprowadzania innowacji i testowania.
Przydatne wskazówki
- Sprinty nie są wrogiem ani czynnikiem motywującym. Nie próbuj nakłaniać ludzi do działania ze względu na sam sprint. Zamiast tego motywuj ich do osiągnięcia celu sprintu i dostarczenia przyrostu produktu.
- Zastanów się, kiedy sprint ma się rozpocząć i zakończyć. Sprint powinien rozpocząć się tuż po zakończeniu poprzedniego, dosłownie w ciągu kilku godzin. Czas między zakończeniem a rozpoczęciem sprintu powinien być przeznaczony wyłącznie na przegląd sprintu, retrospektywę i planowanie sprintu; potem wszystko zaczyna się od nowa!
Czy coś jeszcze?
Sprintów nie można wydłużać ani skracać. Sprint można anulować tylko wtedy, gdy jego cel straci aktualność. Sprint może anulować wyłącznie właściciel produktu.
Spotkanie planowania sprintu
Spotkanie planowania sprintu to wydarzenie Scrum zaprojektowane po to, aby upewnić się, że zespół jest przygotowany do wykonania właściwych zadań w nadchodzącym sprincie.
Cel planowania sprintu
Planowanie sprintu pozwala właścicielowi produktu i zespołowi deweloperskiemu przejrzeć uporządkowany według priorytetów rejestr produktu, zwykle w oprogramowaniu Scrum lub oprogramowaniu do zwinnego zarządzania projektami. W ramach serii dyskusji i negocjacji identyfikują oni elementy, których ukończenie zobowiązują się zapewnić do końca sprintu. Odpowiedzialność za to ponosi właściciel produktu.
Uczestnicy planowania sprintu
Zespół Scrum — właściciel produktu, zespół deweloperski i Scrum Master.
Czas trwania planowania sprintu
Długość większości wydarzeń Scrum jest związana z długością sprintu. W przypadku planowania sprintu powinno ono trwać 2 razy tyle, ile trwa sprint (w godzinach).
Przydatne wskazówki
- Epopeje i historyjki użytkownika można podzielić na mniejsze zadania i przypisać je podczas planowania sprintu, aby każdy wiedział, za co odpowiada.
- Zachęcaj zespół do rozpisania zadań, błędów i wszelkich innych elementów, które tego wymagają, podczas tego spotkania Scrum. Powinno to być wydarzenie o wyjątkowo współpracującym charakterze.
- Przed rozpoczęciem planowania sprintu spróbuj określić prędkość zespołu, zakładając, że od pewnego czasu pracujecie zgodnie z metodyką Scrum.
Czy coś jeszcze?
Planowanie sprintu pozwala zespołowi Scrum odpowiedzieć na pytania: „Co możemy dostarczyć w tym kolejnym sprincie? I jak wykonamy tę pracę?”. Pomaga zapewnić przewidywalność i tworzy środowisko sprzyjające współpracy.
Szablony planowania sprintu
W bibliotece szablonów członkostwa DPM znajdziesz agendę, listę kontrolną i wiadomość e-mail do pobrania, które możesz dostosować do potrzeb związanych z planowaniem sprintu w swoim zespole. Ten zestaw pomoże Ci przygotować produktywną i użyteczną sesję planowania sprintu.
Codzienny Scrum (codzienne spotkanie na stojąco)
Codzienny Scrum to okazja dla zespołu do świętowania niedawnych osiągnięć, określenia planu na dany dzień i zidentyfikowania wszelkich blokad w projekcie Scrum.
Cel codziennego spotkania Scrum
To wydarzenie Scrum jest częstą i regularną okazją, podczas której zespół spotyka się, aby komunikować indywidualne postępy w realizacji celu sprintu. Nie jest to aktualizacja statusu, ale powinno uwidaczniać wszelkie przeszkody zespołu.
Uczestnicy codziennego spotkania Scrum
Mistrz Scrum i zespół deweloperski. Właściciel produktu może, ale nie musi uczestniczyć.
Czas trwania codziennego spotkania Scrum
To spotkanie jest krótkie! Nie powinno trwać dłużej niż 15 minut. Łatwiej powiedzieć, niż zrobić.
Przydatne wskazówki
- Organizuj spotkanie o tej samej porze każdego dnia (zazwyczaj rano) i staraj się, aby było ono dla zespołu Scrum jak najbardziej rutynowe.
- Codzienne spotkanie na stojąco nie powinno zostać odwołane, jeśli lider lub mistrz Scrum nie może w nim uczestniczyć. Spotkanie jest dla zespołu — przeprowadźcie codzienny Scrum.
Czy coś jeszcze?
To szybkie sprawdzenie sytuacji, nazywane również codziennym spotkaniem na stojąco lub spotkaniem Scrum, powinno przygotować zespół do pracy w danym dniu, umożliwiając jego członkom synchronizację i budowanie wzajemnego zaufania. Pozwól zespołowi codziennie rozliczać się wzajemnie z realizacji podjętych zobowiązań.
Spotkanie przeglądu sprintu
Spotkanie przeglądu sprintu to wydarzenie Scrum, podczas którego wszystkie prace ukończone w poprzednim sprincie mogą zostać zaprezentowane interesariuszom.
Cel przeglądu sprintu
Pod koniec każdego sprintu przegląd sprintu zapewnia zespołowi deweloperskiemu możliwość zaprezentowania wszystkich ukończonych prac. Pozwala to interesariuszom ocenić produkt lub dostosować go w miarę jego powstawania.
Przeglądy sprintu można przeprowadzać w nieformalny sposób albo w bardziej ustrukturyzowanej formie. Może to zależeć od cyklu życia produktu i planowania wydania.
Uczestnicy przeglądu sprintu
Zespół Scrum — właściciel produktu, zespół deweloperski i mistrz Scrum. W spotkaniu może również uczestniczyć grupa przedstawicieli kierownictwa lub zewnętrznych interesariuszy.
Czas trwania przeglądu sprintu
1 godzina na każdy tydzień sprintu. Sprint trwający 2 tygodnie powinien obejmować 2-godzinny przegląd sprintu.
Przydatne wskazówki
- Właściciel produktu powinien zadawać interesariuszom pytania, zbierać informacje zwrotne, a także udzielać odpowiedzi na wszelkie pojawiające się pytania.
- Informacje zwrotne, które można wykorzystać do podjęcia działań, otrzymane podczas przeglądu sprintu, powinny zostać przekształcone w nowe elementy rejestru produktu w celu późniejszego ustalenia priorytetów i omówienia.
Czy coś jeszcze?
To wydarzenie Scrum, nazywane również demonstracją sprintu, pomaga budować zaufanie między interesariuszami a zespołem Scrum. Jest to najbardziej bezpośredni sposób na zebranie wczesnych i częstych informacji zwrotnych oraz dodanie ich do rejestru sprintu.
Spotkanie retrospektywy sprintu
Retrospektywa sprintu to ostatnie wydarzenie Scrum w sekwencji sprintu, które pozwala zespołowi spojrzeć wstecz na ukończone prace i zidentyfikować elementy, które można ulepszyć w przyszłych sprintach na podstawie zdobytych doświadczeń.
Cel retrospektywy sprintu
Po przeprowadzeniu przeglądu sprintu zespół Scrum potrzebuje czasu na refleksję nad właśnie zaprezentowanymi pracami oraz omówienie sposobów ulepszenia zarówno rezultatu, jak i zwinnego przepływu pracy. Wszystkie informacje zwrotne należy gromadzić i przypisywać w taki sam sposób jak inne epiki lub historyjki, aby zespół Scrum rozumiał, kto odpowiada za poszczególne zadania i kiedy zmiany zostaną wdrożone.
Uczestnicy retrospektywy sprintu
Mistrz Scrum i zespół deweloperski. Właściciel produktu może, ale nie musi uczestniczyć.
Czas trwania retrospektywy sprintu
Zazwyczaj retrospektywy sprintu nie powinny trwać dłużej niż 1,5 godziny w przypadku sprintu trwającego dwa tygodnie. Jeśli sprinty trwają miesiąc, spotkanie nie powinno trwać dłużej niż 3 godziny.
Przydatne wskazówki
- Podczas pracy z zespołami częściowo zdalnymi lub w pełni rozproszonymi korzystaj z aktywnych narzędzi do współpracy, takich jak Mentimeter lub Confluence, aby zachęcić uczestników do udziału bez konieczności wyłączania wyciszenia i udostępniania głosu wszystkim.
- Jeśli pojawi się sugestia dotycząca usprawnienia, zapytaj innych członków zespołu Scrum, czy wszyscy się z nią zgadzają. Jeśli tak, ustalcie, jak to zalecenie zostanie wprowadzone w życie.
Czy coś jeszcze?
Zadbaj o stworzenie środowiska bezpieczeństwa psychologicznego. To nie jest gra w obwinianie. Spotkania te często prowadzą do sformułowania zaleceń dotyczących poprawy oraz ograniczenia ryzyka w przyszłości. Jako Scrum Master pamiętaj o coachingowym wsparciu zespołu, aby przekazywał szczere informacje zwrotne i okazywał szacunek przez cały czas trwania wydarzenia.
Role w Scrumie
Skoro wspomnieliśmy już o kilku rolach w Scrumie, przyjrzyjmy się każdej z nich:
- Właściciel produktu: Ta rola reprezentuje klienta i ogólnie firmę w odniesieniu do produktu, nad którym pracuje zespół. Właściciel produktu zarządza rejestrem zadań i ustala priorytety elementów pracy dla zespołu deweloperskiego. Codziennie podejmuje kluczowe decyzje dotyczące produktu. Przekłada potrzeby klientów na konkretne elementy pracy dla zespołu deweloperskiego.
- Scrum Master: Scrum Masterowie odpowiadają za zapewnienie zespołowi wszystkiego, czego potrzebuje do osiągnięcia sukcesu, w tym za jasne zrozumienie procesu Scrum. Łączą w sobie rolę coacha, doradcy, rzecznika, osoby usuwającej przeszkody, facylitatora i mediatora.
Scrum Masterowie odpowiadają za ustanowienie Scruma zgodnie z definicją zawartą w Przewodniku po Scrumie, ale nie są kierownikami projektu (uważaj na liderów, którzy uważają, że to ta sama rola!) — nie odpowiadają za produkt pracy. Scrum Master nie musi być również konkretną osobą ani pracować na pełen etat! Więcej informacji o różnicach między Scrum Masterem a kierownikiem projektu znajdziesz tutaj. - Zespół deweloperski: Jest to grupa interdyscyplinarnych członków zespołu, skupionych na dostarczeniu działającego oprogramowania lub oczekiwanego rezultatu pracy zespołu. Obejmuje deweloperów produktu, projektantów, osoby zajmujące się zapewnianiem jakości oraz inne osoby pełniące role techniczne, które muszą współpracować przy faktycznym tworzeniu produktu.
Idealnie ta grupa składająca się z 5–9 osób jest w pełni przypisana do jednego zespołu Scrum. W rzeczywistości, szczególnie w agencjach, może to wyglądać nieco inaczej. Zespół deweloperski powinien samoorganizować się i być zmotywowany do dostarczania wartości, a dzięki odpowiedniej facylitacji ze strony Scrum Mastera i właściciela produktu może taki właśnie być.
Każda z tych ról ma wyjątkowy udział w każdym z wydarzeń Scrum. Skutecznie przeprowadzane wydarzenia Scrum dają każdej osobie pełniącej daną rolę doskonałą możliwość osiągnięcia sukcesu.
Dlaczego wydarzenia Scrum są ważne?
Wydarzenia Scrum są sercem metodyki Scrum. Bez tych wydarzeń Scrum może bardzo szybko stać się trudnym do śledzenia i chaotycznym procesem. Jest to szczególnie ważne w przypadku nowych zespołów — zachęcam, aby wdrożyć Scrum zgodnie z opisem w Przewodniku po Scrumie, przeprowadzić kilka iteracji sprintu, a następnie określić, co należy dostosować, aby jak najlepiej dopasować proces do zespołu.
Uwaga: Być może zauważyłeś, że w tym artykule nie omówiliśmy tablicy sprintu (czasami nazywanej tablicą Kanban). Wynika to z tego, że nie jest ona podstawowym elementem żadnego z wydarzeń Scrum. Tablice sprintu są doskonałymi narzędziami, które można wykorzystywać podczas każdego wydarzenia, ale nie są elementem wymaganym.
Praktyczna tabela porównawcza
Masz mało czasu? Sprawdź tę krótką tabelę, aby porównać poszczególne wydarzenia Scrum.
Co o tym sądzisz?
Niezależnie od tego, jakiego oprogramowania do zarządzania projektami używasz ani nad jakim produktem pracujesz, te wydarzenia Scrum mają na celu dostarczanie rezultatów.
Zauważyłem, że spotkania te zapewniają strukturę i przebiegają pomyślnie, gdy cały zespół angażuje się w nie, mając wspólne rozumienie celu każdego wydarzenia Scrum. Przypominam, że Scrum jest strukturą, która pomaga dostarczać oprogramowanie w sposób zwinny.
