Podejrzewam, że większość z Was słyszała o metodykach zwinnych (ang. agile) w kontekście prowadzenia projektów, często w parze z konkretną "implementacją" tego podejścia, a mianowicie Scrumie. Tematem tego wpisu nie będzie jednak zwinność jako taka (być może kiedyś przyjdzie na to czas), ale jeden z przejawów tego podejścia - jest bowiem oczywiste, że postępowanie zgodne z jakąś metodyką oznacza również zmianę nawyków dotyczących różnych aspektów codziennej pracy i zarządzania. Dzisiaj będzie nas interesować to, co "agile" wprowadza w kontekście komunikacji. Jest ona bardzo istotna w każdym projekcie i sposobie jego prowadzenia, jednak np. w Scrumie, gdzie zadania często są małe i ludzie pobierają kolejne z listy lub tablicy, odpowiednie informowanie się wewnątrz zespołu o statusach jest kluczowe. Stąd też kilka rodzajów spotkań, które mają miejsce w takiej społeczności, a najbardziej znane z nich to tzw. stand-up meetings.

Nie jest to praktyka wykorzystywana tylko w środowisku IT (jest także obecna m.in. na spotkaniach Tajnej Rady Wielkiej Brytanii), ale tutaj przyjęła się bardzo dobrze i dlatego jest z nią kojarzona. Stand-up meetings (w wolnym tłumaczeniu "spotkania na stojąco") to codzienne zbiórki członków zespołu IT, które - jak sama nazwa wskazuje - odbywają się na stojąco. Skąd taki pomysł? Otóż, ludzie nie lubią niewygody, a taką jest zrezygnowanie z wygodnego krzesła na rzecz dźwigania swoich kilogramów na dwóch nogach. Co za tym idzie, uczestnicy takiego spotkania chcą je jak najszybciej skończyć i wrócić przed komputery na swoje wygodne siedziska. I to właśnie idea stojąca za SUM-ami (jak pieszczotliwie nazywamy takie zbiórki) - wymienić się najważniejszymi informacjami jak najszybciej i nie przeciągać rozmów w nieskończoność.

Spotkania zwyczajowo powinny być przeprowadzane w gronie członków samego zespołu IT realizującego jeden projekt, jednak w praktyce warto czasem włączyć osobę zarządzającą, aby przy okazji też dowiedziała się, co w trawie piszczy i z jakimi trudnościami zmagają się programiści. SUM powinien być przeprowadzany codziennie, o możliwie stałej godzinie i trwać ok. 5-15 minut (w zależności od liczby uczestników). Ta praktyka powinna stać się rutyną i być egzekwowana nawet, jeśli nie wszyscy członkowie zespołu są obecni. Jeśli już poruszyliśmy temat samego Scruma, to tam takie spotkania zwane są "Daily Scrumami", gdzie każdy uczestnik powinien odpowiedzieć na trzy pytania:

1. Co robiłem(-am) w projekcie od poprzedniego spotkania?
2. Co zamierzam robić w projekcie po zakończeniu obecnego spotkania?
3. Czy coś mnie blokuje w wykonywaniu moich zadań?

Ważne jest to, aby w trakcie swojej "opowiastki" nie wchodzić zbyt głęboko w szczegóły. Oczywiście, w granicach rozsądku - wypowiedź "robię formularz i dalej będę robił" niekoniecznie musi wiele powiedzieć zespołowi, a będzie świadczyć tylko o mrukliwości mówiącego. Wypada powiedzieć choćby, jaki formularz jest realizowany, ile już (mniej więcej) zostało wykonane i czy faktycznie będziemy go kontynuować przez cały następny dzień pracy, czy jest szansa, że po drodze zabierzemy się za coś innego. W tej zasadzie lakoniczności chodzi bardziej o to, aby nie dotykać tematu szczegółowo, wręcz z całą historią, która za tym stoi. Przykładowo, wypowiedź "realizuję ekran pogody, integruję się z API AccuWeather" jest w porządku, natomiast dodawanie do tego "korzystam z usług REST-owych, wysyłam GET-a z parametrami, które znalazłem w dokumentacji, ale dostaję 500-tkę, sprawdzałem w sieci, oznacza to, że źle sparsowało JSON-a" jest już zdecydowane niepotrzebnie rozwinięte. Nie oznacza to, że takimi informacjami nie można się podzielić, szczególnie, jeśli jest to coś, co nas blokuje - chodzi jedynie o to, aby nie dzielić się nimi na SUM-ie tylko ewentualnie, z konkretną osobą, po zakończeniu "oficjalnego spotkania".

W wyniku SUM-a każdy członek zespołu powinien mieć wiedzę dotyczącą tego:

