Historia Scruma
Od czasu opublikowania raportu Winstona Royce'a „Managing the Development of Large Software Systems” w 1970 roku wielu próbowało znaleźć metodologię, która mogłaby wyeliminować wady modelu rozwoju Waterfall. Alternatywą dla „wodospadu” była metoda Scrum, która zostanie teraz omówiona.
Scrum otrzymał swoją nazwę w 1986 roku od pracy Takeuchiego i Nonakiego The New Rules for New Product Development. Dokument ten dowodzi, że najskuteczniejszym sposobem osiągnięcia celu jest przekazanie programistom jasnego planu działania.
W 1995 roku ukazał się kolejny przewodnik „Software Development with Scrum” autorstwa Sutherlanda i Schweibera. Od tego czasu publikacja ta była kilkakrotnie aktualizowana. Obecnie jest uważany za główny przewodnik rozwoju tej metody. Aktualna wersja Scrum Guide zawiera informacje zaktualizowane w 2020 roku.
Główne zapisy Scrum Guide sugerują, że szablon zarządzania projektami powinien opierać się na fakcie, że programiści dostarczają gotowy produkt w uzgodnionych ramach czasowych – sprintach. Do pomyślnego wdrożenia Scruma zaleca się stosowanie struktury składającej się z kilku elementów: ról, zdarzeń, reguł i artefaktów.
Role w Scrumie
W Scrumie są trzy role, z których wszystkie tworzą zespół Scrumowy:
Klient oprogramowania jest najważniejszą osobą w projekcie, ponieważ tylko on w pełni rozumie jego wartość dla biznesu. Klient wyjaśnia programistom potrzeby użytkowników przyszłego produktu, ale nie ponosi odpowiedzialności za techniczną część procesu rozwoju. Klient określa również priorytet przy tworzeniu określonych elementów lub funkcji w produkcie.
Deweloperom powierzana jest realizacja zadań technicznych, których cross-funkcjonalność zależy od zakresu aplikacji. Deweloperzy są zajęci tworzeniem rejestru sprintu, pisaniem kodu, dostosowywaniem projektu do celu sprintu i innymi zadaniami.
Scrum Master jest facylitatorem zespołu Scrumowego. Zapewnia pomoc dla klienta i programistów. Mówiąc najprościej, Scrum Master jest zajęty komunikacją między tymi, którzy nie są zaangażowani w projekt, a ludźmi piszącymi kod. Czasami różne zespoły programistów w tej samej dużej firmie komunikują się i koordynują na walnych zgromadzeniach scrum masterów tych zespołów.
Zdarzenia w Scrumie
Istnieje 5 rodzajów zdarzeń scrumowych:
Sprint jest najważniejszą częścią Scruma. Obejmuje planowanie sprintu, codzienne stand-upy (codzienny scrum), przegląd i retrospektywę sprintu.
Planowanie sprintu. Wszyscy członkowie zespołu Scrumowego biorą udział w opracowaniu planu przyszłego sprintu. To tutaj prezentowany jest pomysł na produkt i każdy członek zespołu może wyrazić swoją opinię, co o nim myśli. Następnie na spotkaniu ustalane są priorytety i ogłaszane terminy.
Daily Scrum to codzienne krótkie wydarzenie scrumowe, trwające nie dłużej niż 15 minut. Zwykle robi się to w celu zaplanowania pracy enkoderów na dziś lub jutro. Na Daily Scrum możesz omówić bieżące sprawy. Wszyscy programiści zaangażowani w projekt są zobowiązani do wzięcia udziału w takim warsztacie. Obecność Scrum Mastera jest dozwolona, ale nie wymagana.
Przegląd Sprintu (Demo) — Pokaż wyniki utworzone podczas sprintu. Zwykle to wydarzenie odbywa się na końcowym etapie. Biorą w nim udział wszyscy zainteresowani.
Retrospektywa Sprintu – omówienie wyników sprintu. Członkowie zespołu dzielą się swoją opinią na temat tego, jak poradzili sobie z powierzonymi im zadaniami i jak poprawić wyniki pracy w przyszłości.
Dodatkowo czasami przeprowadzane jest udoskonalanie backlogu – Backlog Refinement. Omawia elementy zaległości, przygotowania do następnego sprintu i ustalanie priorytetów bieżących zadań.
Artefakty
Artefakty Scruma to prace wykonywane na końcu projektu lub sprintu. Istnieją trzy artefakty — rejestr produktu, rejestr sprintu i przyrost. Każdy z nich jest potrzebny do terminowego dostarczania oprogramowania użytkownikom. Są też artefakty pomocnicze (wykresy spalania i nie tylko).
Komponenty zawarte w artefaktach sprintu:
Product Backlog - interfejs i funkcje backendu.
Backlog sprintu to lista zadań, które należy wykonać podczas iteracji. Uzgadniane są przed rozpoczęciem sprintu.
Przyrost — łączna liczba elementów rejestru oprogramowania utworzonych podczas sprintu oraz wartość przyrostów, które zostały wykonane przed nim. Ukończony nowy przyrost musi być pokazany przed końcem sprintu. Oznacza to, że masz działającą wersję, która spełnia wymagania zespołu scrumowego.
Pozycja rejestru produktu - musi zostać ukończona podczas iteracji sprintu. Z reguły element jest podzielony na kilka małych zadań.
Cel sprintu to zadania, które należy wykonać (utworzyć element zaległości lub inne zadanie).
Wypalenie sprintu to praca pozostawiona przed końcem sprintu. Wykres spalania jest rosnący lub malejący. Wszystko zależy od trudności, z jakimi spotykają się członkowie zespołu podczas pracy. Nie jest wyznacznikiem postępu, a jedynie sposobem na rozwiązanie problemów i zachętą.
Product release / product burn-down chart – wykres, który Scrum Master rysuje przed zakończeniem kolejnego sprintu. Oś pozioma to sprinty, oś pionowa to ilość pozostałej pracy.
Zasady ramowe Scruma
Role, wydarzenia i artefakty są podstawą Scruma, ale oprócz tego istnieją inne zasady. Wszystkie podnoszą efektywność procesu pracy. Oto lista tych zasad:
- Zespół scrumowy obejmuje klienta oprogramowania, mistrza scrumowego i programistów.
- Wszystkie sprinty powinny mieć taką samą długość.
- Po ukończeniu jednego sprintu od razu rozpoczyna się praca nad kolejnym.
- Sprint zawsze zaczyna się od planu.
- Członkowie zespołu mają poranny scrum na początku dnia pracy.
- Każdy sprint jest przeglądany podczas każdego sprintu. Poprawia to komunikację między zespołem a interesariuszami.
- Nie zaleca się zmiany rejestru sprintu w trakcie sprintu.
Ograniczenia w Scrumie
Oprócz oczywistych zalet Scrum ma również wady:
- Scrum często prowadzi do zmniejszenia ilości wykonywanej pracy ze względu na brak wspólnego terminu.
- Przy niskim zaangażowaniu lub niechęci do współpracy wśród uczestników projektu są spore szanse na niepowodzenie wyniku.
- Struktura Scrum jest trudna do zastosowania w dużych zespołach, ale nadal jest możliwa. Są do tego skalowalne frameworki: LeSS, SAFe, Nexus i inne.
- Odejście jednego lub więcej członków zespołu w połowie projektu nie wpływa zbyt dobrze na projekt.