Co to jest Scrum?

Scrum to framework służący do rozwijania, dostarczania i utrzymywania złożonych produktów poprzez efektywną współpracę zespołową. Zapewnia lekki proces, który koncentruje i koordynuje współpracę zespołową, gdy zespół Scrum rozwiązuje skomplikowane problemy adaptacyjne i dostarcza produkt o optymalnej wartości w sposób przyrostowy i zgodnie z przewidywalnym harmonogramem.

Pierwotnie opracowany przez profesorów Hirotaka Takeuchi i Ikujiro Nonaka i opublikowany jako "The New Product Development Game" w Harvard Business Review w 1986 roku, Scrum został zaadaptowany i spopularyzowany przez Jeffa Sutherlanda i Kena Schwabera w latach 90. Stał się coraz bardziej popularnym sposobem pracy, wykraczając poza rozwój oprogramowania do wielu obszarów rozwoju produktów, które mogą zastosować i skorzystać z podejścia iteracyjnego i przyrostowego. Jego sukces lub porażka zależą od kompetencji technicznych i wspólnych wysiłków zespołu.

Z perspektywy procesowej Scrum oferuje proste i niezwykle skuteczne zwinne podejście do dostarczania produktów. Jak zostanie pokazane później, Scrum nie jest i nie ma na celu opisywania zwinnego podejścia do zarządzania projektami.  

Framework obejmuje trzy odrębne role, które tworzą Zespół Scrum, każda z jasno określonymi obowiązkami, pięć wydarzeń i trzy artefakty. Zasady przedstawione w The Scrum Guide łączą ze sobą role, wydarzenia i artefakty, kierując ich relacjami i interakcjami.

• 5 Wydarzeń: Sprint, Planowanie Sprintu, Codzienny Scrum, Przegląd Sprintu, Retrospektywa Sprintu
• 3 Artefakty: Product Backlog, Sprint Backlog, Przyrost Produktu
• 3 Role: Product Owner, Deweloper, Scrum Master.

1. Sprint to przedział czasowy, który może mieć dowolny czas trwania, ale zazwyczaj wynosi od 2 do 4 tygodni, podczas którego tworzone są jeden lub więcej „Gotowych" (tj. użytecznych i przynajmniej potencjalnie możliwych do wydania) Przyrostów Produktu. Sprint zawiera wszystkie inne wydarzenia.
2. Planowanie Sprintu to moment, w którym Deweloperzy planują pracę do wykonania w następnym Sprincie. Negocjują realistyczny Cel Sprintu z Właścicielem Produktu, wybierają odpowiednie elementy z Backlogu Produktu, aby przyczynić się do tego celu i planują pracę w celu jego osiągnięcia.
3. Dzienny Scrum to 15-minutowe spotkanie prowadzone przez Deweloperów w Zespole Scrum. Odbywa się codziennie podczas Sprintu, a Deweloperzy wykorzystują je do potwierdzenia swojego zaangażowania w osiągnięcie Celu Sprintu i odpowiedniego dostosowania swoich planów.
4. Przegląd Sprintu odbywa się na końcu Sprintu. Jego celem jest uczynienie widocznym dla interesariuszy tego, co zostało dostarczone w Sprincie, aby umożliwić im formalne sprawdzenie i zasugerowanie adaptacji Backlogu Produktu w celu kierowania dalszym rozwojem.
5. Retrospektywa Sprintu to możliwość dla Zespołu Scrum do refleksji nad skutecznością ich sposobu pracy i stworzenia planu ulepszeń do wdrożenia podczas następnego lub kolejnych Sprintów.

Trzy artefakty Scrum zostały zaprojektowane tak, aby utrzymać koncentrację na wartości, która ma zostać dostarczona. Są przejrzyste – czyli celowo widoczne – dla każdego, kto jest zainteresowany tym, co robi Zespół Scrum i jak podchodzi do swojej pracy. Każdy artefakt zawiera zobowiązanie.

