Framework (pol. ramy postępowania) Scrum jest opisany szczegółowo w Scrum Guide (pol. Przewodnik po Scrumie). W związku z licznymi pytaniami, chcieliśmy krótko Wam te ramy przybliżyć. Jako osoby pracujące w Scrumie, powinniście wiedzieć, jakimi zasadami się kierować przy tworzeniu lub rozwijaniu produktu.
Scrum Guide powstał w latach ‘90, aby opisać i przybliżyć zasady opisujące framework Scrum. Jednak jeszcze wcześniej, bo już w latach ‘80, dwóch japońskich naukowców (Hirotaka Takeuchi i Ikujiro Nonaka) zbadało i opisało działania japońskich i amerykańskich firm takich jak np. Fuji-Xerox, Canon, Honda, które uzyskały (wtedy) przewagę konkurencyjną (np. lustrzanka AE-1 od Canon). Wyniki swych badań opublikowali w Harvard Business Review w artykule “New New Product Development Game”. Istotną cechą, którą wskazywali jest m.in. samoorganizujący się zespół. Na szkoleniach opisuję anegdotę o filmie Apollo 13, a konketnie tę scenę:
Przed zgromadzonymi w pokoju ludźmi stawia się jasny cel (włożenie okrągłego filtra w kwadratowy) i osoby te, mając całą swoją wiedzę, doświadczenie i materiały dostępne w lądowniku, muszą ten problem rozwiązać. To właśnie znaczy dla mnie samoorganizujący się i interdyscyplinarny (czyli posiadający ekspertów w różnych dziedzinach) zespół. Tak też powinien wyglądać idealny Zespół Deweloperski, posiadający kompetencje niezbędne do wytworzenia i utrzymania produktu.
Opisywany w Przewodniku Scrum, jest stosowany do rozwijania oprogramowania, sprzętu, oprogramowania wbudowanego (ang. embedded), sieci zintegrowanych usług i autonomicznych pojazdów. Znalazł swoje zastosowanie w szkolnictwie, administracji publicznej, marketingu, zarządzaniu operacjami w organizacjach, budowy samochodu lub samolotu.
Podręcznik stanowi o filarach ram Scrum, czyli o:
Przejrzystość
Cała praca zespołu Scrumowego powinna być jawna. Wszystkie reguły, które stosują, powinny być dla nich zrozumiałe,
Inspekcja
Zespół Scrumowy powinien badać artefakty i wydarzenia tak, aby wychwytywać wszelkie niedociągnięcia z nimi związane.
Scrum wyróżnia elementy frameworku, w których można Inspekcję przeprowadzić:
- Planowanie Sprintu (ang. Sprint Planning),
- Codzienny Scrum (ang. Daily Scrum),
- Przegląd Sprintu (ang. Sprint Review),
- Retrospektywa Sprintu (ang. Sprint Retrospective),
Adaptacja
Jeżeli Zespół Scrumowy po dokonaniu inspekcji dojdzie do wniosku, że należy poprawić proces lub produkt, to należy to zrobić “najszybciej, by ograniczyć dalsze odstępstwa”.
Scrum Guide opisuje w dalszej części:
- Wartości Scrum, które zostały dodane na wyraźną prośbę użytkowników Scrum w 2016 roku,
- poszczególne role – Właściciel Produktu (ang. Product Owner), Scrum Master oraz Zespół Deweloperski (ang. Development Team),
- wydarzenia – Planowanie, Codzienny Scrum, Przegląd Sprintu, Retrospektywa,
- artefakty – Backlog Produktu, Backlog Sprintu, Przyrost, Definicja Ukończenia.
Więcej o składnikach scruma możecie znaleźć w naszych artykułach w ramach cyklu agilestarter, oraz z drugiej strony, w samym Przewodniku po Scrum, także w wersji polskiej.
Przewodnik jest regularnie aktualizowany. Ostatnie zmiany miały miejsce w 2016 roku – aktualizacja pod kątem Wartości Scrum oraz w 2017 roku – aktualizacja, w której m.in. dodano praktykę uwzględniania (zaktualizowany scrum guide) w Backlogu Sprintu zadań usprawnieniowych wynikających z Retrospektyw.
Scrum Guide jest jedynym oficjalnym przewodnikiem po metodzie. Możecie spotkać wiele pozycji książkowych opisujących sam framework lub poszczególne jego elementy, jednakże polecam od czasu do czasu wrócić do podstaw i poczytać co twórcy Scruma – Ken Schwaber i Jeff Sutherland – mieli na myśli.