Słowem wstępu

Prawidłowo prowadzony Scrum jest spoiwem dla zespołu i samochodem wyścigowym dla projektu. Łączy w sobie zarówno dobre relacje międzyludzkie jak i sprawne posuwanie się prosto do celu. Niestety kierowany nieprawidłowo będzie powodował wyłącznie napięcia, frustracje i przerzucanie się odpowiedzialnością za niepowodzenia. Od Ciebie jako członka zespołu zależy jak będzie on wyglądał. Jeśli jeszcze nie wiesz czym jest SCRUM, to odsyłam do artykułu Kacpra Gugała. Dziś skupimy się na życiowych przykładach problemów i idealnych z mojego punktu widzenia rozwiązań.

Zespół deweloperski – jeden za wszystkich, wszyscy za jednego

To różni IT od innych branż, że tutaj pracownik czyli programista posiada szereg unikalnych cech i umiejętności, które mogą być pomocne nie tylko w rozwiązaniu przydzielonych do niego zadań, ale także zadań kolegów z zespołu. Dobrą praktyką jest, aby każdy developer posiadał wiedzę na temat działania całej aplikacji, a nie tylko na temat małego skrawka, za który on będzie odpowiadał. Nie chodzi tutaj o łatwość zastąpienia pracownika nowym specjalistą, ale przede wszystkim o spójność kodu, architektury – wypracowanie pewnych standardów jakości kodu czy dokumentacji jako zespół. Dzięki takiemu podejściu w sytuacji, w której jeden z programistów będzie miał problem z rozwiązaniem zadania – pomocną dłoń mogą okazać mu pozostali członkowie zespołu. Scrum nie jest wydajny dzięki temu, że każdy wie co ma robić i skupia się na swoich zadaniach, ale właśnie dzięki temu, że każdy może oderwać się na chwilę od swojej „roboty” i skupić na tym co jest w tym momencie najważniejsze dla całego zespołu i dla sukcesu projektu.

Scrum Master – wujek dobra rada

W wielu firmach rola Scrum Mastera to stanowisko, które zastąpiło popularnego niegdyś Project Managera. Czy przemianowanie PMa w SMa to na pewno dobra decyzja? Kierownik zespołu powinien cechować się charyzmą, pewnością siebie, powinien wiedzieć jak delegować zadania, jak karcić swoich podopiecznych i jak ich motywować. Podejście to sprawdza się doskonale w firmach, w których każdy z pracowników ma do wykonania konkretny typ zadań, a projekt jest skończony w czasie – wtedy potrzeba człowieka, który zorganizuje pracę i dopilnuje, aby wszystko szło zgodnie z planem. Co jednak z branżą IT? Tutaj typowe zarządzanie zespołem rzadko się sprawdza, stąd tak wielkie zainteresowanie metodykami zwinnymi. Podstawowym ich filarem jest samoorganizujący się zespół. Podkreślić należy, że w Scrumie mówimy o samoorganizującym się zespole deweloperskim – programistów, testerów, projektantów, bez uwzględnienia Scrum Mastera. Wiemy więc, że Scrum Master nie powinien ingerować w pracę i decyzje zespołu.

Wróćmy do naszego pytania. Moim zdaniem nie każdy PM jest w stanie stać się Scrum Masterem. Wynika to przede wszystkim z potrzeby delegowania zadań, podejmowania decyzji o kierunku rozwoju projektu, ingerowania w kształt finalnego produktu, oceniania pracy pracowników i motywowania ich do działania, kiedy są zbyt mało wydajni. Są to nie tyle czynności niepotrzebne, co wręcz niewskazane i szkodliwe. Niestety tak wygląda 90% projektów „zwinnych” w Polsce.