Product Backlog to uporządkowana lista wszystkiego, co należy zrobić, aby osiągnąć Cel Produktu. Jest to jedyne źródło pracy dla Zespołu Scrum. Chociaż może istnieć więcej niż jeden Cel Produktu, na przykład opisujący mapę drogową produktu, w danym czasie pracuje się tylko nad jednym celem. Cel Produktu to założenie, zobowiązanie, które Product Backlog ma za zadanie osiągnąć.

Sprint Backlog obejmuje zbiór elementów Product Backlog wybranych na Sprint oraz całą pracę potrzebną do osiągnięcia Celu Sprintu. Podczas gdy w trakcie Sprintu może zostać dostarczony jeden lub więcej Przyrostów Produktu, istnieje tylko jeden Cel Sprintu. Cel Sprintu to zobowiązanie dla Sprint Backlog i jest tym, do czego dążą Deweloperzy.

Przyrost Produktu to to, co tworzą deweloperzy, aby sprostać potrzebie opisanej przez jeden lub więcej elementów product backlog. Jest to namacalny krok w kierunku osiągnięcia Celu Sprintu. Gdy w Sprincie dostarczany jest więcej niż jeden, każdy Przyrost Produktu zawiera poprzedni. Zobowiązaniem jest osiągnięcie „Definicji Ukończenia" dla Przyrostu Produktu. Ta „Definicja Ukończenia" to formalny opis niezbędnych standardów jakości, które produkt musi spełnić.

Wiemy z manifestu Agile że praktycy zwinności cenią ludzi i interakcje ponad procesy i narzędzia – co oznacza, że choć istnieje miejsce dla procesów i narzędzi – i bądźmy bardzo jasni, Scrum zawiera znaczący element procesu – bardziej cenimy ludzi i sposób, w jaki współpracują. Role i odpowiedzialności związane z tymi rolami, a także współpraca między osobami pełniącymi te role, są fundamentalne dla skutecznego stosowania Scrum.

Zespół Scrum składa się z jednego Product Ownera, jednego Scrum Mastera i, zazwyczaj, między 5 a 9 Programistami. Zespół musi być międzyfunkcyjny – wspólnie posiadając wszystkie kompetencje potrzebne do dostarczenia pożądanego produktu oraz umiejętność współpracy w celu osiągnięcia tego celu. Zespół jest samoorganizujący się – nie uznaje struktur hierarchicznych i pozwala przywództwu dla określonej pracy wyłonić się w odpowiednim momencie.

Product Owner

Product Owner jest odpowiedzialny za maksymalizację wartości produktu wynikającej z pracy Zespołu Scrum. Product Owner to pojedyncza osoba, a nie komitet, i zazwyczaj reprezentuje potrzeby wielu interesariuszy, w tym klientów, dla których tworzona jest wartość. Przyczyniając się do pracy Zespołu Scrum, są odpowiedzialni za skuteczne zarządzanie Product Backlogiem, co obejmuje:

• Opracowywanie i jawne komunikowanie Celu Produktu.
• Tworzenie i jasne komunikowanie elementów Product Backlogu.
• Ustalanie priorytetów elementów Product Backlogu.
• Zapewnienie, że Product Backlog jest przejrzysty, widoczny i zrozumiały.

Każdy interesariusz chcący zmienić Product Backlog może to zrobić tylko przez Product Ownera.

Programista

Rola Programisty w Zespole Scrum dotyczy każdego, kto aktywnie współpracuje z innymi w zespole przy tworzeniu Produktu – nawet ktoś, kto pełni także jedną z pozostałych ról, może być Programistą. Umiejętności potrzebne Programiście będą się różnić w zależności od rodzaju wykonywanej pracy i tego, co jest produkowane. Programiści pracujący w Zespole Scrum nad zagospodarowaniem ogrodu będą potrzebować zupełnie innego zestawu umiejętności niż ci przygotowujący wyszukane przyjęcie lub ci budujący nową grę na smartfon. Scrum można zastosować we wszystkich tych środowiskach deweloperskich.

W Scrum Programiści są zawsze odpowiedzialni za:

