Scrum to ramy zarządzania projektami Agile, które pomagają zespołom organizować i nadzorować swoją pracę za pomocą wartości, zasad i praktyk. Scrum zachęca zespoły do uczenia się na podstawie doświadczeń, samodzielnej organizacji podczas pracy nad problemem oraz refleksji nad sukcesami i porażkami w celu ciągłego doskonalenia.

Kto głównie używa ram postępowania Scrum?

Zespoły programistyczne i inżynierskie szeroko wykorzystują metodologię Scrum, aby dostosować się do zmieniających się wymagań i zarządzać kosztami. Jednak programiści i inżynierowie nie są jedynymi użytkownikami. Ich zasady i wnioski można zastosować do wszelkiego rodzaju pracy zespołowej, począwszy od zespołów marketingowych aż po zespoły IT.

Scrum często utożsamia się z Agile, ponieważ koncentruje się na ciągłym doskonaleniu, podstawowej zasadzie metodyki Agile. Jednak Scrum to ramy postępowania, dzięki którym realizuje się prace, podczas gdy Agile to filozofia.

Filozofia Agile koncentruje się na ciągłym, stopniowym doskonaleniu poprzez małe i częste wydania. Nie można tak po prostu stać się Agile, czyli „elastycznym”, ponieważ wymaga to zaangażowania całego zespołu w zmianę podejścia do dostarczania korzyści klientom.

Można jednak wykorzystać ramy postępowania, takie jak Scrum, aby ułatwić przejście na taki sposób myślenia oraz praktyczne wdrożenie zasad Agile w codziennej komunikacji i pracy.

Różnicę między metodyką Agile a Scrum można znaleźć w Przewodniku po Scrum i Manifeście Agile. Manifest Agile podkreśla cztery wartości:

• Ludzie i interakcje ponad procesy i narzędzia

• Działające oprogramowanie ponad szczegółową dokumentację

• Współpraca z klientem ponad negocjacje umów

• Reagowanie na zmiany ponad realizację założonego planu

Scrum opiera się na empiryzmie i myśleniu zgodnym z zasadami Lean. Empiryzm głosi, że wiedza pochodzi z doświadczenia, a decyzje są podejmowane na podstawie obserwacji.

Myślenie Lean, często praktykowane wraz z tablicami Kanban, zmniejsza marnotrawstwo i zapewnia koncentrację na sprawach podstawowych. Teoria Scrum odnosi się do podstawowych zasad: empiryzmu, myślenia Lean oraz iteracyjnego doskonalenia.

Prawidłowo wcielane w życie zapewniają one wskazówki odnośnie do struktury, działań i ciągłego doskonalenia implementacji metodyki Scrum.

Ramy postępowania Scrum zawdzięczają swój sukces w dużym stopniu pionierskiej pracy Jeffa Sutherlanda. Sutherland opracował Scrum wraz z Kenem Schwaberem na początku lat 90., aby odpowiedzieć na wyzwania związane z zarządzaniem złożonymi projektami programistycznymi.

Sutherland wniósł do zarządzania projektami wyjątkową perspektywę, która kładła nacisk na pracę zespołową, zdolność adaptacji i jasną komunikację. Jego doświadczenie nabyte w środowiskach cechujących się wysoką presją ukształtowało oparty na współpracy i iteracyjny charakter ram Scrum, czyniąc je skutecznym narzędziem do rozwiązywania złożonych problemów.

Dzisiaj wpływ Sutherlanda jest widoczny w tym, jak zespoły Scrum organizują pracę, dostarczają wartość i ciągle się doskonalą.

Do zapewnienia wartości poprzez iteracyjne sprinty Scrum wymaga określonych ról i komponentów, w tym scrum mastera, product ownera i zespołu Scrum.

Ramy postępowania Scrum wyznaczają zestaw wartości, zasad i praktyk, które zespoły Scrum stosują, aby dostarczyć produkt lub usługę. Są w nim szczegółowo opisani członkowie zespołu Scrum i zakresy ich odpowiedzialności, czyli artefakty Scrum. 

