Co to jest Scrum? Scrum jaki jest, każdy widzi. Ot, choćby na rysunku powyżej. Ale czy na pewno? W ramach cyklu artykułów poświęconych podstawowym zagadnieniom pora na wyjaśnienie „mechaniki” Scruma, czyli podstawowych zagadnień, które tworzą szkielet tej metody pracy. Zgodnie z definicją ze Scrum Guide’a w obręb Scruma wchodzą: Zespoły Scrumowe oraz związane z nimi role, wydarzenia, artefakty i reguły. Ale co to tak naprawdę oznacza…

Role: Deweloperzy + Product Owner + Scrum Master = Zespół Scrumowy

W Scrumie mamy tylko 3 role. Deweloperzy odpowiadają za sposób wykonania zadań (JAK), Product Owner odpowiada za wybór zadań do wykonania (CO), a Scrum Master czuwa nad tym, aby przebieg prac był zgodny z zasadami Scruma i ustalonymi przez zespół. Co ważne, Deweloperzy mogą mieć różne role, specjalizować się w określonych pracach (tester, analityk, webdeweloper, programista dowolnego języka itp. itd.), ale w zespole wszyscy powinni być równi i dlatego zawsze nazywamy ich tylko i aż deweloperami. Product Owner to ciało jednoosobowe, jedyne, które może zlecać zadania zespołowi, dlatego bardzo ważne jest wsparcie jego roli w organizacji. Z drugiej strony mamy Scrum Mastera, który obok pracy z zespołem i Product Ownerem, powinien właśnie pracować z organizacją, by rozumiała specyfikę zasad Scruma, przestrzegała ich i wspierała.



Wydarzenia: Planowanie Sprintu + Codzienny Scrum + Przegląd Sprintu + Retrospektywa = Sprint

Praca Scrumem zakłada przede wszystkim pracę w iteracjach, czyli powtarzalnych cyklach czasowych nazywanych Sprintem. Jaką długość będą miały Sprinty zależy od Zespołu Scrumowego. W obrębie Sprintu mają miejsce cztery rodzaje wydarzeń, służące określonym celom. Planowanie Sprintu, jak sama nazwa wskazuje, służy ustaleniu na samym początku Sprintu, nad czym Zespół będzie pracował, w jaki sposób i dla jakiego celu. Pieczę nad postępem pracy Zespół zapewnia sobie, organizując Codzienny Scrum, czyli miniplanowania, które służą codziennej weryfikacji stanu prac i ewentualnym korektom zaplanowanych zadań.  Na koniec Sprintu Zespół przedstawia swoje dokonania Product Ownerowi i interesariuszom w czasie Przeglądu Sprintu, a zaraz po weryfikuje swój sposób pracy i wprowadza ulepszenia w czasie Retrospektywy. Każde z tych spotkań oparte jest na trzech regułach, o których za chwilę opowiem, w punkcie czwartym.

Artefakty: Backlog Produktu + Backlog Sprintu + Przyrost

Artefakty, czyli innymi słowy zobrazowanie pracy i wartości Zespołu Scrumowego. Backlog Produktu to uporządkowana lista wszystkich rodzajów zadań potrzebnych do rozwoju, utrzymania i naprawy produktu. Lista ta jest otwarta dla wszystkich w organizacji, natomiast Product Owner ma ostateczne słowo co do treści, wyglądu i zawartości Backlogu. To jest jego narzędzie pracy nad produktem. Backlog Sprintu z kolei to analogiczne narzędzie, ale dla Zespołu Deweloperskiego, który dzięki temu artefaktowi w pełni panuje nad pracami zaplanowanymi na Sprint. Przyrost natomiast to ukończona przez Zespół zgodnie z Definicją Ukończenia praca na koniec każdego i wszystkich razem Sprintów.

Reguły: Przejrzystość + Inspekcja + Adaptacja

Te trzy reguły to filary, które mają zapewnić poprawne działania Scruma w duchu Agile, i powinny być stosowane cały czas, na każdym kroku pracy Scrumem. Przejrzystość zapewnia Zespowi Scrumowemu i wszystkim w organizacji dostęp do całości prac i takie samo rozumienie każdego elementu Scruma. Dzięki temu nie ma niejasności i nieporozumień. Inspekcja pozwala na bieżące monitorowanie i weryfikowanie przedmiotu pracy i sposobu pracy Zespołu, natomiast Adaptacja powinna być wynikiem tejże Inspekcji i prowadzić do niezbędnych zmian naprowadzających Zespół na właściwy tor pracy.

Rozszerzenie na temat każdego z krótko przedstawionych przeze mnie elementów Scruma oczywiście znajdziecie w Scrum Guide – Schwaber i Sutherland bardzo jasno i dostępnie tłumaczą w nim, jak wygląda poprawne i właściwe stosowanie Scruma.

Na koniec chciałabym jeszcze natomiast wspomnieć o jednej, bardzo ważnej sprawie. Defincja Scruma precyzuje, że jest to framework procesu, a nie proces czy technika sama w sobie. Wg słownika Cambridge jest to:

– a supporting structure around which something can be built,

– a system of rules, ideas, or beliefs that is used to plan or decide something,

czyli po naszemu struktura, szkielet lub ramy. Dlaczego to ważne? Bo często słyszę, jak ludzie mylnie zakładają, że jakaś technika, czy jakieś narzędzie, czy jakaś zasada pochodzą ze Scruma i dlatego trzeba je stosować. A tymczasem słowo framework i dalsze wyjaśnienie definicji, którą możecie przeczytać właśnie w Scrum Guidzie jasno tłumaczy, że Scrum to tylko zestaw podstawowych zasad, ról czy spotkań, tworzących właśnie te ramy, czy szkielet, w obrębie których każdy zespół samodzielnie decyduje, jak chce pracować. Pamiętajcie zatem, że taka choćby tablica to nie Scrum, tak samo jak używanie planning pokera, skali Fibonacciego, czy post itów, prowadzenie Codziennego Scruma na stojąco, bądź przygotowywanie prezentacji na Przegląd Sprintu. Scrum to tylko te kilka elementów, które opisałam wyżej. W co je ubierzecie, co do nich dodacie, jak je zastosujecie, to już wasza, suwerenna decyzja, którą w każdej chwili możecie zmienić. Większość niezrozumień i porażek Scruma w firmach wynika właśnie z faktu bezkrytycznego adaptowania najróżniejszych dodatków, braku refleksji nad ich wpływem na sedno pracy i zagubienia w trakcie poprawnego stosowania reguł dotyczących samego frameworka. To, co sprawdza się nawet w stu zespołach, może kompletnie zdezorganizować sto pierwszy zespół, dlatego pamiętajcie, by adaptować pomysły innych ostrożnie i zawsze zaczynać od weryfikacji, czemu mają one służyć. Alistair Cockburn zastosował swego czasu bardzo ładną metaforę, porównującą te wszystkie dodatki do Scruma do skorupiaków i glonów obrastających kadłub statku, co znacząco go spowalnia i uniemożliwia mu szybkie płynięcie. Im mniej zatem obciążycie sobie framework ponadprogramowymi praktykami, tym łatwiej i szybciej będziecie pracować w duchu Scruma.

PS. Na temat mitów związanych ze Scrumem możecie posłuchać w odcinku osiemnastym podcastu „Porządny Agile” autorstwa Kuby Szczepanika i Jacka Wieczorka, współautorów Agile247. Z odcinka #068 dowiesz się kiedy Scrum nie jest odpowiedzią.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x