• Tworzenie planu dla Sprintu, Sprint Backlogu;
• Zapewnienie jakości poprzez przestrzeganie Definicji Ukończenia;
• Dostosowywanie swojego planu każdego dnia w kierunku Celu Sprintu; oraz,
• Wzajemne rozliczanie się jako profesjonaliści.

Scrum Master

Scrum Master jest odpowiedzialny za ustanowienie Scrum zgodnie z definicją w Przewodniku Scrum. Robi to pomagając każdemu zrozumieć teorię i praktykę Scrum, zarówno w Zespole Scrum, jak i w organizacji.

Często określany jako przywódca-służący, Scrum Master nie posiada władzy rozkazywania – nie mówi ludziom co robić i jak się zachowywać, pomaga im zrozumieć, jak Scrum powinien działać i robi wszystko, co może, aby ułatwić jego adopcję. Świadczą usługi dla:

• Zespołu Scrum – coachingu ich adopcji Scrum, pomagając im znaleźć sposoby ciągłego doskonalenia sposobu dostarczania wartości i powodowania usunięcia wszystkiego, co stoi temu na przeszkodzie.
• Product Ownera – pomagając im w zarządzaniu Product Backlogiem i pomagając im zapewnić, że Cele Produktu i elementy Product Backlogu są odpowiednio ukształtowane, wyrażone i zrozumiane.
• Szerszej organizacji, w której istnieje Zespół Scrum – pomagając im zrozumieć sposób pracy Scrum i jak muszą pracować i zachowywać się, aby umożliwić Zespołom Scrum optymalną skuteczność.

Framework Scrum opiera się na teorii empirycznej kontroli procesów, czyli empiryzmie, który głosi, że wiedza pochodzi z doświadczenia, a podejmowanie decyzji opiera się na tym, co można zaobserwować. Filary empirycznej kontroli procesów to przejrzystość procesu i postępu, inspekcja procesu i postępu oraz adaptacja zarówno powstającego produktu (ulepszanie go z każdą iteracją i przyrostem), jak i sposobów pracy (ciągłe doskonalenie skuteczności i wydajności zespołu).

Ważne jest zrozumienie, jak uczynić proces empiryczny skutecznym. Przejrzystość umożliwia Inspekcję, Inspekcja umożliwia Adaptację, a Adaptacje muszą być Przejrzyste. Inspekcja bez Przejrzystości jest myląca i marnotrawna, Inspekcja bez zamiaru Adaptacji jest bezcelowa, a Adaptacja bez Przejrzystości w celu zbadania jej wpływu czyni Adaptację ryzykowną.

Skuteczne zespoły Scrum żyją i oddychają zestawem pięciu wartości. Te wartości nie są unikalne dla zespołu Scrum, ale poprzez ich wyraźne określenie zachęcają do skutecznej, opartej na współpracy pracy zespołowej. Wartościami tymi są Zaangażowanie, Skupienie, Otwartość, Szacunek i Odwaga.

• Zaangażowanie: Członkowie zespołu Scrum są zobowiązani do osiągania celów sprintu i dostarczania wysokiej jakości pracy poprzez rozwój iteracyjny i przyrostową dostawę. To sprzyja odpowiedzialności i rozliczalności wśród członków zespołu.
• Odwaga: Członkowie zespołu Scrum mają odwagę otwarcie podejmować wyzwania i przeszkody. Są gotowi podejmować ryzyko i mówić o problemach, które mogą wpłynąć na sukces zespołu.
• Otwartość: Członkowie zespołu Scrum dzielą się między sobą informacjami, postępami i obawami, tym samym budując zaufanie i współpracę w zespole.
• Skupienie: Członkowie zespołu Scrum utrzymują zbiorowe skupienie na Celach Produktu i Sprintu, ustalając priorytety swojej pracy w celu optymalizacji dostarczania wartości.
• Szacunek: Członkowie zespołu Scrum szanują się nawzajem jako profesjonaliści, uznając swoje umiejętności, perspektywy i wkład podczas dostarczania produktu. To tworzy pozytywne środowisko pracy i wzmacnia współpracę między członkami zespołu.