Dlaczego ktoś do tego dopuszcza? Dlatego, że firmy, które przechodzą rewolucję scrumową nie chcą zwalniać project managerów (uważają ich za ojców wielu firmowych sukcesów i z pewnością tak jest), dlatego też na siłę szukają dla nich miejsca w zespołach scrumowych. Scrum Master powinien być dla zespołu jak dobry wujek, który zawsze wspomoże dobrą radą, a nie jak kierownik, który patrzy na wszystkich z góry i kiwa palcem. To on pracuje dla zespołu, a nie zespół dla niego. Wielu byłych kierowników projektów nie może sobie poradzić z tą zmianą. Traktują rolę Scrum Mastera jak stanowisko kierownicze, natomiast jest to rola tak samo istotna w zespole scrumowym jak rola programisty. Dobry SM powinien pilnować przestrzegania zasad, którymi cechuje się Scrum, powinien rozwiązywać konflikty i problemy, z którymi zespół sam sobie nie poradzi. Należą do nich na przykład problemy z dostępami, problemy komunikacyjne z innymi zespołami, niepewność co do treści zadań. Najważniejszą jednak rolą SM jest przypominanie zespołowi o tym, że jest drużyną, która pracuje na wspólny sukces i pilnowanie zasad, o których dziś rozmawiamy.

Najczęściej występującym w scrumie problemem jest brak transparentności. Członkowie zespołu nie informują o problemach z zadaniami, o przebiegu prac, bo boją się krytyki, brakuje im wsparcia. Informacja o obecnie wykonywanym zadaniu, to o wiele za mało. I to jest zadanie dla Scrum Mastera, aby domagać się od zespołu przestrzegania zasad czyli także tej transparentności.

Po czym poznać dobrego SMa? Jego zespół jest praktycznie samodzielny, a on sam wie co się aktualnie dzieje w projekcie. Nie ma nic gorszego niż SM, który przez cały sprint prowadzi wyłącznie spotkania statusowe, ignoruje problemy natury programistycznej czy komunikacyjnej, nie interesuje się zupełnie zespołem i jego potrzebami, a w ostatnim dniu sprintu wylewa swoje żale i całą winę za niedostarczone w terminie funkcjonalności zrzuca na zespół. Jeśli pracujecie w takiej atmosferze, to szczerze współczuję.

Sprint – biegniemy prosto do celu

Codzienne spotkania tzw. daily nie służą kontrolowaniu programistów. Są przede wszystkim miejscem, w którym można powiedzieć co udało się zrobić w ostatnim czasie, nad czym obecnie pracujemy i jakie pojawiły się problemy. Transparentność to również jeden z filarów Scruma. Być może ktoś potrzebuje pomocy i może wtedy zaprezentować na daily co sprawia mu kłopot. Lepiej opowiedzieć o tym przy wszystkich, bo z dużym prawdopodobieństwem ktoś już się zetknął z podobnym przypadkiem i wie jak go rozwiązać w najkrótszym czasie. Jeśli brakuje szybkiego rozwiązania, to jest to dobry moment, aby zaprosić kolegów do programowania w parach czy burzy mózgów.

Zespół to monolit. Jeśli zadanie o wysokim priorytecie nie zostanie dowiezione na czas, to praca pozostałych programistów (którzy nie są przypisani do tego zadania) nie będzie miała tak wielkiego znaczenia – i tak cały sprint zostanie źle oceniony przez Product Ownera. Dlatego ważne jest, aby wspólnie rozwiązywać zgłaszane problemy, bo wszystkim powinno zależeć na ich rozwiązaniu.

Wszystko ma oczywiście swoje granice. Jeśli któryś z programistów będzie musiał być prowadzony za rękę przez cały czas, to z pewnością nie pasuje do tego zespołu. Nie możesz ciągle skupiać się na pomaganiu kolegom, kiedy Twoje zadania leżą i czekają. Masz swoje zobowiązania i musi Ci zależeć na ich dotrzymaniu. Każdy odpowiada za zadania do niego przypisane i to na tej osobie spoczywa obowiązek informowania o problemach. Jeśli na koniec sprintu poinformujesz o tym, że masz problemy z rozwiązaniem zadań, to jest to o wiele za późno. Od tego jest daily.

Review – sprawdzamy rezultaty

W słabszych zespołach review przeprowadzane jest przez Scrum Mastera, który przechodzi po kolei po zadaniach wchodzących w skład obecnego sprintu i pyta ile jeszcze zostało do zrobienia w tych niedowiezionych. Tego typu review niestety nie spełnia żadnej funkcji. Jest wręcz sugerowaniem programistom, że nie dali rady zrobić wszystkich zaplanowanych zadań.

