{"id":2243,"date":"2021-08-27T19:46:00","date_gmt":"2021-08-27T17:46:00","guid":{"rendered":"https:\/\/agileinstitute.pl\/?p=2243"},"modified":"2021-08-29T19:52:59","modified_gmt":"2021-08-29T17:52:59","slug":"codzienny-scrum-2","status":"publish","type":"post","link":"https:\/\/agileinstitute.pl\/index.php\/2021\/08\/27\/codzienny-scrum-2\/","title":{"rendered":"Codzienny Scrum"},"content":{"rendered":"\n

Celem Codziennego Scrum<\/a>a (ang. Daily Scrum<\/a>) jest inspekcja postępów na drodze do osiągnięcia Celu Sprint<\/a>u, a w razie konieczności adaptacja Rejestru Sprint<\/a>u, czyli reorganizacja zaplanowanej wcześniej pracy. <\/p>\n\n\n\n

Codzienny Scrum<\/a> to 15‐minutowe (niezależnie od długości Sprint<\/a>u) spotkanie dla Deweloperów danego Zespołu Scrum<\/a>owego. Aby nie komplikować, odbywa się ono w tym samym miejscu, o tej samej porze każdego roboczego dnia Sprint<\/a>u. Jeżeli Właściciel Produktu<\/a> lub Scrum Master<\/a> wykonują pracę związaną z elementami Rejestru Sprint<\/a>u, uczestniczą w spotkaniu jako Deweloperzy.<\/p>\n\n\n\n

Deweloperzy mogą zdecydować się na dowolną technikę oraz strukturę tego spotkania. Warunkiem jest jedynie, że Codzienny Scrum<\/a> dotyczy postępów w realizacji Celu Sprint<\/a>u, a jego efektem jest możliwy do wykonania plan na bieżący dzień pracy. Pozwala to lepiej skupić się i poprawić umiejętność  samozarządzania.<\/p>\n\n\n\n

Spotkanie to ułatwia przekazywanie informacji, wskazuje przeszkody, pozwala na szybkie podejmowanie decyzji, a co za tym idzie, ogranicza potrzebę organizowania innych spotkań.<\/p>\n\n\n\n

Codzienny Scrum<\/a> to nie jedyna okazja dla Deweloperów do zmian w planie. Zwykle spotykają się oni w  ciągu dnia, aby bardziej szczegółowo omówić zmiany czy zaplanować od nowa pracę w Sprincie którą jeszcze trzeba wykonać.<\/p>\n\n\n\n

Kto uczestniczy w Codziennym Scrumie?<\/h2>\n\n\n\n

To wydaje się oczywiste – skoro codzienne spotkanie służy Deweloperom, to wszyscy oni powinni w nim aktywnie uczestniczyć. Ale czy napewno? Tak. Spotkanie to jest absolutnie niezbędnym elementem frameworku Scrum<\/a>. Jednak słynne trzy pytania nie są obowiązkowe, a nawet forma spotkania na stojąco (standup) nie jest wymagana. To, co pozostaje niezmienne, to timebox, 15 minut, który zabezpiecza nas przed rozciągłymi dyskusjami.<\/p>\n\n\n\n

Czy Scrum Master powinien uczestniczyć w tym spotkaniu?<\/h3>\n\n\n\n

Scrum Master<\/a>, jeżeli pełni również rolę wytwórczą w Zespole – jak każdy inny deweloper ma obowiązek udziału w spotkaniu. Ale jako Scrum Master<\/a> – powinien jedynie zapewnić, że spotkanie odbywa się codziennie i nie przekracza ograniczenia czasowego. Oczywiście, jeśli potrzebna jest facylitacja – można go poprosić o pomoc w organizacji wydarzenia (szczególnie gdy zespół jest mniej doświadczony).<\/p>\n\n\n\n

A co z Właścicielem Produktu?<\/h3>\n\n\n\n

Choć Przewodnik po Scrumie<\/a> nie mówi wprost, że Właściciel Produktu<\/a> ma zakaz uczestnictwa w Codziennym Scrum<\/a>ie (mówi tylko, że to spotkanie dedykowane Deweloperom), to zdania są mocno podzielone:<\/p>\n\n\n\n

Zdarzyć  się może, że Właściciel Produktu<\/a> jest także przełożonym członków Zespołu Scrum<\/a>owego. Wówczas spotkanie z jego obecnością mogłoby się przerodzić w sprawozdanie dla szefa, co wypaczyłoby sens tego wydarzenia i zaburzało transparentność. To nie jest dobry pomysł.<\/p>\n\n\n\n

Niektórzy stosują zasadę „Może być obecny, nie powinien się odzywać”. Ale jeśli Rejestr Sprintu<\/a> jest uaktualniany na bieżąco, to poza tymi piętnastoma minutami jest mnóstwo czasu, kiedy Deweloperzy i Właściciel Produktu<\/a> mogą się ze sobą kontaktować (o ile oczywiście jest taka potrzeba). Po co więc blokować czas Właściciela Produktu na sztywno?<\/p>\n\n\n\n

Oczywiście jeśli Właściciel produktu<\/a> jest także Deweloperem, to uczestniczy w spotkaniu jak każdy z nich.<\/p>\n\n\n\n

Cele Codziennego Scruma<\/h2>\n\n\n\n

Uwspólnienie<\/u> wiedzy<\/strong> – zespół ma okazję do podzielenia się wiedzą dom<\/a>enową (produktową) oraz stosowanymi technologiami. Nie każdy w zespole ma tę samą wiedzę w zakresie funkcjonowania tworzonego produktu. Ważne jest więc ustalenie jaka nowa funkcjonalność jest tworzona oraz na jakim biznesowym etapie ona jest. Poza tym jest to okazja tworzenia czegoś nowego i zastosowania nowych technologii. Codzienny Scrum<\/a> to ważna okazja do inspekcji i adaptacji. Istotne jest więc aby wszyscy deweloperzy byli na nim obecni. Czyjaś absencja pozbawia Zespół pełnego obrazu. Oczywiście, jeśli przyczyny losowe decydują o tej nieobecności, należy zadbać o przekazanie reszcie Zespołu stosownych informacji.<\/p>\n\n\n\n

Zaplanowanie bieżącej pracy<\/strong> – wysłuchanie wszystkich członków zespołu i analiza aktualnego stanu prac powinno pozwolić deweloperom na ustalenia zakresu prac na najbliższy czas. Zwykle są to kolejne 24 godziny.<\/p>\n\n\n\n

Rozpoznanie potencjalnych problemów<\/strong> – czy problem stanowi brak ruchu na tablicy z zadaniami?; czy fakt, że dany członek zespołu nie wykonał żadnej pracy w minionym dniu lub nie planuje jej – to kłopot?; Czy brak wiedzy produktowej lub w zakresie znajomości niezbędnej technologii jest problemem?; Czy na realizację Celu Sprint<\/a>u ma wpływ to, że nie udało się zrealizować zadania, które zespół planował zakończyć? To tylko przykładowe pytania, które mogą prowadzić do identyfikacji faktycznych przeszkód na drodze do realizacji Celu Sprint<\/a>u.<\/p>\n\n\n\n

Przykładowy plan Codziennego Scruma?<\/h2>\n\n\n\n