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ść, czyli nieograniczony dostęp do rzeczywistych informacji na temat produktu, procesów, narzędzi, organizacji etc.

Scrum definiuje tylko trzy role: Product Ownera, Scrum Mastera oraz Zespół Developerski, w skład którego wchodzą nie tylko programiści, ale wszyscy specjaliści niezbędni do tego, by Zespół ten był w stanie samodzielnie wykonać zadania, których się podejmuje. Źródłem wymagań jest Backlog Produktu, w którym Product Owner określa kolejność realizacji tak, by najbardziej efektywnie wykorzystać dostępny czas Developerów.

Praca odbywa się w iteracjach zwanych Sprintami, w czasie których do produktu iteracyjnie dodawane są nowe funkcjonalności. Na początku Sprintu Zespół Developerski dokonuje wraz z Product Ownerem szacunku (ang. forecast), które wymagania zostaną zrealizowane w czasie rozpoczynającej się iteracji i jaki w związku z tym będzie Cel Sprintu, po czym Zespół tworzy własny Backlog Sprintu opisujący listę czynności, które pozwolą osiągnąć ten Cel.

Zespół Developerski każdego dnia omawia postęp prac i dokonuje niezbędnych adaptacji Backlogu Sprintu, pracuje też z Product Ownerem nad doskonaleniem wymagań w Backlogu Produktu doprecyzowując je i dekomponując na elementy dostatecznie małe, by dało się je zrealizować w jednej iteracji. Sprint kończy się prezentacją Przyrostu Produktu, czyli nowej wersji produktu, zawierającej zrealizowane i działające funkcjonalności, po czym Zespół wraz z Product Ownerem i zaproszonymi przez niego interesariuszami lub klientami ocenia to, co udało się osiągnąć i dokonuje niezbędnej adaptacji planów rozwoju produktu.

Przyrost Produktu, a więc produkt w stanie na koniec Sprintu, musi być w stanie pozwalającym na jego wdrożenie (wydanie), jeśli taka będzie decyzja Product Ownera. Aby wszyscy uczestnicy Przeglądu Sprintu tak samo rozumieli co to znaczy, że opisana jakimś wymaganiem funkcjonalność jest ukończona, Zespół w porozumieniu z Product Ownerem określa listę warunków, jakie muszą być spełnione i czynności, jakie muszą zostać wykonane dla ukończonego wymagania. Taka Definicja Ukończenia (ang. Definition of Done) ułatwia też Zespołowi szacowanie pracochłonności wymagań w Backlogu Produktu oraz dyskusję nad szacunkiem w trakcie Planowania Sprintu.

Zespół Developerski kończy Sprint dokonując retrospektywy 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, a zazwyczaj dwa tygodnie) umożliwia Zespołowi skupienie się nad realizacją konkretnego Celu Sprintu i listy wymagań, które się na ten Cel składają.

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 też 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 w otoczeniu (na przykład na rynku, w upodobaniach klientów, w technologiach, uwarunkowaniach prawnych etc.).

Zespoły są zaangażowane 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 (na przykład utrzymaniowych) zdecydowanie lepszą metodą będzie Kanban.