W lepszych zespołach każdy z członków prezentuje efekty pracy wykonanej przez niego w danym sprincie. Mogą to być fragmenty dokumentacji, gotowe ekrany aplikacji, prezentacja rozwiązanych błędów. Każdy ma swoje pięć minut. Dzięki temu „czuć”, że sprint przyniósł namacalne efekty. Ma to nie tylko ogromny wpływ na ogólne morale zespołu, ale także motywuje jednostkę do jeszcze lepszej pracy, bo programista zdaje sobie sprawę z tego, że ta praca jest doceniana przez resztę zespołu. Zajmujemy się prezentacją wyłącznie ukończonych zadań i skupiamy się na sukcesach. Na pokorę przyjdzie czas podczas retrospektywy.

Retrospektywa – usprawniamy pracę zespołu

Czas na refleksję i zastanowienie się co w aktualnie zamkniętym sprincie poszło zgodnie z planem, co zasługuje na uznanie, a jakich błędów lepiej nie powtarzać. Każdy z członków zespołu ma szansę wypowiedzieć się na ten temat. Spotkanie to nie służy omawianiu problemów programistycznych, a jednynie problemów organizacyjnych, związanych z pracą zespołu. Bardzo ciekawym narzędziem do przeprowadzania retrospektywy w formie online jest https://www.retrospective-dashboard.org

Zazwyczaj podczas tych spotkań omawia się tematy takie jak:

• problemy komunikacyjne z innymi zespołami
• zbyt duże / zbyt małe velocity
• złe estymaty zadań wynikające ze słabych opisów, z nowych wymagań, z pojawiających się problemów technicznych
• słaby feedback podczas code-review albo brak code-review

Efektywne planowanie – ustalanie priorytetów

Przed rozpoczęciem prac zespół planuje zakres nowego sprintu. Aby taki zakres ustalić, należy najpierw oszacować (wyestymować) czas potrzebny na wykonanie każdego z zadań. Za estymację odpowiada cały zespół deweloperski. Każdy z programistów musi rozumieć wszystkie zadania i cele na ten sprint.

Preferowaną jednostką estymacji zawsze będzie Story Point, który nie określa zbyt prezycyjnie w jakiej przestrzeni czasu zostanie wykonane zadanie, ale dzięki temu zostawia też trochę miejsca na pomoc kolegom z zespołu czy zajęcie się jakimś krytycznym błędem na środowisku produkcyjnym – to w samoorganizującym się zespole jest podstawą. Narzucanie programistom wymogu bardzo dokładnego estymowania w MD (man-day) czy wręcz w godzinach, wprowadza niepotrzebną presję, stres i sprawia, że zespół pozbawiany jest tej samoorganizacji pracy.

Bardzo ciekawym i jednocześnie szybkim sposobem przeprowadzenia planowania jest tzw. Planning Poker. Wszyscy członkowie zespołu developerskiego zasiadają razem do stołu, scrum master otwiera po kolei zadania, czyta ich treść, a następnie zebrani wystawiają swoje estymaty dla każdego z zadań. Robią to jednocześnie, aby ich ocena była ich osobistą decyzją – nie wynikała z tego jak dane zadanie wyceniły pozostałe osoby. W sieci istnieje wiele narzędzi ułatwiających przeprowadzenie planning pokera, ale można też wykorzystać fizyczne karty.

Podsumowanie

Ile razy w ciągu Twojej kariery udało Ci się pracować w takiej atmosferze jak zaprezentowana powyżej? W IT Hero stawiamy na ludzi. Każdy jest ważnym elementem układanki, każdy ma swoje zadanie i każdy jest ojcem sukcesu, który wspólnie osiągamy dzięki odpowiedniej organizacji naszej pracy. Najbardziej zadowoloną osobą jest Klient, który dostaje dokładnie to czego oczekuje – szybko dostarczone, przemyślane i wolne od błędów rozwiązania. Wyciągamy ze Scruma całą esencję – wszystko to co usprawnia i przyśpiesza zamykanie projektów. W takich warunkach 3 programistów nie tworzy aplikacji 3 razy szybciej od 1 programisty, ale aż 5-6 razy szybciej. Ich kompetencje ciągle się przeplatają i uzupełniają. Chcesz wiedzieć więcej o pracy profesjonalisty? Przeczytaj o tym jak zostać dobrym programistą.