Czym jest scrum i jak zacząć
Przewodnik po Scrum — czym jest, jak działa oraz jak zacząć
Przeglądaj tematy
Zacznij korzystać bezpłatnie z szablonu Jira Scrum
Usprawnij swój projekt i z łatwością planuj i śledź pracę oraz zarządzaj nią w sprintach. Szablon Jira Scrum obejmuje tablice, backlogi, harmonogramy, raporty i nie tylko!
Czym jest Scrum?
Scrum to ramy zarządzania projektami Agile, które pomagają zespołom strukturyzować swoją pracę i zarządzać nią za pomocą zestawu wartości, zasad i praktyk. Podobnie jak w drużynie rugby (stąd pochodzi nazwa Scrum) trenującej przed wielkim meczem, Scrum zachęca zespoły do uczenia się na podstawie doświadczeń, samodzielnej organizacji pracy nad problemem oraz refleksji nad sukcesami i porażkami w celu ciągłego doskonalenia.
Choć Scrum, o którym mowa, najczęściej znajduje zastosowanie w zespołach tworzących oprogramowanie, jego zasady oraz wypływające z niego wnioski można zastosować do wszystkich rodzajów prac zespołowych. Jest to jeden z powodów, dla których Scrum jest tak popularny. Scrum, tak często utożsamiany z ramami postępowania związanymi z zarządzaniem projektami Agile, stanowi opis zbioru spotkań, narzędzi i ról, które w połączeniu ze sobą pomagają zespołom uporządkować pracę i nią zarządzać
W tym artykule omówimy sposób tworzenia tradycyjnych ram postępowania Scrum, opierając się na Przewodniku Scrum oraz doświadczeniach Davida Westa, dyrektora generalnego Scrum.org. Na przykładach przedstawimy również, jak nasi klienci modyfikują te podstawowe zasady pod kątem własnych potrzeb. W tym zakresie porady i wskazówki w naszej serii filmów Agile Coach przedstawi Megan Cook, kierownik zespołu ds. produktu Jira i była trener Agile:
Artykuły dotyczące Scrum
Od silosów do spójności dzięki tablicom Scrum Jira
Tablica Scrum Jira przedstawia w sposób graficzny postępy cyklu programistycznego.
Zacznij korzystać za darmoPorównanie Agile i Scrum
Scrum jest często utożsamiany z Agile, ponieważ koncentruje się na ciągłym doskonaleniu, które stanowi podstawową zasadę 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 „zwinnym”, 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 definicją Scrum można znaleźć w Przewodniku po Scrumie 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
Definicja 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 zgodne z zasadami Lean redukuje marnotrawstwo i koncentruje się na sprawach podstawowych. Ramy postępowania Scrum są heurystyczne. Opierają się na ciągłym uczeniu i dostosowywaniu do zmiennych czynników. Wychodzi się w nich z założenia, że na początku projektu zespół nie wie wszystkiego i w miarę zdobywania doświadczenia będzie się rozwijał. Scrum jest skonstruowany tak, aby pomóc zespołom w naturalny sposób dostosować się do zmieniających się warunków i wymagań użytkowników, z uwzględnieniem modyfikacji priorytetów będącej częścią procesu oraz krótkich cykli wydawania, dzięki którym zespół może stale się uczyć i doskonalić.
Choć Scrum jest ustrukturyzowany, nie jest całkowicie sztywnym sposobem pracy. Sposób jego realizacji można dostosować do potrzeb każdej organizacji. Istnieje wiele teorii na temat tego, jak powinny pracować zespoły Scrum, aby odnieść sukces. Jednak ponad dziesięć lat doświadczenia we wspieraniu w realizacji zadań zespołów Agile w Atlassian wskazuje, że jasna komunikacja, przejrzystość i zaangażowanie w ciągłe doskonalenie powinny zawsze znajdować się w samym centrum wybranych wybranych ram postępowania. A reszta zależy od Ciebie.
Ramy postępowania Scrum
Ramy postępowania Scrum wyznaczają zestaw wartości, zasad i praktyk, które zespoły Scrum stosują, aby dostarczyć produkt lub usługę. Szczegółowo opisują członków zespołu Scrum i ich zakres odpowiedzialności, „artefakty” definiujące produkt i pracę nad utworzeniem produktu oraz wydarzenia Scrum, które wskazują zespołowi Scrum kierunek pracy.
Członkowie zespołu Scrum
Zespół Scrum jest mały, elastyczny i skupiony na dostarczaniu zatwierdzonych przyrostów produktu. Liczebność zespołu Scrum to zazwyczaj około 10 osób. To wystarczy, aby ukończyć znaczną ilość pracy w ramach sprintu. Zespół Scrum potrzebuje trzech konkretnych ról: product ownera, Scrum mastera i zespołu tworzącego oprogramowanie. Z uwagi na to, że zespoły Scrum obejmują różne działy, w skład zespołu tworzącego oprogramowanie wchodzą nie tylko programiści, ale również testerzy, projektanci, specjaliści ds. UX i inżynierowie eksploatacji.
Product owner w Scrum
Product ownerzy są mistrzami w dziedzinie swojego produktu. Skupiają się oni na zrozumieniu wymagań biznesowych, klienta i rynku, a następnie ustalają priorytet prac, które będą realizowane przez zespół inżynierski. Skuteczni product ownerzy:
- Tworzą backlog produktu i nim zarządzają.
- Ściśle współpracują z firmą i zespołem, zapewniając, aby elementy prac zawarte w backlogu produktu były dla wszystkich zrozumiałe.
- Udziela zespołowi jasnych wskazówek dotyczących funkcji, które należy dostarczyć w następnej kolejności.
-
Decyduje, kiedy dostarczyć 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ść. Ważne jest również, aby product owner był jedną osobą. Żaden zespół programistów nie chce otrzymywać niezgodnych ze sobą wskazówek od wielu product ownerów.
Scrum master
Scrum masterzy są mistrzami Scrum w swoich zespołach. Szkolą członków zespołu, product ownerów oraz inne osoby w firmie w zakresie procesu Scrum i poszukują możliwości doskonalenia swojej praktyki.
Skuteczny scrum master posiada dogłębną wiedzę na temat prac realizowanych przez zespół i może pomóc zespołowi w zoptymalizowaniu jego przejrzystości i przepływu dostaw. Jako główny koordynator, planuje zasoby (zarówno ludzkie, jak i logistyczne) wymagane na potrzeby planowania sprintu, spotkania standup, przeglądu sprintu i retrospektywy sprintu.
Zespół tworzący oprogramowanie w Scrum
Zespoły Scrum „odwalają całą robotę”. To mistrzowie zrównoważonych praktyk programistycznych. Najbardziej efektywne zespoły Scrum są zwarte, znajdują się w jednym miejscu i zazwyczaj składają się z pięciu do siedmiu członków. Przy określaniu rozmiaru zespołu najlepiej kierować się zasadą dwóch pizz Jeffa Bezosa, dyrektora generalnego Amazon (zespół powinien być na tyle mały, aby móc podzielić się dwoma pizzami).
Członkowie zespołu mają różne umiejętności i uczą się od siebie nawzajem, dzięki czemu nikt nie staje się wąskim gardłem w procesie dostarczania pracy. Mocne zespoły Scrum samodzielnie organizują swoją pracę i podchodzą do projektów z wyraźnym nastawieniem na „my”. Wszyscy członkowie zespołu pomagają sobie nawzajem, aby zapewnić skuteczne ukończenie sprintu.
To zespół Scrum wyznacza plan każdego sprintu. Jego członkowie prognozują ilość pracy, jaką ich zdaniem są w stanie wykonać w trakcie iteracji, biorąc pod uwagę prędkość osiąganą w dotychczasowych iteracjach. Stosowanie iteracji o stałej długości daje zespołowi tworzącemu oprogramowanie ważną wskazówkę na temat jego szacunków i procesu dostarczania, co z kolei przekłada się na rosnącą z czasem dokładność prognoz.
Artefakty Scrum
Artefakty Scrum to wykorzystywane przez zespół Scrum ważne informacje, które pomagają zdefiniować produkt i prace, które należy wykonać w celu opracowania tego produktu. W Scrum istnieją trzy artefakty: backlog produktu, backlog sprintu i przyrost z definicją „ukończenia”. Są to trzy stałe, do których zespół Scrum powinien sięgać podczas sprintów i w szerszej perspektywie czasowej.
- Backlog produktu to podstawowa lista prac do wykonania prowadzona przez product ownera lub menedżera produktu. Jest to dynamiczna lista funkcji, wymagań, ulepszeń i poprawek, która stanowi zestaw danych wejściowych backlogu sprintu. Jest to w zasadzie lista zadań do wykonania dla zespołu. Backlog produktu jest w ciągłym użyciu. Product owner prowadzi go, modyfikując priorytety zawartych w nim zadań, ponieważ w miarę zdobywania nowych informacji i pojawiania się zmian na rynku poszczególne elementy mogą być nieadekwatne, a problemy można rozwiązać w inny sposób.
- Backlog sprintu to lista elementów, historyjek użytkowników lub poprawek błędów wybranych przez zespół programistyczny do implementacji w bieżącym cyklu sprintu. Przed każdym sprintem w trakcie spotkania dotyczącego planowania sprintu (omówionego w dalszej części artykułu) zespół wybiera, które elementy backlogu produktu będzie realizował w trakcie sprintu. Backlog sprintu może być elastyczny i ewoluować w trakcie sprintu. Nie może jednak doprowadzić do odejścia od podstawowego celu sprintu, czyli tego, co zespół chce osiągnąć w trakcie bieżącego sprintu.
- Przyrost (lub cel sprintu) jest zdatnym do użycia produktem końcowym sprintu. W Atlassian zwykle prezentujemy „przyrost” podczas demonstracji na koniec sprintu, w trakcie której zespół pokazuje, co zostało ukończone podczas sprintu. W praktyce możesz nie spotkać się ze słowem „przyrost”, ponieważ często określa się go mianem tego, co zespół rozumie pod pojęciem stanu „Gotowe”, kamienia milowego, celu sprintu, a nawet pełnej wersji lub wydanego epiku. Wszystko zależy od sposobu, w jaki zespoły definiują pojęcie stanu „Gotowe” oraz cele sprintu. Przykładowo niektóre zespoły decydują się na wydawanie czegoś dla klientów pod koniec każdego sprintu. W związku z tym w ich rozumieniu stan „gotowe” będzie tożsamy ze stanem „wydane”. Takie podejście może być jednak nierealne w przypadku innych typów zespołów. Załóżmy, że pracujesz nad produktem serwerowym, który możesz wysyłać do klientów tylko co kwartał. Wówczas nadal możesz zdecydować się na pracę w dwutygodniowych sprintach, ale stan „gotowe” może w tym przypadku oznaczać ukończoną część większej całości, która zostanie wysłana w jednej turze. Należy jednak pamiętać, że im dłuższy okres do wydania oprogramowania, tym większe ryzyko przekroczenia terminu.
Jak widać, istnieje wiele wariantów, nawet w obrębie artefaktów, które zespół może definiować po swojemu. Dlatego ważne jest zachowanie otwartości na rozwój sposobu prowadzenia działań, nawet pod względem artefaktów. Może się zdarzyć, że przyjęte rozumienie terminu „gotowe” będzie powodowało w zespole stres i konieczne będzie cofnięcie się oraz wybranie nowej definicji.
W odniesieniu do ram postępowania powinno się przyjąć takie samo, zgodne z nurtem Agile podejście, jak do produktu. Warto poświęcić chwilę, aby sprawdzić, jak przebiegają działania, w razie potrzeby wprowadzić korekty i nie starać się forsować niczego tylko dla zachowania zgodności.
Spotkania lub wydarzenia w Scrum
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. Niektóre zespoły uważają je za uciążliwe i powtarzalne, podczas gdy dla innych stanowią niezbędny element odprawy. My radzimy zacząć od zastosowania wszystkich wydarzeń w trakcie dwóch sprintów, aby sprawdzić, jaki będzie ich odbiór. Następnie można przeprowadzić szybką retrospektywę, aby stwierdzić, w których obszarach warto wprowadzić poprawki.
Poniżej znajduje się lista wszystkich kluczowych wydarzeń, w jakich może uczestniczyć zespół Scrum:
-
Porządkowanie backlogu: czasami nazywane również pielęgnowaniem backlogu, to wydarzenie należące do obowiązków product ownera. Głównym zadaniem product ownera jest kierowanie pracami nad produktem w sposób zgodny z wizją produktu oraz ciągłe monitorowanie rynku oraz klienta. W tym celu taka osoba prowadzi tę listę, wykorzystując informacje zwrotne od użytkowników oraz zespołu programistycznego do ustalania priorytetów, porządkowania elementów listy i utrzymywania jej w gotowości do podjęcia prac w dowolnej chwili. Więcej informacji na temat prowadzenia dobrego backlogu znajdziesz tutaj.
-
Planowanie sprintu: podczas tego spotkania cały zespół tworzący oprogramowanie planuje prace do wykonania (zakres) podczas bieżącego sprintu. Spotkanie prowadzi Scrum Master. W jego trakcie zespół uzgadnia cel sprintu. Następnie do sprintu dodaje się historyjki użytkowników z backlogu produktu. Historyjki te są zawsze zgodne z celem, a ich wykonalność w trakcie sprintu uzgadnia się z zespołem Scrum.
Na końcu spotkania dotyczącego planowania sprintu każdy członek zespołu Scrum musi dokładnie wiedzieć, co można dostarczyć w ramach sprintu i jak uzyskać przyrost. -
Sprint: sprint to konkretny przedział czasu, w trakcie którego zespół Scrum współpracuje nad ukończeniem przyrostu. Zazwyczaj sprinty trwają dwa tygodnie, jednak niektórym zespołom łatwiej opracować zakres dla okresów tygodniowych, a innym dostarczanie wartościowych przyrostów ułatwiają miesięczne sprinty. Dave West ze Scrum.org radzi, aby sprinty były tym krótsze, im bardziej złożona praca i im więcej niewiadomych. Jednak tak naprawdę wszystko zależy od Twojego zespołu. Jeśli taki model nie działa, nie obawiaj się wprowadzania zmian! W trakcie tego okresu product owner i zespół tworzący oprogramowanie mogą w razie potrzeby renegocjować zakres. W tym tkwi istota empirycznego charakteru Scrum.
Wszystkie wydarzenia — od planowania po retrospektywę ]— odbywają się w trakcie 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 stand-up: jest to bardzo krótkie codzienne spotkanie, które, żeby było prościej, odbywa się o tej samej porze (zazwyczaj rano) i w tym samym miejscu. Wiele zespołów stara się, aby to spotkanie trwało 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.
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 poproszenie 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. -
Przegląd sprintu: 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 taki przyrost zostanie wydany, i w większości przypadków tak właśnie się dzieje.
Takie 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 sprintu: 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 stworzenie okazji, aby zespół mógł pochylić się na tym, co poszło dobrze i co trzeba poprawić następnym razem, a mniej na tym, co poszło nie tak.
Zacznij korzystać bezpłatnie z szablonu Jira Scrum
Usprawnij swój projekt i z łatwością planuj i śledź pracę oraz zarządzaj nią w sprintach. Szablon Jira Scrum obejmuje tablice, backlogi, harmonogramy, raporty i nie tylko!
Wartości Scrum
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. Są uważane za niezbędne warunki sukcesu zespołu Scrum.
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 dla zespołu Scrum to po prostu gotowość do kwestionowania status quo lub wszystkiego, co stoi na drodze do sukcesu. Członkowie zespołu Scrum powinni mieć odwagę i poczucie bezpieczeństwa, 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 ilości pracy.
Otwartość
Codzienne spotkanie stand-up sprzyja otwartości, która pozwala zespołom otwarcie 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. Ponadto dzielenie się postępami działa wzmacniająco na 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, Kanban i Agile
Scrum stanowi tak popularne ramy postępowania Agile, że często Scrum i Agile są mylnie ze sobą utożsamiane. Istnieją jednak i inne ramy postępowania, takie jak Kanban, który jest popularną alternatywą. Niektóre firmy decydują się nawet na przyjęcie modelu hybrydowego Scrum i Kanban funkcjonującego pod nazwą „Scrumban” lub „Kanplan”, który jest po prostu modelem Kanban z backlogiem.
Zarówno w Scrum, jak i w Kanban do monitorowania postępów prac wykorzystuje się metody wizualne, takie jak tablica Scrum czy tablica Kanban. W obydwu przypadkach nacisk kładzie się na wydajność i podział złożonych zadań na mniejsze fragmenty łatwiejszych w zarządzaniu prac, jednak ich sposoby osiągnięcia tego celu są różne.
Scrum koncentruje się na mniejszych iteracjach o stałej długości. Po ustaleniu okresu przewidzianego na sprint wskazuje się historyjki lub pozycje backlogu produktu, które można wdrożyć w trakcie danego cyklu sprintu. Z kolei w Kanban liczba zadań lub prac w toku (limit WIP) do wdrożenia w ramach bieżącego cyklu jest na początku stała. Następnie oblicza się wstecznie czas potrzebny do zaimplementowania tych funkcji.
Kanban nie jest tak ustrukturyzowany jak Scrum. Poza limitem prac w toku ten model pozostawia stosunkowo duże pole do interpretacji. Natomiast w Scrum implementacja opiera się na kilku kategorycznych koncepcjach, takich jak przegląd sprintu, retrospektywa, codzienne spotkanie scrumowe itp. W tym modelu kładzie się również nacisk na interdyscyplinarność, czyli zdolność zespołu Scrum do działania w taki sposób, aby osiągnięcie celu było możliwe niezależnie od członków zewnętrznych. Zebranie zespołu interdyscyplinarnego nie jest proste. Pod tym względem Kanban znacznie łatwiej zastosować, natomiast Scrum uważa się za fundamentalną zmianę w sposobie myślenia i funkcjonowania zespołu tworzącego oprogramowanie.
Zacznij działać w Scrumie
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, pozostawiając jednocześnie wystarczająco dużo przestrzeni, aby firmy mogły nadać im własny, indywidualny charakter.
Możliwość porządkowania złożonych zadań w łatwe do zarządzania historyjki użytkowników sprawia, że rozwiązanie to doskonale sprawdza się w przypadku trudnych projektów. Ponadto wyraźne 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. Koncepcje mniejszych iteracji, codziennych spotkań scrumowych i przeglądów 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.
Powiązane zasoby
Zacznij korzystać bezpłatnie z szablonu Jira Scrum
Usprawnij swój projekt i z łatwością planuj i śledź pracę oraz zarządzaj nią w sprintach. Szablon Jira Scrum obejmuje tablice, backlogi, harmonogramy, raporty i nie tylko!
Kanban
Wprowadzenie do metodyki Kanban tworzenia oprogramowania zgodnego z Agile i korzyści, jakie może przynieść Twojemu zespołowi Agile.
Przeczytaj ten artykuł