...

BRIEF dociera do polskich firm i ich pracowników – do wszystkich tych, którzy poszukują inspiracji w biznesie i oczekują informacji o ludziach, trendach i ideach.

Skontaktuj się z nami

Liczy się czas, czyli dlaczego metodyka Scrum działa

metodologia SCRUM

Scrum istnieje w świecie technologii już od wielu lat, ale nadal wywołuje mnóstwo pytań nawet u osób mocno związanych z tą metodyką. Choć definicja jest lekka i łatwa do zapamiętania, trudności przysparza jej opanowanie oraz efektywne wprowadzenie do organizacji. Czym Scrum jest i dlaczego warto go rozważyć w pracy nad projektami? Chodzi m.in. o czas, a w świecie szybko zmieniających się technologii często jest to surowiec na wagę złota.

Scrum został stworzony przez Kena Schwabera i Jeffa Sutherlanda na początku lat 90. Od 2009 roku metodyka ta jest oficjalnie zdefiniowana w publicznym dokumencie o nazwie „The Scrum Guide”. Od tego czasu dokument był aktualizowany już 5 razy – obecnie najnowsza wersja pochodzi z listopada 2017 roku. Przewodnik od samego początku jest dostępny dla wszystkich zainteresowanych użytkowników za darmo. Do dziś został przetłumaczony na ponad 30 języków, w tym na język polski.

Czym jest Scrum?

Scrum to framework (zorganizowany system), wykorzystywany w procesach wytwarzania, dostarczania i utrzymywania złożonych produktów. Najczęściej jest nim oprogramowanie, ale może to być również dowolna inna rzecz, która dostarcza wartość końcowym użytkownikom, np. rozwój sprzętu, usług, produktów chmurowych, czy marketingowych.

System ten definiuje ramy postępowania, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów. Warto podkreślić, że Scrum nie jest procesem, techniką wytwórczą, czy też wyczerpującym opisem sposobu działania. W jego ramach określono jedynie ogólne reguły postępowania, w zakresie których możliwe jest stosowanie różnego rodzaju procesów i technik. Z systemem tym wiążą się również wydarzenia oraz sprinty, które odgrywają ważną rolę w działaniu metodyki.

Wydarzenia opisane w Scrumie są używane do wprowadzenia regularności i zminimalizowania potrzeby organizowania innych, nieujętych we frameworku spotkań. Wszystkie wydarzenia są ograniczone czasowo (ang. timebox), co oznacza, że mają ustalony maksymalny czas trwania.

Sercem tej metodyki jest z kolei „sprint” — ograniczony czasowo do maksymalnie jednego miesiąca, podczas którego wytwarzany jest „ukończony”, gotowy do użycia i potencjalnego wydania przyrost. Po rozpoczęciu sprintu nie można go ani skracać, ani wydłużać – jego ramy są stałe.

Zgodnie z definicją, Scrum składa się z zespołu scrumowego oraz związanych z nimi ról, wydarzeń, artefaktów (ang. artifacts) i reguł. Każdy z elementów służy konkretnym celom i jest niezbędny do osiągnięcia sukcesu w stosowaniu tej metodyki. Reguły Scruma łączą ze sobą wydarzenia, role i artefakty, definiując powiązania oraz relacje pomiędzy nimi.

Najważniejsi są ludzie

Zespoły Scrumowe są samoorganizujące się i międzyfunkcjonalne (ang. cross-functional). Samoorganizacja zespołu polega na samodzielnym decydowaniu, w jaki sposób najlepiej wykonywać pracę i dostarczyć oczekiwaną wartość, nie będąc przy tym kierowanymi przez osoby spoza zespołu. Międzyfunkcjonalność z kolei oznacza, że posiadają wszelkie kompetencje niezbędne do ukończenia pracy i nie są zależne od osób spoza zespołu.

Ich cechą charakterystyczną jest to, że dostarczają produkty iteracyjnie – powtarzając tę samą operację w pętli aż do osiągnięcia oczekiwanego wyniku – oraz przyrostowo, zwiększając szanse na jak najwcześniejsze uzyskanie informacji zwrotnej od wszystkich interesariuszy, a także na wprowadzenie ewentualnej zmiany w tworze lub w rejestrze jego wymagań. Przyrostowe dostarczanie „ukończonego” wyniku pracy zapewnia nieprzerwaną dostępność działającego produktu oraz gwarantowanie wartości użytkownikom przy każdej potencjalnie użytecznej wersji.

W zespole scrumowym wyróżniamy trzy role: Product Owner, czyli właściciel produktu, zespół deweloperski oraz Scrum Master.

Product Owner odpowiedzialny jest za maksymalizację wartości produktu i pracy zespołu deweloperskiego. Jego jednym z najważniejszych obowiązków jest zarządzanie backlogiem produktu (ang. Product Backlog), czyli uporządkowaną listą rzeczy do realizacji w obrębie danego tworu. Zespół deweloperski złożony jest z profesjonalistów, których zadaniem jest dostarczenie – na zakończenie każdego Sprintu – „ukończonego” i gotowego do potencjalnego wydania przyrostu produktu. Z kolei Scrum Master jest odpowiedzialny za promowanie i wspieranie stosowania tej metodyki. Osiągają to poprzez wspieranie wszystkich w zrozumieniu teorii, jego praktyk, reguł i wartości. Pomagają również osobom spoza zespołu scrumowego zrozumieć, które z ich interakcji z zespołem są właściwe, a które nie.