Te artefakty określają produkt i pracę potrzebną do jego wytworzenia. Z kolei wydarzenia w Scrum wskazują zespołowi kierunek pracy. Zespół Scrum to niewielka, wielofunkcyjna, samozarządzająca jednostka odpowiedzialna za dostarczanie wartościowego przyrostu produktu podczas każdego sprintu.

Chociaż Scrum jest uporządkowany, nie jest całkowicie sztywny. Jego wykonanie można dostosować do potrzeb organizacji. Istnieje wiele teorii na temat tego, jak zespoły Scrum powinny pracować, aby osiągnąć sukces. 

Po ponad dekadzie pomagania zespołom Agile w realizacji zadań w Atlassian przekonaliśmy się jednak, że jasna komunikacja, przejrzystość i ciągłe dążenie do doskonalenia powinny zawsze stanowić sedno wybranych ram postępowania. 

Reszta zależy od Ciebie.

Zespół Scrum jest mały, zwinny i skupiony na dostarczaniu zatwierdzonych przyrostów produktu. Zazwyczaj jest to efektywna, zwarta grupa około 10 osób.

Często jest on jednak wystarczająco duży, aby wykonać znaczną ilość pracy w ramach sprintu. W zespołach Scrum potrzebne są trzy role: product ownera, Scrum Mastera i zespołu programistów.

Product ownerzy są mistrzami w dziedzinie swojego produktu. Skupiają się oni na zrozumieniu wymagań biznesowych, klienta i rynku.

Osoba w tej roli ustala priorytety prac do wykonania dla zespołu inżynierskiego. Skuteczni product ownerzy:

• Tworzą backlog produktu i nim zarządzają.

• Wykorzystują zarządzanie backlogiem sprintu poprzez opracowywanie, porządkowanie i przejrzyste administrowanie backlogiem produktu w celu efektywnego planowania i ustalania priorytetów.

• Ściśle współpracują z firmą i zespołem, dbając, aby zgłoszenia zawarte w backlogu produktu były dla wszystkich zrozumiałe.

• Udzielają zespołowi jasnych wskazówek dotyczących funkcji, które należy dostarczyć w następnej kolejności.

• Decydują, kiedy wydać produkt, skłaniając się przy tym w kierunku częstszych dostaw.

Product owner nie zawsze jest menedżerem produktu. Product ownerzy koncentrują się na dbaniu o to, aby zespół programistów dostarczał firmie jak największą wartość.

Product owner musi być osobą fizyczną. Żaden zespół programistów nie chce otrzymywać niezgodnych ze sobą wskazówek od wielu product ownerów.

Scrum masterzy są mistrzami metodyki Scrum w swoich zespołach. Uczą zespoły, product ownerów i firmę o procesów Scrum i starają się robić to w coraz doskonalszy sposób. 

Głównym zadaniem Scrum mastera jest podnoszenie efektywności zespołu przez trening, usuwanie przeszkód oraz ułatwianie procesów Scrum. W ten sposób mogą zwiększać ogólną wydajność oraz produktywność zespołu.

Skuteczny Scrum master dogłębnie rozumie pracę zespołu i może pomóc jego członkom zoptymalizować przejrzystość i przepływ dostaw.

Jako główni koordynatorzy planują niezbędne zasoby (zarówno ludzkie, jak i logistyczne). Zasoby te obejmują wszystko, od planowania sprintu, przez spotkania zespołu, przeglądy sprintu, aż po jego retrospektywy.

Zespoły programistyczne Scrum odwalają najgorszą robotę. Składają się one z mistrzów praktyk zrównoważonego rozwoju. 

Najbardziej efektywne zespoły Scrum są zżyte, a ich członkowie (zazwyczaj są to zespoły 5–7 osobowe) pracują w jednym miejscu. Przy określaniu rozmiarów zespołu można kierować się zasadą dwóch pizz sformułowaną przez Jeffa Bezosa, CEO firmy Amazon, zgodnie z którą zespoły powinny być na tyle małe, aby dwie pizze wystarczyły dla wszystkich członków.

