Mariusz Prowaźnik

o programowaniu w Javie, Scali i Clojure.


O spotkaniach wzorowanych na Daily Scrum

Przez niecały rok miałem przyjemność pracować w zwinnym zespole, który z powodzeniem wprowadził Scrum - w całości. Byłem zaskoczony jak bardzo można poprawić sposób pracy nad projektem IT. Zmieniło się też moje podejście do jednej z praktyk Scrumowych: Codzienny Scrum (ang. The Daily Scrum).

Jest to praktyka wyglądająca na najprostszą do wprowadzenia ze wszystkich praktyk Scrum, dlatego często idzie na pierwszy ogień podczas prób uczynienia pracy zespołu zwinniejszą. No cóż, poprawne przeprowadzenie takiego spotkania rzeczywiście nie jest trudne, ale pod warunkiem, że jest osadzone w ramach Scruma. Gdyby jednak próbować robić podobne spotkania w odizolowaniu od reszty praktyk, to wręcz nie da się tego zrobić "zgodnie ze sztuką". Oczywiście, nawet krótkie codzienne spotkania zespołu bez przejmowania się jakimikolwiek zasadami Scruma mogą usprawniać pracę, ale to tylko ułamek potencjalnych korzyści.

Zajrzyjmy do Scrum Guide:

Codzienny Scrum jest spotkaniem dla Zespołu Deweloperskiego, ograniczonym czasowo do piętnastu minut, podczas którego bieżące zadania są synchronizowane i powstaje plan działania na najbliższe 24 godziny. Jest to osiągane poprzez inspekcję prac, które zostały wykonane od ostatniego Codziennego Scruma i prognozowaniu prac, które mogą zostać wykonane przed kolejnym spotkaniem.

Scrum Guide

Codzienny Scrum jest dla Zespołu Deweloperskiego. Nie jest po to, żeby zdać raport menadżerowi, czy jakiejś innej nadzorującej projekt osobie. Wyrazistym antywzorcem jest sytuacja, gdy menadżer przepytuje po kolei każdą osobę w zespole, a ci którzy już są przepytani, lub czekają na swoją kolej, zajmują się innymi rzeczami, bo to o czym mowa nie jest dla nich istotne, albo dlatego, że spotkanie trwa już 40 minut. Codzienny Scrum to przede wszystkim wymiana informacji pomiędzy członkami Zespołu Deweloperskiego i powinna być na tyle konkretna, by każdy każdego słuchał. Trudno uniknąć problemów na tym polu, gdy rzeczywiste role w zespole nie odpowiadają rolom ze Scruma.

Podczas Codziennego Scruma bieżące zadania są synchronizowane i powstaje plan na następne 24 godziny. Zespół decyduje które zadania najlepiej zrobić w ciągu następnego dnia oraz kto konkretnie je zrobi. Gorzej, jeśli nie ma w tej kwesti wiele do gadania, bo zdecydował o tym ktoś inny i jeśli zrobią inaczej to "będzie dym"... Kolejny możliwy problem polega na tym, że zespół nie może zaplanować dobrze pracy, bo potrzebuje do tego pomocy z zewnątrz zespołu.

Pierwsze z pytań Codziennego Scruma brzmi "co zostało zrobione", a nie "co było robione". Nie zrealizuje się jednak takiego podejścia w praktyce, jeśli praca nie jest rozbita na zadania, które da się zrobić w jeden dzień. Do tego trzeba wcześniejszego Planowania Sprintu (ang. Sprint Planning) oraz jeśli nie poświęca się regularnie czasu na Pielęgnowanie Rejestru Produktu (ang. Backlog Refinement). Nawet wtedy rozbicie pracy na takie zadania może być niemożliwe, jeśli dług techniczny jest zbyt duży.

Ponadto, bez Retrospektyw można nawet nie zauważyć, że coś jest nie tak.

Zespół, który chce być zwinny, prędzej czy później natrafia na jakąś Scrumową zasadę, którą w jego przypadku ciężko wdrożyć. Może wtedy ją olać. Może próbować ją wdrożyć "na pałę" i dojść po krótkim czasie do wniosku, że to bez sensu. Prawdziwa poprawa następuje dopiero wtedy, gdy rozpoznaje się kryjący za tym wszystkim problem i podejmuje odpowiednie środki naprawcze.

PS. W zgodzie z najnowszymi trendami na blogach IT dorzucam jakieś zdjęcie: kaczki i gołąb z Parku Łazienkowskiego.

Brak komentarzy :

Prześlij komentarz