Close

Scrum

Dowiedz się od najlepszych, jak korzystać ze Scrum

Przeglądaj tematy

Czym jest Scrum?

Scrum to ramy postępowania, które ułatwiają zespołom współpracę. Podobnie jak w drużynie rugby (skąd pochodzi ich nazwa) trenującej przed wielkim meczem, 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.

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 oraz ról, które w połączeniu ze sobą pomagają zespołom uporządkować pracę i nią zarządzać.

W tym artykule omówimy, jak wyglądają tradycyjne ramy 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 konkretnych potrzeb. W tym zakresie porady i wskazówki przedstawi nam w naszej serii filmów Agile Coach Megan Cook, nasza kierownik zespołu ds. produktu Jira Software i była trener Agile:

Artykuły dotyczące Scrum

[KONTYNUACJA]

Ramy postępowania

Ludzie często utożsamiają Scrum z Agile, ponieważ Scrum 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 sposób myślenia. 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 wdrożenie zasad Agile w codziennej komunikacji i pracy.

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ć.

Ramy postępowania Scrum | Atlassian Agile Coach

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.

Artefakty Scrum

Zacznijmy od wskazania trzech artefaktów w Scrum. Artefakty to coś, co tworzymy, na przykład narzędzie do rozwiązania problemu. W Scrum te trzy artefakty to backlog produktu, backlog sprintu oraz przyrost zgodny z przyjętą definicją stanu „gotowe”. Są to trzy stałe w zespole Scrum, do których ciągle sięgamy i w które inwestujemy z biegiem czasu.

  • 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.

Porada eksperta:

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

Jednym z lepiej znanych elementów ram postępowania Scrum jest zestaw następujących po sobie wydarzeń lub spotkań, które zespoły Scrum regularnie organizują. Największe różnice między zespołami uwidaczniają się w ich podejściu do tego typu wydarzeń. 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:

  1. 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.

  2. 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.

  3. 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.

  4. Codzienny scrum lub spotkanie standup: 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ę zakończyć to spotkanie w ciągu 15 minut, jednak to jedynie wskazówka. Bywa ono również nazywane „codziennym standupem”, co podkreśla krótki czas jego trwania. Celem codziennego scrumu 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 standup zgłaszane są wszelkie obawy w zakresie realizacji celów sprintu oraz blokery.

    Powszechną praktyką podczas przeprowadzania spotkań standup 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 standup 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ę on w codzienne odczytywanie kalendarzy, nie bój się wprowadzić zmian i iść w bardziej kreatywnym kierunku.

  5. Przegląd sprintu: pod koniec sprintu zespół zbiera się na nieformalną sesję w celu przeprowadzenia demonstracji lub kontroli 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.

  6. 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.

Trzy role o zasadniczym znaczeniu dla sukcesu Scrum

Zespół Scrum wymaga 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 ownerem nie zawsze jest menedżer produktu. Product ownerzy koncentrują się na zapewnieniu, aby zespół tworzący oprogramowanie dostarczał najwyższą wartość dla firmy. Ponadto ważne jest, aby product owner był pojedynczą osobą. Żaden zespół tworzący oprogramowanie nie chce otrzymywać sprzecznych 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.

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, codzienny scrum 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.

Ale dlaczego 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, 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.

Jednak dogłębne zrozumienie Scrum może zająć sporo czasu, zwłaszcza jeśli zespół tworzący oprogramowanie jest przyzwyczajony do typowego modelu kaskadowego. Koncepcje mniejszych iteracji, codziennych spotkań Scrum, przeglądów sprintów i 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.

Claire Drumond
Claire Drumond

Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.

Up Next
Sprints