Scrum to struktura, która pozwala na rozwiązywanie złożonych problemów adaptacyjnych, jednocześnie dostarczając produkty o najwyższej możliwej wartości. Scrum jest lekki, prosty do zrozumienia, lecz trudny do opanowania.

Twórcy skruktury scrum zainspirowali się empirycznym sprawdzeniem i dostosowaniem pętli sprzężenia zwrotnego, aby poradzić sobie ze złożonością i ryzykiem. Scrum kładzie nacisk na podejmowanie decyzji na podstawie rzeczywistych wyników, a nie na spekulację. Czas dzieli się na krótkie kadencje, zwane sprintami, zazwyczaj tygodniowe lub dwutygodniowe. Produkt jest zawsze przechowywany w stanie potencjalnie możliwym do załadowania (odpowiednio zintegrowanym i przetestowanym). Pod koniec każdego sprintu interesariusze i członkowie zespołu spotykają się, aby zobaczyć wyniki prac oraz ocenić potencjalny przyrost wytworzonego produktu i zaplanować kolejne kroki. Scrum to prosty zestaw ról, obowiązków i spotkań, które nigdy się nie zmieniają. Usuwając zbędną nieprzewidywalność, jesteśmy w stanie poradzić sobie z niezbędną nieprzewidywalnością ciągłego odkrywania i uczenia się. Zespół scrumowy składa się z takich ról jak: Product Owner, Development Team i Scrum Master. Zespoły są samoorganizujące się i są wielofunkcyjne. Samoorganizujące się zespoły wybierają, w jaki sposób najlepiej wykonywać swoją pracę, a nie są kierowane przez osoby spoza zespołu. Zespoły interdyscyplinarne posiadają wszystkie kompetencje potrzebne do wykonania pracy bez uzależnienia od osób, które nie są częścią zespołu. Model zespołu w scrumie ma na celu optymalizację elastyczności, kreatywności i produktywności.

Role w scrumie

W ramach Scrum Framework zdefiniowane są role: zespół scrumowy, Scrum Master, Właściciel produktu scrum, Scrum Product Owner. Każda z tych ról ma zdefiniowany zestaw obowiązków i tylko dzięki spełnieniu tych obowiązków i dzięki ścisłej współpracy, projekt może zostać zakończony powodzeniem.

Rys. 1. Role w scrumie i interesariusze

W ramach Scrum Framework cała praca dostarczana klientowi odbywa się za pośrednictwem dedykowanych zespołów scrumowych. Zespół scrumowy to zbiór osób pracujących razem w celu dostarczenia wymaganych i zatwierdzonych przyrostów produktu. Aby skutecznie działać, ważne jest, aby wszyscy w zespole mieli jeden cel, przestrzegali tych samych norm i zasad oraz okazywali sobie szacunek. Podczas zakładania nowego zespołu zawsze trzeba pamiętać, że na początku żaden nowy zespół nie osiągnie najwyższej możliwej wydajności. Na początku zespół musi przejść przez pewne etapy, zgodnie z opisem w Tuckman model: Forming, Storming, Norming, Performing. Czas potrzebny na to, by zespół scrumowy znajdował się w fazie wykonywania, zależy od zespołu. Żeby zespół osiągnął dojrzałość pozwalającą dostarczyć wyniki w przewidywalny sposób, potrzeba zazwyczaj trzech sprintów.

Scrum jest prosty. Jest przeciwieństwem dużego zbioru połączonych elementów obowiązkowych. Nie jest on metodologią. Wdraża naukową metodę empiryzmu. Zastępuje zaprogramowane podejście algorytmiczne podejściem heurystycznym, z szacunkiem dla ludzi i samoorganizacji, aby poradzić sobie z nieprzewidywalnością i rozwiązywaniem złożonych problemów. Poniższy rysunek przedstawia scrum w akcji opisany przez Kena Schwabera i Jeffa Sutherlanda w ich książce „Software in 30 Days”, która pokazuje proces od planowania do dostarczania oprogramowania.

Rys. 2. Scrum w akcji