Członkowie zespołu powinni dysponować różnorodnymi umiejętnościami i uczyć się od siebie wzajemnie, aby żaden z nich nie spowalniał pracy kolegów nad dostarczeniem produktu. Silne zespoły Scrum praktykują samoorganizację i podchodzą do projektów w duchu pracy zespołowej. 

Członkowie zespołu pomagają sobie wzajemnie , aby pomyślnie ukończyć sprint. Zespół Scrum kieruje planowaniem każdego ze sprintów. 

Na podstawie danych historycznych o tempie pracy członkowie zespołu przewidują, ile pracy mogą wykonać podczas iteracji. Dane historyczne o wydajności służą zespołowi do przewidywania swojej zdolności produkcyjnej i poprawiania dokładności planowania sprintu. 

Utrzymywanie stałej długości iteracji daje zespołowi programistów ważne informacje zwrotne o procesach szacowania i realizacji, dzięki czemu prognozy stają się coraz dokładniejsze. W oparciu o tę ewaluację zespół rozważa, co można osiągnąć podczas kolejnego sprintu.

Artefakty Scrum to podstawowe informacje, których zespół Scrum używa w celu określenia produktu oraz tego, jaką pracę należy wykonać, aby go stworzyć. W Scrum istnieją trzy artefakty: backlog produktu, backlog sprintu i przyrost z definicją ukończenia.

Zespół Scrum powinien zastanowić się nad tymi trzema stałymi podczas sprintów i ich opracowywania.

Jest to podstawowa lista prac, które product owner lub menedżer produktu musi wykonać i obsługiwać. To dynamiczna lista funkcji, wymagań, ulepszeń i poprawek, która działa jako dane wejściowe dla backlogu sprintu. 

Zasadniczo jest to lista zadań do wykonania zespołu. 

Product owner stale weryfikuje backlog produktu, zmienia jego priorytety i prowadzi go. W miarę jak zespoły zdobywają więcej wiedzy lub gdy zmienia się sytuacja rynkowa, elementy mogą przestać być istotne lub problemy mogą zostać rozwiązane w inny sposób. 

Elementy backlogu są szeregowane według priorytetów, aby zmaksymalizować wartość dla klienta, dzięki czemu dostarczane funkcje bezpośrednio zwiększają zadowolenie klienta i długoterminową wartość biznesową.

Backlog to lista elementów, historyjek użytkowników lub poprawek błędów wybranych przez zespół programistów do wdrożenia w bieżącym cyklu sprintu. Podczas planowania każdego sprintu zespół wybiera z backlogu elementy, nad którymi będzie pracować.

Backlog sprintu może być elastyczny i może ewoluować podczas sprintu. Jednak podstawowy cel sprintu — to, co zespół chce osiągnąć w bieżącym sprincie — pozostaje niezmienny.

Przyrost, znany powszechnie jako cel sprintu, to użyteczny produkt końcowy sprintu. W firmie Atlassian zazwyczaj demonstrujemy przyrost podczas demonstracji kończącej sprint, kiedy to zespół prezentuje to, co zostało ukończone podczas sprintu. 

Ten termin jest często określany mianem zespołowej definicji ukończenia, kamienia milowego, celu sprintu lub nawet pełnej wersji czy też wysłanego epiku. Zależy to od definicji ukończenia przyjętej przez zespół oraz definicji celów sprintu.

Przykładowo niektóre zespoły wydają coś swoim klientom pod koniec każdego sprintu. Dlatego ich definicja ukończenia oznaczałaby wysyłkę. Jak widać zespół może zdefiniować wiele wariantów, nawet w obrębie artefaktów.

Ważne jest więc, aby pozostać otwartym na ewolucję sposobu utrzymania swoich artefaktów. Być może dana definicja ukończenia powoduje nadmierny stres w zespole, dlatego trzeba ją zweryfikować i wybrać nową.