Te wartości mogą i powinny być stosowane, aby pomóc uczynić skutecznym każdy zwinny sposób pracy.

Wartości Scrum wspólnie przyczyniają się do zdolności zespołu Scrum do:

• Adaptacji do zmian: Scrum jest bardzo responsywny na zmieniające się wymagania. Umożliwia dostosowanie się do ewoluujących potrzeb klientów poprzez wprowadzanie zmian na końcu każdego sprintu, promując elastyczność i większą satysfakcję klientów.
• Współpracy w podejmowaniu decyzji: Samoorganizująca się natura zespołu Scrum i empiryczne podstawy metody pracy Scrum zachęcają do współpracy. Życie wartościami Scrum ożywia pracę zespołową.  
• Ciągłego doskonalenia: Scrum obejmuje regularne retrospektywy – których celem jest zapewnienie regularnych możliwości dla zespołu Scrum do zbadania skuteczności sposobu, w jaki pracują, oraz zidentyfikowania obszarów do poprawy. To jest ciągłe doskonalenie w działaniu.
• Przyjęcia podejścia skoncentrowanego na kliencie: Scrum kładzie duży nacisk na dostarczanie wartości klientowi. Product Owner, reprezentujący interesy klientów, ustala priorytety funkcjonalności, zapewniając, że produkt jest zgodny z potrzebami i oczekiwaniami klientów w trakcie całego procesu rozwoju.

Scrum oferuje liczne korzyści dla rozwoju produktów, zwiększając efektywność, współpracę i zdolność adaptacji:

• Elastyczność
• Szybszy czas wprowadzenia na rynek
• Wzmocniona współpraca
• Poprawiona jakość produktu
• Zwiększona satysfakcja klienta
• Wyższa produktywność
• Lepsze zarządzanie ryzykiem
• Przejrzystość
• Wzmocnione zespoły
• Ciągłe doskonalenie.

Poznaj więcej o 10 kluczowych zaletach używania Scrum, szczegółowo omówionych w tym blogu.

Scrum może przedstawiać kilka wyzwań i wad. Przy wdrażaniu Scrum, jak w przypadku wszystkich nowych sposobów pracy, może wystąpić opór wobec zmian. Zespoły mogą mieć trudności z poziomem współpracy i komunikacji potrzebnym do skutecznego działania Scrum. Role takie jak Scrum Master mają również określone obowiązki, które różnią się od tradycyjnych ról, a niezrozumienie tych ról może prowadzić do zamieszania i nieefektywności. Po wdrożeniu Scrum nadal należy stawić czoła wyzwaniom, typowe ryzyka lub wady obejmują:-

1. Niewystarczające wsparcie kierownictwa: Jak w przypadku każdej inicjatywy zmiany bez silnego wsparcia ze strony kierownictwa w organizacji, przyjęcie Scrum napotka na opór lub będzie borykać się z wyzwaniami w pokonywaniu barier organizacyjnych. Brak zrozumienia potrzebnej zmiany kulturowej i słabe zaangażowanie na wyższych szczeblach może poważnie ograniczyć wartość, jaką Scrum może dostarczyć jako sposób pracy.
2. Krzywa uczenia się: Początkowe zakłócenia i dostosowania mogą wpłynąć na produktywność, gdy członkowie zespołu przystosowują się do nowych ról, wydarzeń i procesów współpracy wprowadzonych przez Scrum. Powiedzenie, że sprawy mogą się pogorszyć zanim się poprawią, jest często prawdziwe. Kluczem jest danie czasu na naukę i zidentyfikowanie osób z doświadczeniem w skutecznym wdrażaniu tego w innych miejscach, które mogą pomóc.
3. Przesadne zobowiązania:  Zespoły mogą napotkać ryzyko przesadnego zobowiązywania się do pracy podczas planowania sprintu, co prowadzi do wypalenia lub pogorszenia jakości rezultatów. Równoważenie pragnienia szybkiego postępu z realistycznym wyznaczaniem celów jest kluczowe dla utrzymania zrównoważonych praktyk rozwojowych. Ważne jest ustalenie zrównoważonego tempa – należy spodziewać się niepowodzeń w osiąganiu Celów Sprintu, podczas gdy zespół ustala, co można osiągnąć.
4. Przesadne skupienie na celach krótkoterminowych: Skupienie na krótkich, o stałej długości sprintach w Scrum może czasami prowadzić do krótkiego spojrzenia, gdzie zespoły priorytetowo traktują natychmiastowe cele nad długoterminowymi celami strategicznymi. W czystym środowisku produktowym dobry Product Owner powinien być w stanie komunikować i utrzymywać odpowiednie długoterminowe skupienie. Gdy napotka się wyzwanie złożoności, może być potrzebne coś więcej…
5. Problemy z integracją pracy wielu zespołów w przypadku większych, bardziej złożonych przedsięwzięć: Scrum jest silny gdy stosowany do pojedynczych zespołów, ale bardzo słaby gdy praca do wykonania przekracza możliwości „10 lub mniej" osób w zespole. W tej sytuacji zalecany jest szerszy framework do radzenia sobie ze skalą i/lub złożonością.

