Daily Scrum (pol. Codzienny Scrum) to wydarzenie zespołu deweloperskiego, którego celem jest uwspólnienie wiedzy na temat wykonywanej pracy, zaplanowanie jej na dalszy okres oraz zidentyfikowanie problemów, które uniemożliwiają wypełnienie Celu Sprintu. Codzienne spotkanie synchronizacyjne spotykamy również w Kanbanie lub innych zwinnych sposobach pracy.
Cel wydarzenia
Niezależnie w jakiej metodyce czy framework’u pracuje zespół, spotkanie to powinno odbyć się codziennie. Rozwinięcie jego głównych celów to:
- uspójnienie wiedzy – spotykając się zespół ma okazję do podzielenia się wiedzą domenową (produktową) oraz użytymi technologiami. Nie wszyscy w zespole mają tę samą wiedzę w zakresie funkcjonowania obecnego produktu, w związku z tym mogą być ciekawi jaką nową funkcjonalność tworzą i na jakim biznesowym etapie ona jest. Poza tym może przy okazji tworzenia czegoś nowego zespół dotyka nowych dla siebie technologii,
- zaplanowanie dalszej pracy – wysłuchanie wszystkich zainteresowanych i przejrzenie aktualnego stanu prac powinno prowadzić zespół deweloperski do ustalenia zakresu prac na najbliższy okres. Zazwyczaj są to 24h (Scrum),
- znalezienie potencjalnych problemów – czy brak ruchu na tablicy z zadaniami jest problemem; czy fakt, że dany członek zespołu nie wykonał żadnej pracy w minionym okresie lub jej nie planuje jest problemem?; Czy brak wiedzy domenowej lub w zakresie używanej technologii jest problemem?; Czy jest jakiś wpływ na realizację Celu Sprintu wynikający z tego, że nie udało się zrealizować zadania, które zespół planował skończyć? To tylko przykładowe pytania, które mogą prowadzić do identyfikacji faktycznych problemów.
Spotkanie to występuje w różnych metodykach i jest ono obowiązkowe lub nie. Skupię się tutaj na dwóch najbardziej popularnych – Scrum i Kanban.
W Scrum spotkanie nazywa się Daily Scrum, czasem potocznie nazywane jest jako Daily StandUp. Ta nazwa pochodzi od techniki skrócenia czasu trwania spotkania. Mike Cohn w udzielonym wywiadzie dokładnie wyjaśnia dlaczego jej używamy i na czym ona polega.
Drugą metodą jest Kanban. Nie ma wymogu formalnego, aby w tym frameworku stosować to spotkanie. Kanban daje dowolność stosowanych w nim wzorców postępowania, Daily Standup jest jedną z praktyk, którą wiele zespołów kanbanowych stosuje, jeśli widzą w nim wartość dodaną
Struktura
Oryginalna, rekomendowana ale nie narzucana przez Scrum Guide struktura spotkania to odpowiedź na trzy podstawowe pytania:
- Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
- Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
- Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?
Dla mnie osobiście są to pytania wychodzące od osoby. Czyli każdy członek zespołu po kolei odpowiada na trzy wymienione pytania. Jest bardzo cienka granica między Daily z poprawnym stosowaniem tych pytań (kiedy zespół faktycznie przy takiej strukturze potrafi zaplanować pracę na najbliższy okres oraz identyfikuje występujące problemy), a spotkaniem statusowym, raportującym np do kierownika lub Product Ownera nie wnoszącym żadnej wartości dodanej, traktowanym raczej przez zespół jak status, a może bardziej jak spowiedź.
Inna strukturą rekomendowaną przeze mnie jest wyjście nie od osób, ale od elementów Rejestru Produktu (ang. Product Backlog). Czyli zespół spotyka się codziennie po to, aby faktycznie porozmawiać o zadaniach i nie do końca w centrum zainteresowania są osoby w zespole, ale zadania będące na tablicy. Innymi słowy patrzymy jakie zadania są aktualnie “w trakcie” (szeroko rozumianego “w takcie”, ponieważ code review, testy i inne kroki procesu również traktuję jako zadania w produkcji) i omawiamy je po kolei odpowiadając sobie na pytanie, co możemy jako zespół zrobić, aby jak najszybciej “przepchnąć” zadanie do “Done”. Jeżeli do tego podejścia dodany aspekt Lean’owy, czyli:
- patrzenie na tablicę od prawej strony (omawianie zadań będących bliżej zakończenia prac),
- nie zaczynanie nowych zadań, jeżeli nie zakończymy bieżących (“Stop starting, start finishing”),
- limitowanie pracy w toku,
to będziemy mieli Daily, które daje wartość, faktycznie na którym rozmawiamy o problemach (np “to zadanie już wczoraj było w tym statusie- dlaczego nadal w nim jest?”) oraz przybliżamy się jako zespół do realizacji celu sprintu (Scrum) czy upłynniania przepływu zadań przez nasz proces (Kanban).
Kto powinien w Daily uczestniczyć?
W Daily powinien uczestniczyć przede wszystkim zespół deweloperski. Jest to spotkanie dla niego, ponieważ, jeżeli rozpatrzymy Scruma, to Product Owner na początku danego sprintu uzgadnia z zespołem czym się on zajmie w nadchodzącej iteracji. Czyli cała odpowiedzialność za dostarczenie na koniec sprintu gotowego, potencjalnego do wydania przyrostu (ang. potentially shippable increment) spoczywa na zespole deweloperskim.
Patrząc na Kanbana i zakładając, że zespół codziennie się spotyka, odpowiedzialność za realizację zadań, “upłynnienie” procesu pracy (ang. flow) również jest na zespole deweloperskim. Więc również w tej metodyce spotkanie jest dedykowane dla zespołu.
W obu przypadkach Product Owner (w Kanbanie jeżeli występuje taka rola) może, ale nie musi w spotkaniu uczestniczyć. Z uczestnictwem tej roli w spotkaniu wiążą się za i przeciw. Podstawowe argumenty przemawiające “za” to m.in. obecność Product Ownera. Można z nim porozmawiać, zadać na bieżąco pytanie doszczegławiające dane zadanie. Przeciw takiej sytuacji przemawia ryzyko zamienienia się spotkania dedykowanego dla zespołu w spotkanie statusowe. Wyobraźmy sobie sytuację, że zespół nie rozmawia między sobą jak wypalić/zrealizować zadania, ale zaczyna raportować swoją pracę skupiając się przede wszystkim na części “co udało mi się do teraz zrobić”.
W Scrumie występuje jeszcze rola Scrum Mastera (SM). Według Scrum Guide, osoba w tej roli powinna zapewnić, że spotkanie występuje. Zapewnić znaczy, że Zespół Deweloperski spotyka się w ramach Codziennego Scruma oraz SM uczy ich jak utrzymać piętnastominutowe ograniczenie czasowe. Scrum Master także może dopytać zespół, czy faktycznie zrealizują dany sprint (kciuk w górę, kciuk w dół albo pokaż prawdopodobieństwo na palcach jednej dłoni).
Podsumowanie
Daily jest na pewno jednym z najważniejszych spotkań zespołu deweloperskiego, ponieważ pomaga w istotny sposób zarządzać bieżącą pracą. Rozmowa o tym co się aktualnie robi, co się planuje w najbliższym czasie oraz jakie występują problemy na pewno pomaga w osiągnięciu tego, co zostało przed zespołem postawione.
Polecamy do posłuchania dwa nagrania Porządny Agile – Porządny Codzienny Scrum i Praktyka codziennego stand-upu