Ramy postępowania Scrum obejmują praktyki, wydarzenia i spotkania, które zespoły Scrum regularnie organizują. Największe różnice między zespołami uwidaczniają się w ich podejściu do wydarzeń Agile.

Radzimy wykorzystać wszystkie wydarzenia w dwóch sprintach, aby zobaczyć, jak to wygląda. Można wtedy przeprowadzić szybki przegląd, aby dowiedzieć się, gdzie trzeba wprowadzić poprawki. Poniżej znajduje się lista wszystkich kluczowych wydarzeń, w jakich może uczestniczyć zespół Scrum:

Za te działania, nazywane czasem porządkowaniem backlogu, odpowiada product owner. Główne zadanie product ownera polega na prowadzeniu rozwoju produktu zgodnie z przyjętą wizją i stałym monitorowaniu rynku oraz potrzeb klientów. 

Utrzymuje on tę listę, opierając się na opiniach użytkowników i zespołu programistycznego w celu ustalania priorytetów oraz dbając o porządek na liście, tak aby była ona gotowa do pracy w dowolnym momencie.

Na tym spotkaniu cały zespół programistów planuje pracę do wykonania (zakres) podczas bieżącego sprintu. To spotkanie, znane jako planowanie sprintu, prowadzi Scrum Master.

W jego trakcie zespół określa cel sprintu i planuje pracę do wykonania. Określone historyjki użytkowników są następnie dodawane do sprintu z backlog produktu.

Te historyjki zawsze są zgodne z celem oraz zaakceptowane przez zespół Scrum jako możliwe do wdrożenia podczas sprintu. Pod koniec spotkania planowania wszyscy członkowie zespołu Scrum powinni wiedzieć, co ma zostać dostarczone podczas sprintu i jak ma zostać osiągnięty przyrost.

Sprint to faktyczny okres czasu, w którym zespół Scrum współpracuje w celu ukończenia przyrostu. Te iteracje czasowe nazywane są sprintami i zazwyczaj trwają od jednego do czterech tygodni. 

Typową długością sprintu są dwa tygodnie, choć niektóre zespoły uważają, że okres tygodnia ułatwia określenie zakresu, a miesiąc dostarczanie wartościowego przyrostu. Dave West ze Scrum.org doradza, że im bardziej złożona praca i im więcej niewiadomych, tym krótszy powinien być sprint. 

To jednak zależy od Twojego zespołu i nie obawiaj się wprowadzić zmian, jeśli coś nie działa! W tym okresie zakres może być renegocjowany między właścicielem produktu a zespołem programistów, jeśli zajdzie taka potrzeba. 

To stanowi główny element empirycznej natury Scrum. Wszystkie wydarzenia — od planowania po retrospektywę — odbywają się podczas sprintu. Po ustaleniu konkretnego przedziału czasu dla sprintu nie powinno się go zmieniać w trakcie procesu tworzenia produktu. 

Dzięki temu zespołowi łatwiej będzie się uczyć na dotychczasowych doświadczeniach i zastosować wyciągnięte wnioski do przyszłych sprintów.

Codzienne spotkanie scrumowe lub spotkanie zespołu

To bardzo krótkie codzienne spotkanie, które odbywa się o tej samej porze (zazwyczaj rano) i w tym samym miejscu, żeby było prościej. Te decydujące spotkania w określonym czasie nazywane są codziennymi spotkaniami scrumowymi i mają za zadanie sprawdzanie postępów w realizacji celu sprintu, koordynację działań zespołu i rozpoznawanie przeszkód. 

Wiele zespołów stara się, aby to trwało ono 15 minut, jednak to jedynie wskazówka. Bywa ono również nazywane „codziennym stand-upem”, co podkreśla krótki czas jego trwania. 

Celem codziennego spotkania scrumowego jest bieżące informowanie wszystkich członków zespołu, upewnienie się, że dążą do realizacji celu sprintu i zaplanowanie działań na kolejne 24 godziny. Możesz skorzystać z szablonu codziennego spotkania stand-up, aby rozpocząć sprawnie spotkania i szybciej się zorganizować.

