Scrum – iteracyjne i przyrostowe ramy zarządzania procesem produkcyjnym () zgodne ze Scrum Guide. Może mieć zastosowanie w realizacji procesów produkcyjnych w oparciu o metodyki zwinne zgodne z manifestem Agile.
Rozwój produktu, a więc proces produkcyjny podzielony jest na trwające maksymalnie jeden miesiąc iteracje, zwane sprintami czyli cyklami produkcyjnymi. Po każdym sprincie zespół powinien być w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany w procesie tworzenia i rozwoju oprogramowania – . Nie jest on jednak ograniczony tylko do tej dziedziny.
Historia Hirotaka Takeuchi i Ikujiro Nonaka wprowadzili termin Scrum w kontekście rozwoju produktu w artykule Harvard Business Review z 1986 r. pt. „Nowa gra rozwoju nowych produktów” (ang. „”). Takeuchi i Nonaka uzasadniali później w The Knowledge Creating Company, że jest to forma „tworzenia wiedzy organizacyjnej, [...] szczególnie dobra we wprowadzaniu innowacji w sposób ciągły, przyrostowy i spiralny” (ang. „”).
Autorzy opisali nowe podejście do rozwoju produktu komercyjnego, którego celem jest zwiększenie szybkości i elastyczności. Koncepcja powstała w oparciu o studia przypadków z firm produkujących samochody, kserokopiarki i drukarki. Autorzy nazywali to podejściem holistycznym lub rugby, ponieważ cały proces jest wykonywany przez jeden wielofunkcyjny zespół w wielu nakładających się fazach, podczas których zespół „próbuje pokonać dystans jako jednostka, podając piłkę tam i z powrotem” (ang. „”) (W rugby scrum jest metodą wznowienia gry i polega to na tym, że gracze pakują się ściśle razem z opuszczonymi głowami, a następnie próbują zdobyć piłkęScrum, abbreviated form of scrummage, Oxford English Dictionary Online..)
Na początku lat 90. Ken Schwaber wykorzystywał to, co w przyszłości stało się Scrumem w swojej firmie Advanced Development Methods. W tym samym czasie Jeff Sutherland, John Scumniotales i Jeff McKenna opracowali podobne podejście w Easel Corporation, odnosząc się do niego za pomocą pojedynczego słowa scrum.
W 1995 roku Sutherland i Schwaber wspólnie przedstawili artykuł opisujący ramy postępowania zgodnego z metodyką scrum (ang. ). Miało to miejsce podczas warsztatów projektowania i wdrażania obiektów biznesowych (ang. ) odbywających się w ramach OOPSLA '95 (Object-Oriented Programming, Systems, Languages & Applications '95) w Austin w Teksasie. W ciągu następnych lat Schwaber i Sutherland współpracowali, aby połączyć ten materiał zarówno ze swoim doświadczeniem, jak i z rozwijającymi się dobrymi praktykami – w celu opracowania tego, co stało się znane jako scrum.
W 2001 roku Schwaber współpracował z Mikiem Beedlem, w celu opisania metodyki scrum w książce pod tytułem „Agile Software Development with Scrum”. Podejście scrum do planowania i zarządzania rozwojem produktów polega na wprowadzeniu uprawnień decyzyjnych na poziom operacyjny.
W 2002 roku Schwaber wraz z innymi założył Scrum Alliance i ustanowił serię akredytacji „Certified Scrum”. Schwaber opuścił Scrum Alliance pod koniec 2009 roku i założył Scrum.org, która nadzoruje równoległą serię akredytacji „Professional Scrum”.
Od 2009 roku metodyka scrum jest oficjalnie zdefiniowana w publicznym dokumencie o nazwie „The Scrum Guide”. Dokument ten był aktualizowany 5 razy. Obecnie najnowsza wersja pochodzi z listopada 2020 roku.
W 2018 roku Schwaber i społeczność Scrum.org wraz z liderami społeczności Kanban opublikowali przewodnik Kanban dla zespołów scrum.
Opis ogólny Zespół pracuje w określonych przedziałach czasowych zwanych przebiegami lub sprintami (ang. ). Zmiany wprowadzane w każdym przebiegu powinny wnosić zauważalną dla użytkowników nową wartość funkcjonalną. Przebieg nie może trwać dłużej niż jeden miesiąc. W praktyce sprinty trwają od 1 do 4 tygodni. Zaleca się stosowanie przebiegów o stałych długościach.
Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci historyjek (ang. ). Każda historyjka opisuje jedną cechę systemu. Właściciel produktu (ang. ) jest też zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego przebiegu. Po tym formułowany jest rejestr wymagań (ang. ). Cel przebiegu jest zapisywany w widocznym miejscu w pokoju członków zespołu.
Następnie podczas planowania przebiegu (ang. ) wybierane są zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu przebiegu. Szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (ang. ).
Po planowaniu zespół przechodzi do realizacji przebiegu. W jego trakcie Właściciel Produktu powinien cały czas pracować z zespołem nad jak najlepszym zrozumieniem wymagań, nie ingerując jednocześnie w sposób ich implementacji. Nie powinno się także zmieniać zakresu Sprintu.
Zespół z założenia jest ciałem samoorganizującym się, nie ma mowy o odgórnym przypisywaniu zadań poszczególnym członkom zespołu. Dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji.
Naczelną zasadą metody jest przeprowadzanie codziennych (maksymalnie 15-minutowych) spotkań (ang. ), na których omawiane są zadania zrealizowane poprzedniego dnia, problemy występujące przy ich realizacji oraz zadania do wykonania w dniu spotkania.
Każdy sprint kończy się spotkaniem (ang. ), na którym prezentowany jest produkt wykonany podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani projektem. Na spotkaniu każdy członek zespołu może zabrać głos i wyrazić opinię o produkcie. Na zakończenie ustalany jest termin spotkania planistycznego do następnego przebiegu.
Realizacja projektu według scrum skupia się na: dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu, włączaniu się przyszłych użytkowników w proces wytwórczy, samoorganizacji zespołu projektowego.
Zespół i odpowiedzialności Zazwyczaj zespół scrum składa się z mniej niż 10 osób. Dobrze, gdy ma charakter interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Główne role w projekcie grają: scrum master, właściciel produktu (ang. ) i deweloperzy (ang. ).
Odpowiedzialności główne Deweloperzy (ang. ) – grupa osób, składająca się od trzech do dziewięciu osób, odpowiedzialna za dostarczenie produktu Właściciel produktu (ang. ) – osoba reprezentująca klienta. Właściciel produktu może być członkiem zespołu, jednak nie jest zalecane, aby jednocześnie był Scrum Masterem. Scrum master – osoba odpowiedzialna za usuwanie wszelkich przeszkód uniemożliwiających zespołowi wykonanie zadania oraz za poprawną implementację procesu i metod.
Wydarzenia w scrumie Scrum składa się 5 wydarzeń, z czego najważniejszym z nich jest sprint, który zawiera w sobie 4 pozostałe. Każde z tych wydarzeń może być wykorzystane do inspekcji oraz adaptacji. Sugerowane jest, aby wydarzenia odbywały się o tej samej porze i miejscu, co pozwala wprowadzić regularność i przewidywalność
Wydarzenia Sprint – główne wydarzenie w sprincie, w którym odbywa się cała praca potrzebna do wytworzenia przyrostu (ang. increment). Sprint nie powinien trwać dłużej niż miesiąc. Po zakończeniu sprintu, natychmiast powinien wystartować następny. Planowanie sprintu (ang. sprint planning) – wydarzenie mające służyć zaplanowaniu pracy na nowo rozpoczynający się sprint. Zespół deweloperski podejmuje zadania z rejestru wymagań (ang. product backlog) do rejestru sprintu (ang. sprint backlog), na podstawie priorytetów otrzymanych od właściciela produktu (ang. product owner). Planowanie sprintu nie powinno trwać dłużej niż 8 godzin dla miesięcznego sprintu. Daily scrum (inaczej stand-up) – codzienne spotkanie zespołu deweloperskiego, które ma służyć sprawdzeniu postępu prac w trakcie trwania sprintu. Nie powinno trwać dłużej niż 15 minut. Przegląd sprintu (ang. sprint review) – scrum team prezentuje interesariuszom wartość wytworzoną podczas trwania sprintu, oraz wspólnie ustalają co powinno zostać wykonane w następnej kolejności. Czas trwania tego wydarzenia, to 4 godziny dla miesięcznego sprintu. Retrospektywa sprintu (ang. sprint retrospective) – spotkania przeznaczone dla zespołu scrumowego, które ma służyć inspekcji i adaptacji, po każdym zakończonym sprincie. Czas trwania tego wydarzenia, to 3 godziny dla miesięcznego sprintu.
Przypisy
Linki zewnętrzne Scrum.org Przewodnik po Scrumie: Reguły Gry – Ken Schwaber and Jeff Sutherland Scrum Alliance Jarosław Łojko: Metodyka Scrum w pigułce agileadept.pl, 2021-06-22. [dostęp 2021-09-20]
Manifest programowania zwinnego („Manifest Agile”) w języku polskim
Kategoria:Zarządzanie projektami Kategoria:Procesy tworzenia oprogramowania