Dla ekstremalnej skali w kontekście produktowym – gdzie potrzebnych jest setki programistów – może być wskazany skalowany framework taki jak SAFe. Dla problemów mniejszej skali – na przykład do 100 programistów – i/lub gdy złożoność całościowego rozwiązania biznesowego obejmuje wiele produktów, usług i innych działań, wtedy framework projektu zwinnego taki jak AgilePM zaspokoi tę potrzebę.  

Opierając się na kwestii skalowania wspomnianej powyżej, w tym odcinku serii „Level Up" od APMG eksperci zarządzania projektami agile odpowiadają na pytania dotyczące zwinnego zarządzania projektami i scrum. Jednym z kluczowych poruszanych zagadnień jest różnica między tymi podejściami.  Omawiane są kwestie takie jak planowanie sprintów, idealna długość Sprintu oraz wartość codziennych stand-upów.

Agile Business Consortium rozwinęło swoje wiodące na świecie podejście do zarządzania projektami Agile (AgilePM), aby zapewnić wersję zaprojektowaną specjalnie do pracy z Scrum. AgilePM for Scrum oferuje pojedynczy framework do dostarczania kompletnych rozwiązań biznesowych. Zajmuje się wprost rozwiązaniami obejmującymi wiele produktów lub usług, wymagającymi połączonych wysiłków rozwojowych wielu zespołów Scrum lub kombinacji zespołów Scrum i nie-Scrum. Z technikami do radzenia sobie z agile planowaniem i koordynacją między zespołami, przywództwem z perspektyw wizji biznesowej, architektury rozwiązania i zarządzania projektami, nadzorem, ryzykiem i innymi aspektami, warto rozważyć to rozwiązanie w bardziej złożonych sytuacjach projektowych.

W tym filmie Richard Pharro, CEO APMG International, i ja dyskutujemy o 'AgilePM for Scrum.' Ten nowy framework łączy mocne strony dwóch wiodących frameworków Agile. Richard zadaje kluczowe pytania, dążąc do dostarczenia wglądu w framework, w tym jego zakres, uzasadnienie jego rozwoju oraz tego, kto może najwięcej skorzystać z tego frameworku. Dodatkowo eksplorujemy akredytowane szkolenia i certyfikację program wspierający ten framework.

Scrum wytyczył znaczącą ścieżkę dla zwinności w rozwoju produktów programistycznych i jest bardzo popularnym i wszechstronnym podejściem nie bez powodu, będąc idealnie dopasowanym do dostarczania produktów, które zachwycają klientów w obliczu złożonych i ewoluujących wymagań. Wykorzystuje zalety wielofunkcyjnych, współpracujących zespołów, aby dostarczać wartość szybciej i wydajniej niż ich mniej zwinni odpowiednicy.