• kto czym się zajmuje i ile jeszcze czasu może mu to zająć,
• które zadania niedługo zaczną być realizowane, a które są jeszcze nieobsadzone i do wzięcia,
• czy są blokady, których należy się pozbyć (poprzez dokładniejsze omówienie czegoś, poproszenie kierownika projektu o interwencję itd.), ponieważ stopują one prace.

Tyle mówi teoria. Natomiast wiadomo, że każdy zespół IT dostosowuje trochę SUM-y do swoich preferencji oraz środowiska i nie ma w tym niczego złego - najważniejsze w realizowaniu dobrej praktyki jest to, aby ona nam rzeczywiście pomagała, a nie była jedynie punktem do odhaczenia w programie dnia, "bo tak trzeba". Przykładowo, jeśli mamy bardzo mały zespół i zachodzi duża wymienność nie tylko pomiędzy zadaniami w projekcie, ale także pomiędzy samymi projektami, to SUM powinien dotyczyć nie tylko samego zespołu realizującego konkretny projekt, ale całego działu IT - choćby po to, aby inni wiedzieli, czy jest wymagane "wskoczenie" do danego oprogramowania i pomoc koleżance lub koledze.

Także w małych zespołach często włącza się osoby zarządzające do SUM-a, nie tylko po to, aby mogły zorientować się w statusie prac i zidentyfikować ewentualne przeszkody. Powodem jest także to, że w takich firmach relacja pomiędzy "górą" a zespołem często jest znacznie bliższa niż w korporacjach, a takie spotkania mogą dodatkowo powiązać obie strony i sprawić, że atmosfera w pracy stanie się lepsza. Dodatkowo, jeśli dynamika pojawiania zadań jest wyjątkowo duża, włączenie osoby zarządzającej do SUM-a może pomóc w skutecznej delegacji zleceń i planowaniu harmonogramu.

Innym sposobem na urozmaicenie spotkania na stojąco jest wprowadzenie pewnej formy zabawy - pewne "głupie", ale zabawne zachowania pozwalają nie tylko czerpać radość z tego czasu, ale także łatwiej zapamiętać to, co się działo. U nas w Wilda Software od wielu lat jest to "losowe" wyznaczanie kolejnego wypowiadającego się, co zawsze wprowadza efekt niepewności i bycia czujnym. Każda osoba wskazuje kolejną i musi wiedzieć, kto już był, a kto jeszcze nie miał okazji się wypowiedzieć. Jednak, to nie wszystko - bywało, że wyznaczanie odbywało się przez rzucenie małej piłki, która to sygnalizowała uczestnika, który właśnie ma głos. To wprowadza jeszcze więcej rozrywki (szczególnie podczas rzutów nad monitorami po przekątnej pokoju), jednak przestrzegam Was przed ewentualnymi nieprzyjemnościami, które mogą się z tym wiązać (głównie w pobliżu okien i szyb).

Daily Scrumy najlepiej sprawdzają się "na żywo", jednak bywają sytuacje, w których nie wszyscy uczestnicy znajdują się na miejscu. Wówczas do gry wkraczają technologie wideo- i audiokomunikacyjne - niejednokrotnie podczas SUM-a podłączaliśmy innych programistów (pracujących akurat zdalnie) przez telefon, Google Meeta czy Discorda. W ostateczności SUM-y można przeprowadzać także tekstowo na Slacku, jednak pewnie domyślacie się, że z efektywnością ma to niewiele wspólnego - nie każdy uważnie przeczyta taki status, dodatkowo robi to wygodnie siedząc w fotelu i łatwo wówczas przeoczyć rzeczywiście istotne informacje.

Na koniec inny, bardzo śmiały pomysł na urozmaicenie SUM-a i sprawienie, aby był on jeszcze krótszy, sprawniejszy, a i członkowie zespołu mogli się nagimnastykować. Można nieco odejść od "stand-up" i przyjąć bardziej ekstremalne i męczące podejście, a mianowicie... leżenie z podparciem się na łokciach. Wprawdzie nie słyszałem, aby ktoś używał tego sposobu w moim najbliższym otoczeniu, ale nie da się ukryć, że taka forma może również być potraktowana jako forma zabawy, treningu, a jednocześnie znacznie skraca spotkanie. Tylko zadbajcie o czystą podłogę.

Życzę Wam bardzo owocnych spotkań na stojąco (lub "pompująco") i przede wszystkim tego, aby nie tylko były one stałym punktem programu dnia, ale też rzeczywiście efektywną formą wymiany informacji pomiędzy członkami zespołu (nie tylko IT).

Pozdrawiam i dziękuję - Jakub Rojek