Pokazane zdarzenia są wykorzystywane w scrumie po to, aby stworzyć regularność i zminimalizować potrzebę niezdefiniowanych spotkań. Wszystkie zdarzenia są podzielone na przedziały czasowe. Czas trwania rozpoczętego sprintu jest stały i nie można go skracać ani wydłużać. Pozostałe wydarzenia mogą zostać zakończone za każdym razem, gdy cel zostanie osiągnięty, zapewniając odpowiednią ilość czasu bez dopuszczania odpadów w procesie.

Sprint

Sprint to z góry ustalony przez Product Ownera przedział czasu (najlepiej nie krótszy niż 2 tygodnie i nie dłuższy niż 1 miesiąc), podczas którego zespół scrumowy ma do wykonania zakres zadań określony przed rozpoczęciem sprintu.

Podczas sprintu:

• nie wprowadza się żadnych zmian, które mogłyby zagrozić celowi sprintu
• cele jakościowe nie zmniejszają się
• zakres może zostać wyjaśniony i renegocjowany między właścicielem produktu a zespołem deweloperskim

Każdy sprint może być uważany za projekt z nie więcej niż jednomiesięcznym horyzontem. Podobnie jak projekty, sprinty są wykorzystywane do osiągnięcia czegoś. Każdy sprint ma cel, który ma zostać zbudowany, projekt i elastyczny plan, który poprowadzi go do budowy, pracy i wynikającego z tego przyrostu produktu.

Sprinty są ograniczone czasowo do jednego miesiąca. Gdy horyzont sprintu jest zbyt długi, definicja tego, co jest budowane, może się zmienić, a złożoność oraz ryzyko może wzrosnąć. Sprinty umożliwiają przewidywalność, zapewniając inspekcję i dostosowywanie postępów w kierunku celu sprintu co najmniej raz w miesiącu kalendarzowym. Sprinty również ograniczają ryzyko kosztów do jednego miesiąca kalendarzowego.

Przepisane zdarzenia są wykorzystywane w scrumie, aby stworzyć regularność i zminimalizować potrzebę niezdefiniowanych spotkań. Wszystkie zdarzenia są podzielone na przedziały czasowe. Po rozpoczęciu sprintu jego czas trwania jest stały i nie można go skracać ani wydłużać. Pozostałe wydarzenia mogą zostać zakończone za każdym razem, gdy cel wydarzenia zostanie osiągnięty, zapewniając odpowiednią ilość czasu bez dopuszczania odpadów w procesie.

Rys. 3. Backlog produktu

Elementy charakterystyczne scrumu

Backlog produktu

Backlog produktu jest uporządkowaną listą elementów potrzebnych w produkcie. Jest to jedyne źródło wymagań dla wszelkich zmian, które należy wprowadzić do produktu. Właściciel produktu jest odpowiedzialny za backlog, w tym jego zawartość, dostępność i zamawianie. Backlog produktu nigdy nie jest kompletny. Jego najwcześniejszy rozwój określa początkowo znane i najlepiej rozumiane wymagania. Ewoluuje on wraz z ewolucją produktu i środowiska, w którym będzie on używany. Backlog produktu jest dynamiczny – stale się zmienia po to, aby określić, który produkt musi być odpowiedni, konkurencyjny i użyteczny. Jeśli produkt istnieje, jego backlog również istnieje. Udoskonalenie to akt dodawania szczegółów, szacunków i kolejności do pozycji w backlogu produktu. Jest to ciągły proces, w którym właściciel produktu i zespół programistów współpracują nad szczegółami elementów backlogu. Podczas jego ulepszania elementy są sprawdzane i poprawiane. Wiele zespołów scrumowych często pracuje razem nad tym samym produktem. Jeden produkt backlog jest używany do opisania nadchodzących prac nad produktem. Następnie można wykorzystać atrybut backlog produktu, który grupuje elementy.

Backlog sprintu

Backlog sprintu to zestaw elementów backlogu produktu wybranych do sprintu, a także plan dostarczenia produktu i realizacji celu sprintu. Backlog sprintu jest prognozą zespołu deweloperskiego na temat tego, jaka będzie funkcjonalność w następnym przyroście i pracy niezbędnej do zapewnienia tej funkcjonalności w kroku „Zrobione”.

