Daily (Scrum, standup)- codzienne spotkanie zespołu deweloperskiego [agilestarter]

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.

Zachęcam do zapoznania się również z Anty-wzorcami dotyczącymi Daily Scrum, mówiącymi o występujących na Daily problemach, po czym je poznać i jak sobie z nimi poradzić.

Źródła zdjęć:
flickr.com udostępnione na licencji CC BY-NC-ND 2.0

Komentarze do wpisu: “Daily (Scrum, standup)- codzienne spotkanie zespołu deweloperskiego [agilestarter]

  1. Bardzo ciekawy wpis. U nas powoli odchodzimy od struktury trzech pytań per user, a bardziej staramy się je zadawać (i odpowiadać na nie 😉 w kontekście danego story: co zostało w niej zrobione od wczoraj, co zostanie dziś ukończone, czy jej realizacja napotkała na jakieś problemy. Kolejność: od najważniejszego story (góra), taski od prawej (ukończone i najbliżej ukończenia) – walking the wall/the board. Taka struktura wynikła z tego, że pracowaliśmy w dość sporym zespole, gdzie ciężko było utrzymać skupienie i połapać się na tablicy, kiedy wypowiadało się po kolei wiele osób. W tym podejściu łatwiej też pamiętać o celu sprintu, ustalonych priorytetach i zasadzie „stop starting, start finishing”. Częściej teraz udaje się nam wychwycić, jeśli rozpoczęte są „dolne” story przy nieukończonych „górnych”.

    Daily wykorzystujemy także do poinformowania się wzajemnie o najbliższych planowanych zmianach w dostępności – urlopie, pracy zdalnej, przyjściu później, wyjściu wcześniej itp.

    Z innych technik, to kiedy pojawia się któreś ze sformułowań : „trzeba będzie”, „zrobię to po daily”, „to się pogada”, „potem dodam” – wręczany jest mały żółty kartonik lub post-it, na zasadzie „supełka” na pamięć, żeby postanowienie nie wyleciało z głowy w momencie wyjścia za próg salki, co często się zdarzało.

    Ostatnio kończymy też daily pytaniem – czy wszystko jest jasne? czy plan na dziś jest ustalony?

    • Dawid Lewandowicz

      Dzięki Ewa za komentarz. Faktycznie czasami się zdarza, że ktoś coś zapomni. Nie myślałem nigdy o zaproponowanej przez Ciebie technice w tym kontekście. Spróbuję.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x