W trakcie spotkania stand-up zgłaszane są wszelkie obawy w zakresie realizacji celów sprintu oraz blokery. Powszechną praktyką podczas przeprowadzania spotkań stand-up jest proszenie każdego członka zespołu o udzielenie odpowiedzi na trzy pytania w kontekście dążenia do osiągnięcia celu sprintu:

• Co udało mi się zrobić wczoraj?

• Co mam zamiar zrobić dzisiaj?

• Czy istnieją jakieś przeszkody? 

Widzieliśmy jednak spotkania, które szybko zamieniały się w odczytywanie notatek z kalendarza na dzień poprzedni i kolejny. Ideą spotkania stand-up jest sprowadzenie rozpraszającej gadaniny do codziennego spotkania, aby zespół mógł skoncentrować się na pracy przez resztę dnia. 

Jeśli więc zamieni się ono w codzienne odczytywanie notatek z kalendarzy, nie bój się wprowadzić zmian i działać kreatywnie.

Pod koniec sprintu zespół zbiera się na nieformalną sesję w celu obejrzenia demonstracji lub skontrolowania przyrostu. Zespół tworzący oprogramowanie przedstawia elementy backlogu oznaczone jako Gotowe, aby interesariusze i inni członkowie zespołu mogli się do nich ustosunkować. 

Product owner może zdecydować, czy przyrost zostanie wydany (w większości przypadków tak właśnie się dzieje). Spotkanie przeglądowe odbywa się również w sytuacji, gdy product owner modyfikuje backlog produktu w oparciu o bieżący sprint w sposób, który wpływa na przebieg sesji planowania kolejnego sprintu.

W przypadku sprintów miesięcznych warto ograniczyć czas przeglądu sprintu do maksymalnie czterech godzin.

Retrospektywa polega na zebraniu zespołu w celu udokumentowania i omówienia sukcesów i porażek w kontekście sprintu, projektu, ludzi lub relacji, narzędzi, a nawet konkretnych wydarzeń. 

Chodzi o umożliwienie zespołowi pochylenie się na tym, co poszło dobrze i co trzeba poprawić następnym razem, a mniej na tym, co poszło nie tak.

W 2016 roku do Przewodnika po Scrumie dodano pięć wartości Scrum. Te wartości wyznaczają kierunek pracy, działań i zachowań zespołu Scrum. Skuteczna współpraca, zaangażowanie w zadania i przestrzeganie zasad Scrum są niezbędne do osiągnięcia sukcesu zespołu w środowisku Agile.

Zaangażowanie

Ponieważ zespoły Scrum są małe i zwinne, każdy członek znacząco przyczynia się do sukcesu zespołu. Z tego względu każdy członek zespołu powinien brać na siebie zadania, które jest w stanie ukończyć, i nie podejmować się zbyt dużych wyzwań. 

Komunikacja dotycząca postępów pracy powinna być intensywna i często mieć postać spotkań stand-up.

Odwaga

Odwaga to dla zespołu Scrum po prostu gotowość do kwestionowania status quo lub wszystkiego, co stoi na drodze do sukcesu. Członkowie zespołu Scrum powinni mieć odwagę i czuć się bezpiecznie, aby próbować nowych rzeczy. 

Zespół Scrum powinien mieć odwagę i czuć się na tyle bezpiecznie, aby móc otwarcie mówić o przeszkodach, postępach projektu, opóźnieniach itp.

Koncentracja

Centralnym elementem przepływu pracy w zespołach Scrum jest sprint, czyli jasno wyznaczony okres, w którym zespół wykonuje ustaloną ilość pracy. Sprint zapewnia strukturę, ale także pomaga skupić się na ukończeniu zaplanowanej pracy.

Otwartość

Codzienne spotkania stand-up sprzyjają otwartości, która pozwala zespołom szczerze mówić o pracach w toku i blokerach. Zespoły Scrum w Atlassian często odpowiadają na następujące pytania:

