29.12.20215 min

Mikhail MedvedevSenior Software Engineer

Scrum nie jest taki "magiczny" jak się wydaje

Kiedy zespół decyduje się na Agile, a w szczególności na Scrum, zbyt często myśli, że po wykonaniu wszystkich magicznych rytuałów wszystko będzie działać, jak za dotknięciem czarodziejskiej różdżki. I co? I tak się nie dzieje.

Scrum nie jest taki "magiczny" jak się wydaje

Prawda jest taka, że czasami Scrum przypomina coś w rodzaju kultu. Nawet spotkania nazywa się „ceremoniami”, tak jakby w Scrumie nie było spotkań, tylko jakieś magiczne rytuały, a trenerzy i konsultanci wyglądają i mówią jak jacyś kultyści.

Kiedy zespół decyduje się na Agile, a w szczególności na Scrum, zbyt często ma takie podejście, że po wykonaniu wszystkich magicznych rytuałów wszystko będzie działać jak za dotknięciem czarodziejskiej różdżki i wszystkie problemy znikną. Wierzą, że jeśli będą powtarzać te magiczne zaklęcia, wydajność gwałtownie wzrośnie.

Jednak tak się nie dzieje. Czar pryska i wszyscy są zawiedzeni. Wtedy właśnie piszą niezliczoną liczbę artykułów, argumentując, że Scrum to jakiś przekręt i po prostu nie działa.

Cóż, Scrum to nie magia. Pomimo wszystkich przerażających słów i uroczych trenerów, Scrum sam w sobie nie posiada żadnej mocy. Nie jest w stanie samodzielnie rozwiązać problemów.


No i co dalej?

Cóż... nie jestem ekspertem od Scruma. Jestem inżynierem oprogramowania. Nie musisz mnie więc słuchać. Jednak kiedy zacząłem interesować się Agile, byłem zdumiony, jak wiele osób tylko naśladuje Scrum, bez żadnych konkretnych wymagań czy celów.

Scrum to tak jakby cały wszechświat: miliony artykułów, kursów i książek, tysiące rozmów, certyfikatów i trenerów. Tak wiele słów, a tak mało działań.


Framework

Porozmawiajmy jak inżynierowie. Scrum nie bez powodu nazywany jest “frameworkiem”. Jak wiele innych frameworków, nie oferuje ci kodu do rozwiązania Twojego problemu, daje ci tylko strukturę. To Twoim zadaniem — jako Scrum Mastera, Team Leadera lub inżyniera —  jest wypełnienie dziur.

Jak napisać taki kod? Mam pewien pomysł. Dla wielu osób może to zabrzmieć dziwnie, ale tak właśnie jest: zamiast ciągle gadać, zrób coś. To naprawdę nie ma znaczenia, w jaki sposób nazwiesz to czy tamto lub jak piękny jest Twój wykres spalania. Liczy się to, czy input daje właściwy output.


Sprint jako funkcja

Input: zadania.

Output: iteracja.

Sprint jest kamieniem węgielnym Agile. To najważniejsza funkcja. Nie jest to tylko słowo, rytuał, czy okres zaledwie dwóch tygodni. Wiele zespołów po prostu wrzuca kilka zadań na początku, a następnie, pod koniec drugiego tygodnia, przekazuje to, co nieskończone, do następnego “Sprintu”. Ale to nie jest Sprint, to tylko imitacja.

Każdy Sprint powinien zaczynać się od czystej kartki. Dobra funkcja jest idempotentna.

Ponadto, Sprint nie służy jako narzędzie pomiaru dla menedżera. Sprint mierzy się tylko wynikami, czyli tym, jaki mamy output.

Sprint jest funkcją, działaniem, które powinno wytworzyć iterację — coś, co działa, a czego wcześniej nie było. Coś, co można zademonstrować.

Jeśli Twoja praca nie jest iteracyjna — może rozwiązujesz tylko nieposortowane bugi, albo budujesz satelitę — to nie powinieneś próbować dzielić procesu na sprinty.


“Ceremonie” jako funkcje

Mogą być nazywane ceremoniami, ale nie dajcie się zmylić — są to tylko spotkania, które jeśli są prowadzone skutecznie, mogą być funkcjami i przynosić rezultaty.

Jeśli spotkanie nie przynosi rezultatów, powinno być prowadzone w inny sposób lub usunięte z kalendarza. Jeśli spotkanie jest rytuałem, to jest to tylko strata czasu dla wszystkich uczestników.


Znaczenie czasu

Zazwyczaj jest tak, że inżynierowie nie lubią zbyt wielu spotkań. A szczególnie prawie nikt nie lubi tych długich. Jeśli spotkanie nie ma jasno określonego celu, staje się dla uczestnika torturą. Jeśli spotkanie nie przynosi żadnych rezultatów, to nie ma ono sensu. Jeśli bezsensowne spotkanie powtarza się regularnie, można odnieść wrażenie, że to rytuał.

