Czym jest Scrum i jaka jest rola testera w zespole scrumowym? O tym w dzisiejszym artykule.
Istnieje wiele narzędzi, sposobów i metod prowadzenia projektów. Wybór odpowiednich z nich bardzo często zależy od specyfikacji projektu. Z tego artykułu dowiesz się więcej na temat Scruma, jednej z metodyk zwinnych.
W tym artykule opiszę:
- Czym jest Scrum;
- Plusy i minusy Scruma;
- Kim jest Tester w Zespole Scrumowym;
- Kiedy warto stosować metodykę Scrum.
Czym jest Scrum
Scrum to ramy postępowania wykorzystywane w zarządzaniu tworzeniem produktów. Nie jest procesem, techniką wytwórczą czy opisem sposobu działania. To jedynie ogólne zasady postępowania, w obrębie których możliwe jest stosowanie różnych procesów i technik.
Scrum to metodyka działania w projekcie, która dzięki swojej elastyczności pozwala usprawniać procesy wytwarzania dobrego oprogramowania oraz doskonalić zespół i środowisko pracy.
Scrum w swoim założeniu jest metodyką podzieloną na wydarzenia:
- Sprint — wbrew temu, co mówi nazwa, nie jest to tempo biegowe. W tym przypadku sprint to przedział czasowy, w którym zespół ma za zadanie dostarczyć ustaloną wcześniej część oprogramowania;
- Planowanie sprintu — spotkanie mające na celu zaplanowanie pracy dla całego zespołu w trakcie trwania sprintu;
- Codzienny Scrum (daily Scrum) — 15-minutowe spotkanie, w trakcie którego każdy członek zespołu odpowiada w skrócie na 3 pytania: co robił wczoraj, czym planuje zająć się dziś i czy ma jakieś problemy, utrudniające obecną pracę;
- Przegląd sprintu — spotkanie organizowane na zakończenie sprintu w celu inspekcji przyrostu. Podczas spotkania zespół i interesariusze analizują, co zostało ukończone w sprincie;
- Retrospektywa sprintu — to okazja do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wprowadzony w następnym sprincie.
W tych wszystkich wydarzeniach bierze udział Zespół Scrumowy. W jego skład wchodzą Product Owner, zespół developerski oraz Scrum Master. Zespoły Scrumowe są samoorganizujące się i międzyfunkcjonalne.
Cytując słynny „Przewodnik po Scrumie” autorstwa K.Schwabera: „Samoorganizujące się zespoły samodzielnie decydują, w jaki sposób najlepiej wykonywać pracę, nie będąc przy tym kierowanymi przez osoby spoza zespołu. Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu.”
W „idealnym” Zespole Scrumowym każdy jego członek posiada wystarczające kompetencje, aby móc sprostać każdemu zadaniu. Tu mam na myśli zarówno procesy projektowania, developmentu, jak i testowania.
Ideą Scruma jest prowadzenie projektu, nie będąc zależnym od nikogo spoza zespołu scrumowego. Zespół powinien być w stanie zaplanować pracę na cały sprint i zrealizować ten plan. Krótko mówiąc, powinien być samowystarczalny.
Plusy i minusy Scruma
Korzystanie ze Scruma ma zarówno plusy, jak i minusy. Jak słusznie zauważa Schwaber: „Scrum jest lekki i łatwy do zrozumienia jednak trudny do opanowania”. Metodyka ta jednocześnie daje dużą swobodę członkom zespołu scrumowego, ale jest też ciężka do wprowadzenia i opanowania, ponieważ w zespole scrumowym „każdy jest developerem”, co znaczy, że każdy powinien posiadać podobny wachlarz kompetencji. W praktyce jednak wygląda to zgoła inaczej. Moim zdaniem najlepszym i najefektywniejszym zespołem scrumowym będzie taki, w którym znajdą się sami eksperci w swoich dziedzinach: architekt, backend i frontend developerzy, tester oraz Scrum master (oczywiście to w zależności od specyfikacji projektu).
Dużo zespołów projektowych korzysta z tej metodyki, wykorzystując tylko część z jej potencjału. Widywałem zespoły, w których ze Scruma mieli jedynie daily i czas pracy podzielony na sprinty. Różne zespoły wykorzystują część wydarzeń ze Scruma, co samo w sobie pokazuje, że jest to pożądana i skuteczna metodyka. Wprowadzenie Scruma w projekcie i wykorzystywanie go w całości pozwala dużo efektywniej prowadzić projekt i zarządzać zespołem.
Kim jest tester w zespole scrumowym
Rola testera w zespole scrumowym często bywa bagatelizowana, czy wręcz pomijana — jednak jest ona bardzo ważna. Wbrew pozorom nie ogranicza się jedynie do testowania gotowych komponentów aplikacji.
Rola testera zaczyna się już na samym początku procesu, tzn. w fazie planowania. Kiedy zespół developerski omawia poszczególne części aplikacji i wymyśla najbardziej optymalne rozwiązania, tester rozpoczyna swoją pracę. Podczas gdy zespół ustala szczegóły dotyczące implementacji, tester musi dowiedzieć się, jak ma działać (a jak działać nie powinna) konkretna funkcjonalność i jak to można sprawdzić, przetestować. Już w tym miejscu tester może zacząć planować przypadki testowe i szukać błędów w trakcie planowania.
Następnie, w trakcie sprintu, poza codziennymi obowiązkami powinien też dostosowywać i modyfikować przypadki testowe, jeśli implementacja z jakiegoś powodu będzie inna niż zakładana.
Bardzo często testerzy zajmują się również zarządzaniem środowiskami. Mam tu na myśli kontrolowanie aby zmiany ze środowisk developerskich były mergowane do środowisk testowych. Niestety bardzo często brak kontroli nad tym procesem jest powodem wielu nieporozumień i kłopotów.
Po zakończeniu sprintu warto również przygotować product backlog do przeglądu sprintu, a więc warto uporządkować wszystkie zadania pod kątem priorytetu itd.
Kiedy warto stosować metodykę Scrum
Metodyka Scrum jest świetnym rozwiązaniem dla mniejszych zespołów developerskich. W takim zespole powinno być więcej niż 3, jednak nie więcej niż 9 osób. W ten sposób zespół nadal pozostaje zwinny, a jego kompetencje pozwalają swobodnie prowadzić projekt.
Pomocne przy wyborze między Scrumem a innymi metodykami są 3 pytania:
- Jaki rodzaj pracy będzie wykonywać zespół?
- Czy będzie istniała wspólnota pracy, praca zespołowa, czy też każdy członek zespołu swoje zadania może wykonywać samodzielnie i niezależnie?
- Czy jest ważne utrzymanie stałego tempa pracy i rozwoju produktu?
Jeśli można przewidzieć, zaplanować i ustabilizować pracę na krótki odcinek czasu (między 1 a 4 tygodniami), prawdopodobnie powinniśmy zastosować Scrum. Dzięki temu ryzyko, że „przestrzelimy” z efektami naszej pracy lub utkniemy nad trudnościami, kosztuje nas tylko jeden sprint. Praca eksploracyjna, eksperyment, odkrywanie niepewnego lub poszukiwanie najlepszego rozwiązania (znamy cel, nie znamy ścieżki dojścia) – to domena Scruma.
Natomiast jeśli nie liczy się planowanie, a efekt, jeśli praca ma być zaplanowana na dłuższy wymiar czasu (przykładowo kilka miesięcy) i ma zostać dostarczony cały produkt, wtedy proponowałbym kierować poszukiwania w stronę metodologii kaskadowych.
Na zakończenie dodam, że pracowałem w kilku różnych metodologiach i mając porównanie, jestem wielkim zwolennikiem Scruma. Jednakże to jedynie moja subiektywna opinia. Mam nadzieję, że artykuł okazał się pomocny i teraz wiesz już, o co chodzi w Scrumie i kiedy warto go stosować.