• Co było przedmiotem mojej pracy wczoraj?

• Nad czym pracuję dzisiaj?

• Jakie problemy mnie blokują?

Pomaga to uwidocznić postępy i zidentyfikować blokery. Dzielenie się postępami wzmacnia również zespół.

Szacunek

Siła zespołu Agile polega na współpracy i uznaniu, że każdy członek zespołu przyczynia się do realizacji prac w ramach sprintu. Członkowie zespołu cieszą się wzajemnie ze swoich osiągnięć i okazują szacunek sobie nawzajem, product ownerowi, interesariuszom i scrum masterowi.

Scrum to najczęściej stosowane ramy postępowania Agile, dostępne są jednak także inne. Kanban oferuje alternatywne podejście, które kładzie nacisk na ciągłe dostarczanie i przepływ, a nie na iteracje o stałej długości.

W Kanban:

• Zgłoszenia są wizualizowane na tablicy i zarządzane się nimi za pomocą limitów prac w toku (WIP).

• Zespoły wykonują nową pracę tylko wtedy, gdy zwalnia się potencjał wykonawczy, co pozwala uzyskać miarowy, ciągły przepływ.

• Nie ma określonych ról ani ceremonii, dzięki czemu Kanban jest bardziej elastyczny i lżejszy niż Scrum.

Kiedy warto korzystać z metodyki Kanban:

• Idealnie sprawdza się w zespołach z ciągłym strumieniem napływających zadań (np. wsparcia lub operacyjnych).

• Przydatna, gdy priorytety często się zmieniają, a stałe zobowiązania sprintu są trudne do utrzymania.

Kiedy warto korzystać z metodyki Scrum:

• Najlepiej nadaje się do opracowywania produktów lub funkcji, w których kluczowe znaczenie ma przyrostowe dostarczanie, struktura i przewidywalność.

• Sprawdza się dobrze w przypadku zespołów, które korzystają z jasno określonych ról, ceremonii i celów sprintu.

Podejścia hybrydowe:

Niektóre zespoły łączą elementy obu ram postępowania w tak zwany Scrumban lub Kanplan (Kanban z backlogiem). To hybrydowe rozwiązanie umożliwia zespołom utrzymanie backlogu Scrum i dyscypliny planowania, przy jednoczesnym wykorzystaniu elastyczności Kanban w wykonaniu zadań.

Scrum Alliance jest jednym z najważniejszych źródeł wiedzy dla tych, którzy chcą lepiej poznać zasady Scrum i rozwijać swoją karierę. Jako globalna organizacja zajmująca się promowaniem ram postępowania Scrum, Scrum Alliance oferuje szereg certyfikatów i programów szkoleniowych.

Są one przeznaczone dla Scrum Masterów, product ownerów i innych praktyków Scrum. Szczególnie popularne są certyfikaty Certified Scrum Master (CSM) i Certified Scrum Product Owner (CSPO).

Zapewniają one profesjonalistom solidne podstawy w zakresie praktyk i wartości Scrum. Zdobycie tych kwalifikacji potwierdza zaangażowanie w metodyki Agile i otwiera drzwi do nowych możliwości w zakresie zarządzania projektami i tworzenia oprogramowania. 

Dzięki dostępowi do aktywnej społeczności, ciągłej edukacji i uznawanych w branży certyfikatów Scrum Alliance pomaga osobom i organizacjom odnieść sukces z pomocą Scrum.

Wdrożenie metodyki Scrum i innych metodologii Agile może być znaczącą zmianą dla każdej organizacji, w której pomaga trener Agile. Trenerzy Agile ściśle współpracują z zespołami Scrum, aby przeprowadzić je przez zmianę statusu i poprowadzić członków zespołu do stosowania zasad Scrum w ich codziennej pracy. 

Osoby te wspierają wydarzenia związane ze Scrumem, takie jak planowanie sprintów i retrospektywy, a także szkolą zespoły w zakresie najlepszych praktyk współpracy i komunikacji. Trenerzy Agile odgrywają kluczową rolę w eliminowaniu przeszkód hamujących postępy zespołu.