Jeśli Twój Scrum składa się z rytuałów, to jest to imitacja — nie powinno być dla nikogo zaskoczeniem, że ludzie zaczną narzekać, i że to nie działa.


Standup

Input: Sprawozdania członków zespołu

Output: Plan dnia

O standupach napisano już bardzo dużo. Zwykle skupiają się na “ludzkiej” stronie — raportujcie sobie nawzajem, nie rozpraszajcie się, trzymajcie się czasówki. Wszystkie te punkty są ważne. Ale dlaczego to robimy? „Każdy wie, co robisz”, ale dlaczego?

Powinni o tym wiedzieć, aby móc zaplanować swój dzień.


Udoskonalenie backlogu

Input: Wymagania

Output: Jasno określone, rozpisane zadania

Udoskonalenie backlogu bierze ściśle określone wymagania i przekształca je w jasno zdefiniowane zadania.

Jasno zdefiniowane  — to jest ważne. Po spotkaniu nie powinno być potrzeby zadawania pytań. Pamiętaj, że te zadania będą dalej przechodzić przez pipeline i wrócą do Ciebie podczas planowania Sprintu.

Jeżeli udoskanalanie jest bezowocne, to planowanie również będzie bezowocne.

Ponadto, Planning Poker nie jest tylko nudną grą. Pytanie o to „jak” nie jest tutaj ważne. Ważne jest to, czy możesz szybko powiedzieć, jak trudne jest to zadanie.

Szacunki definiują Sprint, Sprint definiuje to, nad czym będziesz pracował oraz jak intensywnie. Jeśli poker rzeczywiście coś zmieni, to wszyscy będą tym zainteresowani.


Planowanie Sprintu

Input: Jasno określone, uporządkowane pod względem priorytetów zadania

Output: Plan Sprintu

Planowanie Sprintu bierze to, co zostało wytworzone w udoskonaleniu backlogu, dzieli na części i przekształca w Sprint.

Najważniejszą rzeczą w planowaniu Sprintu jest powaga sytuacji. Kiedy planujesz Sprint i „zobowiązujesz się”, nie powinien to być tylko symboliczny gest — to Ty decydujesz, nad czym będziesz pracować. Będzie to inkrementacja, którą będziesz musiał pokazać swoim współpracownikom.


Retrospekcja

Input: Przemyślenia członków zespołu na temat Sprintu

Output: Lista działań do realizacji

Pracowałem kiedyś w zespole, w którym czas retrospekcji był czasem, gdy wszyscy tylko na siebie krzyczeli i narzekali. W jeszcze innym zespole czas retrospekcji był czasem ciszy, bo niby wszystko było dla wszystkich super.

W wielu zespołach retrospekcja jest tylko dla menedżerów — jedyna rzecz, o której myślą inżynierowie, to powrót do pracy.

Retrospekcja powinna zebrać opinie wszystkich osób na temat procesu pracy i stworzyć listę działań. Następnie działania te powinny być realizowane.

Jeśli retrospekcja nie przyniesie żadnej poprawy, to jest to tylko strata czasu.


Demo

Demo Sprintu istnieje po to, aby upewnić się, że stworzyłeś iterację. Jeśli nie masz nic do zademonstrowania, to może to nie był Sprint?


Koło

Pomyśl o Scrumie jako o diagramie sekwencji działań funkcji Lambda. Ponieważ proces jest iteracyjny, nieuchronnie tworzy się z tego koło.

... Usprawnienia -> Udoskonalenie backlogu -> Backlog -> Planowanie Sprintu -> Sprint -> Standup ->  Demo -> Retrospekcja -> Usprawnienia ..

To tak naprawdę przetwarzanie danych.


Odpowiedni framework

Scrum nie tworzy dla zespołu procesu. Jako framework, może jedynie pomóc w strukturze. To na zespole spoczywa obowiązek napisania “kodu”.

Żeby to miało sens i jakoś działało, nie powinno nam zależeć na byciu fajnym czy robieniu rzeczy dobrze. Powinniśmy się martwić o wyniki.

Chociaż wiele mówi się o tym, jak fajnie i przyjemnie jest być zwinnym, to tak naprawdę w Agile chodzi o dyscyplinę. Został stworzony jako framework do poruszania się w chaosie ciągle zmieniających się wymagań.

Scrum nie musi być zabawą, ale też nie musi być nudny. Najlepiej, żeby był po prostu niewidoczny. Co najważniejsze, nie powinien odciągać ludzi od pracy i wprowadzać więcej chaosu, bo często ten chaos już tam jest.

I tak macie rację, czasami Scrum po prostu nie jest właściwym wyborem dla danego zespołu.


Oryginał tekstu w języku angielskim można przeczytać tutaj.

<p>Loading...</p>