Blog

Scrum to metoda wywodząca się z Agile, określająca zasady postępowania (ang. framework) dla Zespołów, które w zmiennym środowisku wytwarzają złożone produkty. Metoda skupia się na Zespołach i nie opisuje ani nie podpowiada, jak należy zbudować organizację, by Scrum działał w niej dobrze. Twórcy intencjonalnie ograniczyli definicję metody do absolutnego minimum tak, by umożliwić wypełnienie frameworku własnym kontekstem, ale też i po to, aby zachęcić do szukania własnych rozwiązań.

Jak działa Scrum

U podstaw Scruma leży empiryzm, który wpisany jest we wszystkie zdarzenia metody, i który działa na poziomie zarówno produktu, jak i procesu. Aby empiryzm działał, czyli by możliwa była inspekcja tego, co udało się osiągnąć i ocena sposobu, w jaki to osiągnięto, niezbędna jest przejrzystość – nieograniczony dostęp do rzeczywistych informacji na temat produktu, procesów, narzędzi, organizacji etc.

Scrum definiuje trzy odpowiedzialności: Product Ownera, Scrum Mastera oraz Developerów, którymi są specjaliści niezbędni do tego, by Zespół Scrum był w stanie samodzielnie wytworzyć wartość, której dostarczenia się podejmuje. Źródłem pracy dla Zespołu jest Backlog Produktu, w którym Product Owner określa kolejność realizacji poszczególnych elementów tak, by najbardziej efektywnie wykorzystać dostępny czas Developerów.

Praca odbywa się w iteracjach zwanych Sprintami, w których czasie do produktu dodawane są nowe funkcjonalności i cechy. Na początku Sprintu cały Zespół Scrum tworzy prognozę (ang. forecast) tego, które elementy Backlogu Produktu zostaną zrealizowane w czasie rozpoczynającej się iteracji i jaki w związku z tym będzie Cel Sprintu, po czym Developerzy tworzą własny Backlog Sprintu, opisujący plan działań, które pozwolą osiągnąć ten Cel.

Developerzy każdego dnia omawiają postęp prac i dokonują niezbędnej adaptacji Backlogu Sprintu, pracują też z Product Ownerem nad doskonaleniem elementów Backlogu Produktu, doprecyzowując je i dekomponując na części dostatecznie małe, by dało się je zrealizować w jednej z kolejnych iteracji. W Sprincie Developerzy tworzą jeden lub kilka Przyrostów, czyli nowych wersji produktu, zawierających zrealizowane i działające funkcjonalności, po czym Zespół Scrum spotyka się na Przeglądzie Sprintu z zaproszonymi przez Product Ownera interesariuszami lub klientami i ocenia to, co udało się osiągnąć oraz dokonuje niezbędnej adaptacji planów rozwoju produktu.

Przyrost, a więc nowa wersja produktu, musi być w stanie pozwalającym na jego użycie. Aby wszyscy uczestnicy Przeglądu Sprintu tak samo rozumieli, co to znaczy, że prace nad wytworzeniem jakiejś funkcjonalności są ukończone, Developerzy w porozumieniu z Product Ownerem określają taką listę warunków, jakie muszą być spełnione i czynności, jakie muszą zostać wykonane w ramach prac developerskich. Ta Definicja Ukończenia (ang. Definition of Done) ułatwia też Developerom szacowanie pracochłonności wymagań znajdujących się w Backlogu Produktu oraz dyskusję nad prognozą Sprintu w trakcie Planowania Sprintu.

Zespół Scrum kończy iterację Retrospekcją Sprintu, podczas której dokonuje przeglądu swych działań i przygotowuje listę usprawnień, jakich dokona w kolejnej iteracji, aby osiągnąć większą efektywność i skuteczniej realizować Cele Sprintu, po czym rozpoczyna się kolejna iteracja (między Sprintami nie ma przerw).

Dlaczego to działa?

Scrum pozwala efektywnie tworzyć złożony produkt w mocno zmiennym środowisku, ponieważ na czas iteracji – trwającej maksymalnie miesiąc – umożliwia Zespołowi skupienie się na dążeniu do konkretnego Celu Sprintu i realizacji zbioru elementów Backlogu Produktu, które pozwalają ten Cel osiągnąć.

Z drugiej strony Product Owner, a poprzez niego interesariusze, zyskują swobodę dowolnego kształtowania produktu poprzez ciągłe doskonalenie Backlogu Produktu, bo nie trzeba z tym czekać do zakończenia prac w wielomiesięcznych projektach (praca odbywa się w krótkich iteracjach), jest więc możliwość zmiany kierunku rozwoju produktu praktycznie co iterację.

Empiryzm, który przejawia się w pętli inspekcji-adaptacji, będącej elementem każdego zdarzenia w Scrumie powoduje, że tak produkt, jak i zaangażowana w jego rozwój organizacja, dokonuje ciągłych usprawnień i adaptacji i zwinnie reaguje na zmiany rynkowe, w upodobaniach klientów, w technologiach, uwarunkowaniach prawnych etc.

Developerzy są zaangażowani w to, co robią, bo mają poczucie rzeczywistego wpływu: współuczestniczą w tworzeniu Backlogu Produktu, dokonują szacunku pracochłonności, definiują sposób pracy w Sprintach, wdrażają usprawnienia w narzędziach i procesach, jakimi się posługują.

Agile to nie tylko Scrum

Scrum doskonale sprawdza się tam, gdzie tworzony jest produkt i gdzie niezbędna jest wspólna praca grupy specjalistów nad rozwiązywaniem złożonych problemów; należy pamiętać wszakże, że Agile to nie tylko Scrum, a do niektórych typów prac często lepszym wyborem będzie Kanban w połączeniu z jakąś inną metodą lub procesem.