Głównym celem jest umożliwienie zespołom Scrum skupienia się na dostarczaniu wartości. Zapewniając dostosowane szkolenia i wsparcie, trenerzy Agile umożliwiają członkom zespołu przyjęcie praktyk Agile.

Będzie to wspierać kulturę ciągłego doskonalenia i zwiększać efektywność zespołu Scrum w wielu zespołach i projektach.

Nawet doświadczone zespoły Scrum stają przed wyzwaniami, takimi jak opór przed zmianą, niejasny kierunek i ograniczone przeszkolenie Scrum. Zaczynając na niewielką skalę, z jednym projektem lub zespołem, można stopniowo pokonać te przeszkody.

Kompleksowe szkolenie i ciągły coaching zwiększają zaufanie do metod Scrum i Agile. Jasne cele, role, i obowiązki sprawiają, że wszyscy pracują w sposób skoordynowany.

Regularne retrospektywy i sesje informacyjne pomagają zespołom w refleksji, adaptacji i doskonaleniu. Poprzez wczesne stawienie czoła tym wyzwaniom zespoły Scrum mogą budować odporność, lepiej współpracować i odnosić sukcesy z ramami postępowania Scrum.

Śledzenie postępów i efektywności zespołu Scrum jest niezbędne do ciągłego doskonalenia i sukcesu projektu. Zespoły Scrum często wykorzystują prędkość sprintu, wykresy spalania i wyniki satysfakcji klienta do oceny wydajności. 

Monitorowanie czasu wdrażania, czasu cyklu i gęstości usterek może także dostarczyć analiz dotyczących przepływu pracy zespołu i jakości produktu. Regularne przeglądy sprintów i retrospektywy są kluczowymi wydarzeniami w Scrum.

Przeglądy te pozwalają zespołom zastanowić się nad swoimi osiągnięciami, zidentyfikować obszary wzrostu i celebrować pomyślne zakończenie sprintu. Poprzez konsekwentne mierzenie tych wskaźników i działanie w oparciu o opinie zespoły Scrum ulepszają swoje praktyki, dostarczają większą wartość dla klienta i zapewniają ciągły sukces w ramach postępowania Scrum.

Same ramy postępowania Scrum są proste. Reguły, artefakty, wydarzenia i role są łatwe do zrozumienia. Przyjęte w nich częściowo nakazowe podejście faktycznie pomaga wyeliminować niejasności w procesie tworzenia oprogramowania.

Jednocześnie dają wystarczająco dużo przestrzeni, aby firmy mogły nadać im własny, indywidualny charakter. Organizacja złożonych zadań w możliwe do zarządzania historyjki użytkowników sprawia, że jest to idealne rozwiązanie w przypadku złożonych projektów. 

Jasne rozgraniczenie ról i planowanych wydarzeń zapewnia przejrzystość i zbiorową odpowiedzialność na każdym etapie cyklu programistycznego. Szybkie wydania podtrzymują wysoki poziom motywacji zespołu, a użytkownicy są zadowoleni, ponieważ widzą postępy w krótkim czasie.

Dogłębne zrozumienie Scrum może jednak zająć sporo czasu, zwłaszcza jeśli zespół tworzący oprogramowanie jest przyzwyczajony do typowego modelu kaskadowego. Mniejsze iteracje, codzienne spotkania scrumowe i przeglądy sprintów oraz wyznaczenie Scrum Mastera mogą stanowić trudną zmianę kulturową dla nowego zespołu.

Jednak długoterminowe korzyści znacznie przewyższają czas poświęcony na początkową naukę. Powodzenie, z jakim stosuje się Scrum w tworzeniu złożonych produktów sprzętowych i programowych w różnych branżach, sprawia, że te ramy postępowania są atrakcyjnym rozwiązaniem dla Twojej organizacji.

Jeśli chcesz nauczyć się korzystania z metodyki Scrum w systemie Jira, zapoznaj się z tym samouczkiem.