Nie jest to jednak bez wyzwań... Ken Schwaber i Jeff Sutherland stwierdzają w swoim przewodniku Scrum Guide 2020, że "Framework Scrum, jak przedstawiono w niniejszym dokumencie, jest niezmienny. Choć możliwe jest wdrożenie tylko części Scrum, wynikiem nie jest Scrum. Scrum istnieje tylko w całości..."

Scrum to prosty, elegancki, skuteczny zwinny framework do dostarczania produktów. Zostało to udowodnione wielokrotnie na całym świecie w wielu różnych zastosowaniach w różnych branżach, ale tylko wtedy, gdy jest używany w całości. Jeśli pominiesz jakikolwiek element Scrum, po prostu nie będzie działać prawidłowo. Scrum działa, ScrumBut niesie ryzyko niepowodzenia. ScrumBut opisuje sytuację, gdy "używamy Scrum, ale nie robimy tego".  W miejsce "nie robimy tego" wstaw cokolwiek chcesz... "Nie robimy codziennego Scrum", "nie współpracujemy", "nie mamy Scrum Mastera, mamy kierownika", "nie mamy backlogu produktu, mamy specyfikację", "nie definiujemy celu sprintu" itd. Schwaber i Sutherland opracowali Scrum, nadzorowali jego stopniową i staranną ewolucję od połowy lat 90. – zaakceptuj ich mądrość i rób to prawidłowo.  

Jeśli twoim obszarem jest rozwój produktów, to łatwo dostrzec, jak wprowadzenie zwinności do tej gry poprzez stosowanie i ciągłe doskonalenie stosowania Scrum mogłoby przynieść ogromne korzyści. Ale jeśli twoje zainteresowania sięgają szerzej niż czysty rozwój produktów, to jako samodzielne rozwiązanie, Scrum może okazać się niewystarczający.

Szkolenia, edukacja oraz ciągłe zachęcanie i wsparcie zespołów Scrum są potrzebne, aby wykorzystać sukces Scrum. APMG oferuje następujące certyfikaty dla kluczowych ról.

Ten kurs nauczy Cię doskonałości jako Scrum Master, usprawniając rozwój produktów i rozwiązań przy użyciu Scrum. Kluczowe zagadnienia obejmują kompleksowe zrozumienie frameworka Scrum, zasad Scrum oraz roli Scrum Mastera. Nauczysz się również budować efektywne zespoły deweloperskie, działać jako przywódca-sługa, prowadzić wydarzenia Scrum, wspierać Product Ownerów w zarządzaniu backlogiem oraz wspierać adopcję Scrum.

Na tym kursie dowiesz się, jak zmaksymalizować wartość produktów dostarczanych przez zespoły Scrum. Zdobądź głęboką wiedzę na temat struktury Scrum i roli Właściciela Produktu Scrum. Opanuj zasady Scrum oraz sposób tworzenia i ustalania priorytetów rejestru produktu opartego na wartości, dzieląc epiki i tematy na wykonalne historie użytkowników.

Pierwszy dzień zarówno kursu Scrum Master, jak i Product Owner jest identyczny – skontaktuj się ze swoim dostawcą szkoleń APMG w sprawie prowadzenia tego dnia jako samodzielnego kursu idealnego dla członków zespołu i interesariuszy. Obejmuje wszystko, co znajduje się w Przewodniku Scrum – a oni muszą to wszystko wiedzieć.   

AgilePM for Scrum łączy Scrum z wiodącym na świecie zwinnym podejściem do zarządzania projektami (AgilePM), aby oferować pojedyncze ramy do dostarczania kompletnych rozwiązań biznesowych, gdzie wymagane jest iteracyjne i przyrostowe wytwarzanie. Ta certyfikacja wyposaża Cię w umiejętności integracji Scrum z Agile Project Management. Kursy poruszają zasady i teorię leżącą u podstaw frameworka Scrum – prowadzone przez dostawców akredytowanych przez APMG i Agile Business Consortium.

Obraz „Scrum Framework" został stworzony przez Agile Business Consortium. Copyright © 2024, Agile Business Consortium. Wszelkie prawa zastrzeżone.