Rys. 4. Backlog sprintu

Backlog sprintu uwidacznia całą pracę, którą zespół ds. rozwoju określa jako niezbędną do osiągnięcia celu sprintu. Aby zapewnić ciągłe doskonalenie, obejmuje on co najmniej jedno usprawnienie procesu o wysokim priorytecie określone na poprzednim spotkaniu retrospektywnym. Backlog sprintu jest planem wystarczająco szczegółowym, aby zmiany w toku można było zrozumieć w daily scrum. Zespół deweloperski modyfikuje backlog sprintu podczas sprintu. Tylko zespół ds. rozwoju może zmienić swój backlog sprintu podczas sprintu. Jest on bardzo dobrze widocznym w czasie rzeczywistym obrazem pracy, którą zespół rozwoju planuje wykonać podczas sprintu i należy wyłącznie do zespołu ds. rozwoju.

Przegląd sprintu

Przegląd sprintu odbywa się na końcu sprintu w celu sprawdzenia przyrostu i dostosowania backlogu produktu w razie potrzeby. W trakcie sprintu mogło dojść do pojedynczego przeglądu lub wielu wdrożeń, które doprowadziły do sprawdzenia tego skoku. Podczas przeglądu sprintu zespół scrumowy i interesariusze współpracują nad tym, co zostało zrobione w sprincie. W oparciu o to i wszelkie zmiany backlogu produktu podczas sprintu uczestnicy współpracują nad kolejnymi elementami, które można zrobić, aby zoptymalizować wartość. Jest to nieformalne spotkanie, a nie spotkanie statusowe, a prezentacja przyrostu ma na celu wywołanie opinii i wspieranie współpracy. Jest to co najwyżej czterogodzinne spotkanie dla miesięcznych sprintów. W przypadku krótszych sprintów wydarzenie jest zwykle krótsze. Scrum Master zapewnia, że wydarzenie odbywa się i uczestnicy rozumieją jego cel. Uczy on wszystkich zaangażowanych, aby utrzymać go w odpowiednim czasie.

Retrospektywa sprintu

Retrospektywa sprintu jest okazją do tego, aby zespół scrumowy sam się sprawdził i opracował plan ulepszeń, które zostaną wprowadzone w czasie następnego sprintu.

Typowa retrospektywa następuje po przeglądzie sprintu i przed następnym planowaniem sprintu. Jest to co najwyżej trzygodzinne spotkanie dla miesięcznych sprintów. W przypadku krótszych sprintów wydarzenie jest zwykle krótsze. Scrum Master zapewnia, że ​​wydarzenie odbywa się i że uczestnicy rozumieją jego cel. Jest to okazja, aby zespół scrumowy poprawił efektywność i aby wszyscy członkowie byli obecni.

Podczas retrospektywy sprintu zespół omawia:

• co poszło dobrze w sprincie
• co można poprawić i w jaki sposób to zrobić
• co zobowiązujemy się ulepszyć w następnym sprincie

Scrum Master zachęca zespół scrumowy do usprawnienia procesu rozwoju i praktyk, aby był bardziej skuteczny w następnym sprincie. Podczas każdej retrospektywy sprintu zespół scrumowy planuje sposoby na podniesienie jakości produktu poprzez ulepszenie procesów roboczych lub dostosowanie definicji „Zrobione”, jeśli jest to właściwe i nie koliduje ze standardami produktu lub organizacji.

Pod koniec retrospektywy sprintu zespół scrumowy powinien zidentyfikować ulepszenia, które wprowadzi w następnym sprincie. Wdrożenie tych ulepszeń w następnym sprincie jest adaptacją do inspekcji samego zespołu scrumowego. Chociaż ulepszenia można wprowadzić w dowolnym momencie, retrospektywa sprintu stanowi formalną możliwość skupienia się na inspekcji i adaptacji.

Autor: Robert Wołos – scrum developer ODI w Onwelo. Interesują go nowości technologiczne i aplikacje na Androida, które tworzy w wolnym czasie. Jeśli masz ciekawy problem z obszaru hurtowni danych lub ETL (Data Stage, ODI), Robert chętnie pomoże.