Scrum to zwinna (Agile) metodyka i/lub przyrostowy sposób postępowania do zarządzania projektami, stosowany głównie w projektach programistycznych, których celem jest dostarczanie nowych funkcji oprogramowania co 2 – 4 tygodnie. Jest to jedno z podejść, które wpłynęło na „Agile Manifesto” wyrażający zbiór wartości i zasad, które pomagają w podejmowaniu decyzji dotyczących szybszego tworzenia oprogramowania wysokiej jakości.
Scrum jest szeroko stosowany przez zespoły programistyczne. W rzeczywistości jest to najpopularniejsza metodyka zwinna. Zgodnie z 11. rocznym raportem „State of Agile”, 68% zespołów programistycznych używa Scruma lub hybrydy Scrum. Jednak Scrum rozprzestrzenił się również na inne funkcje biznesowe, w tym IT i marketing, gdzie są projekty, które muszą być prowadzone w obliczu złożoności i niejednoznaczności. Zespoły kierownicze opierają swoje zwinne praktyki zarządzania na Scrumie, często łącząc je z praktykami lean i Kanban (podgrupy sprawnego zarządzania projektami).
Scrum jest podgrupą zwinną:
• Agile to zbiór wartości i zasad opisujących codzienne interakcje i działania grupy. Sam Agile nie jest nakazowy ani specyficzny.
• Metodyka Scrum jest zgodna z wartościami i zasadami zwinności (Agile), ale zawiera dalsze definicje i specyfikacje, szczególnie w odniesieniu do niektórych praktyk programistycznych.
Opracowany z myślą o zwinnym (Agile) tworzeniu oprogramowania, Scrum stał się często wybieraną platformą do zarządzania projektami i jest czasem nazywany po prostu zarządzaniem projektem Scrum lub rozwojem Scrum.
• Wyższa produktywność
• Produkty lepszej jakości
• Skrócony czas wprowadzania na rynek
• Lepsza satysfakcja interesariuszy
• Lepsza dynamika zespołu
• Zadowoleni pracownicy
Scrum zajmuje się złożonością pracy, zapewniając przejrzystość informacji (Przejrzystość/ Transparency), tak aby zespoły mogły kontrolować (Inspekcja/ Inspect) proces i dostosowywać się (Adaptacja/ Adapt) w oparciu o aktualne, a nie przewidywane warunki. Pozwala to rozwiązać typowe pułapki procesu tworzenia kaskady: chaos wynikający z ciągle zmieniających się wymagań; niedoszacowanie czasu, zasobów i kosztów; kompromisy dotyczące jakości oprogramowania; i niedokładne zgłaszanie postępów. W rozwoju Scrum wymagana jest przejrzystość wspólnych warunków i standardów, aby zapewnić, że to, co jest dostarczane, jest zgodne z oczekiwaniami. Częsta kontrola zapewnia postęp prac i wczesne wykrywanie problemów, dzięki czemu można szybko wprowadzić korekty.
Zespoły Scrum składają się zazwyczaj z 7 +/- 2 członków i nie mają lidera zespołu do delegowania zadań lub decydowania o rozwiązaniu problemu. Zespół jako jednostka decyduje, jak rozwiązywać problemy. Każdy członek zespołu Scrum jest integralną częścią rozwiązania i oczekuje się, że będzie współodpowiedzialny za produkt od jego powstania do ukończenia.
W metodyce Scrum istnieją trzy kluczowe role:
Właściciel produktu / The Product Owner
Właściciel produktu jest kluczowym udziałowcem projektu – zazwyczaj jest to klient lub rzecznik klienta. Jest tylko jeden właściciel produktu, który przekazuje ogólną misję i wizję produktu. Właściciel produktu jest ostatecznie odpowiedzialny za zarządzanie zaległościami produktu i akceptowanie ukończonych przyrostów pracy.
Scrum Master
Scrum Master odpowiada za poprawną implementację procesu i metod Scrum. Scrum Master jest również odpowiedzialny za zespół robiąc wszystko co możliwe, aby pomóc zespołowi wykonać pracę na najwyższym poziomie. Może to obejmować usuwanie przeszkód, ułatwianie spotkań itd.
Zespół programistyczny / The Development Team
Zespół ds. rozwoju to samoorganizująca się, wielofunkcyjna grupa, wyposażona we wszystkie umiejętności umożliwiające dostarczanie ładowalnych przyrostów po zakończeniu każdego sprintu. Scrum rozszerza definicję terminu „programista” poza programistów, aby uwzględnić każdego, kto uczestniczy w tworzeniu dostarczonego przyrostu. W zespole deweloperskim nie ma żadnych funkcji nadrzędnych.
Planowanie sprintu / Sprint Planning
Planowanie sprintu to spotkania zespołu (zdarzenia czasowe – time-boxed), które określają, które pozycje z Rejestru Produktu (Product Backlog) zostaną dostarczone i jak zostaną wykonane prace.
Sprint
Sprint to czas, w którym praca jest wykonywana, zakończona i przygotowywana do przeglądu. Sprinty trwają zwykle 2-4 tygodnie, ale mogą wynosić nawet też tydzień.
Codzienny Scrum / Daily Scrum
Codzienny Scrum to krótkie spotkanie komunikacyjne (nie więcej niż 15 minut), w którym każdy członek zespołu szybko i przejrzyście opisuje postępy od ostatniego Daily Scrum, zaplanowanej pracy przed następnym spotkaniem (Daily Scrum) oraz wszelkie przeszkody, które mogą blokować jego postęp.
Przegląd sprintu / The Sprint Review
Przegląd Sprintu to spotkanie po każdym Sprincie, które ma na celu omówienie funkcjonalności oraz cech produktu, a także przebiegu prac tylko i wyłącznie dla fragmentu stworzonego produktu. Właściciel produktu sprawdza pracę zgodnie wcześniej zdefiniowanymi kryteriami akceptacji i akceptuje lub odrzuca jej efekt. Zainteresowane strony lub klienci wyrażają opinię, aby upewnić się, że dostarczony przyrost spełnił wymagania biznesowe.
Retrospektywa / The Retrospective
Retrospektywa jest ostatnim spotkaniem zespołu po każdym Sprintcie. Omawia się wtedy co poszło dobrze i jakie problemy napotkał zespół oraz jak zespół może się poprawić w następnym Sprincie. Retrospektywa jest ważną okazją dla zespołu, aby skupić się na ogólnej wydajności i zidentyfikować strategie ciągłego doskonalenia swoich procesów.
Rejestr produktu / Product Backlog
Rejestr produktu jest najważniejszym dokumentem, który określa wszystkie wymagania dotyczące systemu, projektu lub produktu. Produkt Backlog może być traktowany jako lista zadań składająca się z elementów pracy, z których każdy tworzy produkt o wartości biznesowej. Pozycje są uporządkowane w kolejności od najważniejszej do najmniej ważnej.
Rejestr Sprintu / Sprint Backlog
Rejestr Sprintu to specyficzna lista zadań/obiektów/funkcji pobranych z Rejestru Produktu, które mają zostać wykonane podczas Sprintu.
Przyrost / Increment
Przyrost jest sumą wszystkich pozycji z Rejestru Produktu, które zostały ukończone od czasu ostatniego wydania, np. oprogramowania. Zespół dostarcza kolejne wersje (inkrementy) działającego produktu w krótkich cyklach zwanych Sprintami.