Spotkania kluczem do sukcesu

Miarą powodzenia w Scrumie są spotkania. Ktoś mógłby powiedzieć, że jest ich zdecydowanie za dużo, ale odgrywają istotną rolę w finalizacji prac. Dzięki nim wszyscy członkowie zespołów scrumowych są informowani na bieżąco o postępie prac. Najbardziej charakterystycznym jest „daily standup”, czyli codzienne spotkanie dla zespołu deweloperskiego. Takie zebranie powinno trwać do 15 minut, a zespół w tym czasie planuje pracę na najbliższe dwadzieścia cztery godziny.

Kolejne z nich to „sprint planning” – spotkanie określające cel sprintu oraz plan pracy do wykonania w jego ramach. Jest to „sprint backlog”, który powstaje dzięki współpracy członków zespołu.

Następnym spotkaniem jest „sprint review”, który jest organizowany na zakończenie sprintu w celu przeprowadzenia inspekcji przyrostu i, jeśli zajdzie taka potrzeba, dostosowania backlogu produktu. Podczas przeglądu sprintu zespół oraz interesariusze wspólnie analizują to, co zostało ukończone w sprincie oraz rozważają, co mogłoby być wykonane w następnej kolejności, aby zoptymalizować wartość.

Ostatnim jest „sprint retrospective”. To okazja dla zespołu scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wcielony w życie w najbliższym sprincie.

Firmowy znak jakości

W firmie ITMAGINATION projekty w metodyce Scrum są realizowane już od lat, niezależnie od tego, czy zespół pracuje w strukturach organizacji, czy u zewnętrznego klienta. Dzięki temu systemowi możemy sprostać nawet największym oczekiwaniom, razem z klientem realizując ustalone wcześniej założenia. Choć jeszcze kilka lat temu Scrum nie był aż tak popularny, dzisiaj nie musimy już przekonywać żadnego z naszych klientów do pracy tą metodyką. W związku z tym ITMAGINATION może się na przestrzeni ostatnich lat poszczycić wieloma projektami, które zostały zrealizowane w założonym czasie i budżecie, jednocześnie nie zapominając o elastyczności przy określaniu wymagań względem powstającego produktu.

W ITMAGINATION grupy projektowe zawsze są dopasowane do potrzeb konkretnego projektu oraz klienta. Dobierając poszczególne osoby dbamy, aby zespół był międzyfunkcjonlany i samoorganizujący tak, by mógł samodzielnie wykonać wszystkie zadania w projekcie. W skład takiego teamu poza programistami wchodzą specjaliści od QA, bezpieczeństwa, DevOps, analizy biznesowej i systemowej czy User Experience.

Pracę zespołu deweloperskiego wspiera Scrum Master, dbając o organizacje i przebieg wydarzeń scrumowych. Usuwa przeszkody ograniczające postępy, głównie poprzez ułatwienie komunikacji między zespołem a pozostałymi interesariuszami. Scrum Master w szczególności jest pomocny, gdy projekt jest realizowany dla organizacji, w której Scrum nie jest jeszcze w pełni przyjęty.

Najważniejszą rolą z punktu widzenia klienta jest Product Owner. Jest on odpowiedzialny za maksymalizację wartości produktu poprzez odpowiednie zarządzanie backlogiem produktu (rejestrem wymagań), w tym jasnego artykułowania wymagań i porządkowania elementów w sposób pozwalający jak najlepiej osiągać założone cele. Rolę Product Ownera w projektach komercyjnych zazwyczaj przyjmuje przedstawiciel klienta, odpowiedzialnego za projekt po stronie zamawiającego. ITMAGINATION wspiera go dzięki analitykowi biznesowo-systemowemu, który wspomaga go w zarządzaniu wymaganiami, w tym analizie, definiowaniu oraz dokumentowaniu potrzeb. W zależności od potrzeb i doświadczenia klienta w projektach IT, analityk biznesowy może przejąć większą odpowiedzialność i pełnić rolę tzw. Proxy Product Ownera – w tym modelu klient bardziej skupia się na potrzebach/wymaganiach i ich odpowiedniej priorytetyzacji. Analityk z kolei dba o odpowiednią dekompozycję i dokumentację wymagań oraz przyjmuje odpowiedzialność za komunikowanie ich do zespołu deweloperskiego.

Niezależnie od wybranego sposobu pracy, Product Ownera zawsze wspiera Scrum Master, który dba, aby cele, zakres i domena produktowa były zrozumiałe dla wszystkich. Wspiera również komunikację pomiędzy wszystkimi zainteresowanymi stronami.

Z naszego doświadczenia wynika, że metodyka Scrum sprawdza się zarówno w projektach typu „start-up”, gdzie konieczne jest szybkie uruchomienie produktu (tzw. MVP – Minimum Viable Product), jak i projektów o dłuższym stażu, będących w tak zwanej „stabilizacji i rozwoju”. Wówczas sprinty mogą być łączone w tzw. „releasy”, gdzie biznes ma pełną kontrolę nad funkcjami i zmianami wdrażanymi na produkcję z wersji na wersję.


Autor: 

Michał Łaszcz – Senior Software Analyst w ITMAGINATION

 

 

Brief.pl - jedno z najważniejszych polskich mediów z obszaru marketingu, biznesu i nowych technologii. Wydawca Brief.pl, organizator Rankingu 50 Kreatywnych Ludzi w Biznesie.

BRIEF