Co to jest Scrum?

Scrum to framework do tworzenia, dostarczania i utrzymywania złożonych produktów poprzez skuteczną współpracę zespołową. Zapewnia lekki proces skupienia i koordynacji współpracy opartej na zespole, podczas gdy Zespół Scrum rozwiązuje skomplikowane problemy adaptacyjne i dostarcza produkt o optymalnej wartości przyrostowo i zgodnie z przewidywalnym harmonogramem.

Pierwotnie pomyślany 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 Jeff Sutherland i Ken Schwaber w latach 90. XX wieku. Stał się coraz bardziej popularnym sposobem pracy, rozszerzając się poza rozwój oprogramowania na wiele obszarów rozwoju produktów, które mogą zastosować i skorzystać z podejścia iteracyjnego i przyrostowego. Odnosi sukces lub ponosi porażkę w zależności od kompetencji technicznych i wysiłków współpracy 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. Reguły opisane w The Scrum Guide łączą role, wydarzenia i artefakty, kierując ich relacjami i interakcjami.

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

1. Sprint to przedział czasowy, który może trwać dowolnie długo, ale zazwyczaj od 2 do 4 tygodni, w trakcie którego tworzone są jeden lub więcej „Ukończonych" (tj. użytecznych i przynajmniej potencjalnie gotowych 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ą z Właścicielem Produktu realistyczny Cel Sprintu, wybierają odpowiednie elementy z Backlogu Produktu, które przyczynią się do osiągnięcia tego celu i planują pracę niezbędną do jego realizacji.
3. Daily Scrum to 15-minutowe spotkanie prowadzone przez Deweloperów w Zespole Scrum. Odbywa się codziennie podczas Sprintu, a Deweloperzy wykorzystują je do ponownego 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 mogli formalnie sprawdzić i zasugerować adaptacje Backlogu Produktu w celu kierowania dalszym rozwojem.
5. Retrospektywa Sprintu to okazja dla Zespołu Scrum do refleksji nad skutecznością swojego sposobu pracy i stworzenia planu ulepszeń, które będą wdrożone w następnym lub kolejnych Sprintach.

Trzy artefakty Scrum są 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.

Rejestr Produktu to uporządkowana lista wszystkiego, co należy zrobić, aby osiągnąć jego 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 cel, zobowiązanie, które Rejestr Produktu ma osiągnąć.

Rejestr Sprintu obejmuje zestaw elementów Rejestru Produktu wybranych na Sprint oraz całą pracę potrzebną do osiągnięcia Celu Sprintu. Chociaż podczas Sprintu może zostać dostarczony jeden lub więcej Przyrostów Produktu, istnieje tylko jeden Cel Sprintu. Cel Sprintu to zobowiązanie dla Rejestru Sprintu i jest tym, do czego dążą Deweloperzy.

Przyrost Produktu to to, co tworzą deweloperzy, co zaspokaja potrzebę opisaną przez jeden lub więcej elementów rejestru produktu. Jest to namacalny krok w kierunku osiągnięcia Celu Sprintu. Gdy więcej niż jeden zostaje dostarczony w Sprincie, każdy Przyrost Produktu zawiera poprzedni. Zobowiązaniem jest osiągnięcie „Definicji Ukończenia" dla Przyrostu Produktu. Ta „Definicja Ukończenia" to formalne opisanie niezbędnych standardów jakości, które produkt musi spełnić.

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

Zespół Scrum składa się z jednego Product Ownera, jednego Scrum Mastera i zazwyczaj od 5 do 9 Deweloperów. Zespół musi być wielofunkcyjny – zbiorowo posiadający wszystkie kompetencje potrzebne do dostarczenia pożądanego produktu oraz zdolność do współpracy w celu osiągnięcia tego celu. Zespół jest samoorganizujący się – nie uznaje struktury hierarchicznej i pozwala przywództwu w konkretnej pracy wyłaniać się stosownie do potrzeb.

Product Owner

Product Owner jest odpowiedzialny za maksymalizację wartości produktu wynikającej z pracy Zespołu Scrum. Product Owner to 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 efektywne zarządzanie Product Backlogiem, co obejmuje:

• Opracowywanie i jasne 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 zrozumiany.

Każdy interesariusz chcący zmienić Product Backlog może to zrobić tylko za pośrednictwem Product Ownera.

Deweloper

Rola Dewelopera w Zespole Scrum dotyczy każdego, kto aktywnie współpracuje z innymi w zespole przy rozwijaniu Produktu – nawet ktoś, kto pełni jedną z innych ról, może być Deweloperem. Umiejętności potrzebne Deweloperowi będą się różnić w zależności od rodzaju wykonywanej pracy i tego, co jest produkowane. Deweloperzy pracujący w Zespole Scrum nad zagospodarowaniem ogrodu będą potrzebować zupełnie innych umiejętności niż ci przygotowujący wystawną kolację czy ci budujący nową grę na smartfona. Scrum można zastosować we wszystkich tych środowiskach rozwoju.

W Scrum Deweloperzy są zawsze odpowiedzialni za:

• Tworzenie planu dla Sprintu, Sprint Backlogu;
• Zapewnianie 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 wszystkim zrozumieć teorię i praktykę Scrum, zarówno w Zespole Scrum, jak i w organizacji.

Często nazywany służebnym przywódcą, Scrum Master nie posiada władzy rozkazodawczej – nie mówi ludziom, co mają robić i jak się zachowywać, pomaga im zrozumieć, jak Scrum powinien działać i robi, co może, aby ułatwić jego przyjęcie. Świadczy usługi dla:

• Zespołu Scrum – coachingu ich w przyjęciu Scrum, pomagając im znaleźć sposoby ciągłego doskonalenia sposobu dostarczania wartości i powodując usunięcie wszystkiego, co stoi na przeszkodzie.
• Product Ownera – pomagając mu w zarządzaniu Product Backlogiem i pomagając mu zapewnić, że Cele Produktu i elementy Product Backlogu są właściwie ukształtowane, wyrażone i zrozumiane.
• Szerszej organizacji, w której istnieje Zespół Scrum – pomagając jej zrozumieć sposób pracy Scrum i jak musi pracować i zachowywać się, aby umożliwić Zespołom Scrum osiągnięcie optymalnej skuteczności.

Framework Scrum opiera się na teorii empirycznego sterowania procesem, czyli empiryzmie, który zakłada, że wiedza pochodzi z doświadczenia, a podejmowanie decyzji opiera się na tym, co można zaobserwować. Filarami empirycznego sterowania procesem są 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 poprawianie skuteczności i wydajności zespołu).

Ważne jest, aby zrozumieć, 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 do 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. Tymi wartościami 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 iteracyjny rozwój i przyrostowe dostarczanie. 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 wypowiadać się w sprawach, które mogą wpływać na sukces zespołu.
• Otwartość: Członkowie zespołu Scrum dzielą się informacjami, postępami i obawami między sobą, tym samym wspierają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 profesjonalistów, uznając wzajemnie swoje umiejętności, perspektywy i wkład podczas realizacji 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ć każdy zwinny sposób pracy skutecznym.

Wartości Scrum łącznie przyczyniają się do zdolności zespołu Scrum do:

• Adaptacji do zmian: Scrum wykazuje wysoką responsywność na zmieniające się wymagania. Akomoduje ewoluujące potrzeby klientów poprzez umożliwienie dostosowań 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 sposobu pracy Scrum zachęcają do współpracy. Życie wartościami Scrum ożywia współpracę.  
• Ciągłego doskonalenia: Scrum obejmuje regularne retrospektywy – których celem jest zapewnienie regularnych możliwości dla zespołu Scrum do sprawdzania efektywności sposobu ich pracy i identyfikowania obszarów do poprawy. To jest ciągłe doskonalenie w działaniu.
• Przyjęcia podejścia zorientowanego na klienta: Scrum kładzie silny nacisk na dostarczanie wartości klientowi. Product Owner, reprezentujący interesy klientów, priorytetyzuje funkcjonalności, zapewniając, że produkt jest zgodny z potrzebami i oczekiwaniami klientów przez cały okres jego rozwoju.

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

• Elastyczność
• Szybszy czas wprowadzenia na rynek
• Ulepszona współpraca
• Lepsza jakość produktu
• Zwiększona satysfakcja klienta
• Wyższa produktywność
• Lepsze zarządzanie ryzykiem
• Przejrzystość
• Zespoły z większymi uprawnieniami
• Ciągłe doskonalenie.

Dowiedz się więcej o 10 kluczowych zaletach stosowania Scrum, szczegółowo opisanych w tym blogu.

Scrum może przedstawiać kilka wyzwań i wad. Podczas wdrażania 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 potrzebnej do skutecznego działania Scrum. Role takie jak Scrum Master mają również specyficzne 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 wciąż istnieją wyzwania do pokonania, typowe zagrożenia lub wady obejmują:-

1. Nieadekwatne wsparcie kierownictwa: Jak w przypadku każdej inicjatywy zmian bez silnego wsparcia kierownictwa w organizacji, przyjęcie Scrum napotka opór lub będzie stawiać czoła wyzwaniom w przezwyciężaniu barier organizacyjnych. Brak zrozumienia potrzebnej zmiany kulturowej i słabe zaangażowanie na wyższych poziomach 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 adaptują się do nowych ról, wydarzeń i procesów współpracy wprowadzonych przez Scrum. Porzekadło, że sprawy mogą się pogorszyć zanim się poprawią, często okazuje się prawdziwe. Kluczem jest pozostawienie 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ązywanie się:  Zespoły mogą napotkać ryzyko przesadnego zobowiązywania się do pracy podczas planowania sprintu, co prowadzi do wypalenia lub kompromisów w jakości rezultatów. Zrównoważenie pragnienia szybkiego postępu z realistycznym wyznaczaniem celów jest kluczowe dla utrzymania zrównoważonych praktyk rozwoju. Ważne jest ustalenie zrównoważonego tempa – należy spodziewać się niepowodzeń w osiąganiu celów sprintu, podczas gdy zespół wypracowuje to, co można osiągnąć.
4. Nadmierne skupienie na celach krótkoterminowych: Skupienie na krótkich sprintach o stałej długości w Scrum może czasami prowadzić do krótkodystansowego spojrzenia, gdzie zespoły priorytetowo traktują cele bezpośrednie kosztem długoterminowych celów strategicznych. W czystym środowisku produktowym dobry Product Owner powinien być w stanie komunikować i utrzymywać odpowiednie długoterminowe skupienie. Gdy komplikują to złożoność, może być potrzebne coś więcej…
5. Problemy z integracją pracy wielu zespołów dla 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 zdolności "10 lub mniej" osób w zespole do jej osiągnięcia. W tej sytuacji zaleca się szerszy framework do radzenia sobie ze skalą i/lub złożonością.

Dla ekstremalnej skali w kontekście produktowym – gdzie potrzebne są setki programistów – wskazany może być skalowany framework taki jak SAFe. Dla problemów mniejszej skali – do 100 programistów na przykład – i/lub gdzie złożoność ogólnego rozwiązania biznesowego obejmuje wiele produktów, usług i innych działań, wtedy zwinny framework projektowy taki jak AgilePM zaspokoi potrzeby.  

Opierając się na kwestii skalowania wspomnianej powyżej, w tym odcinku serii APMG 'Level Up', eksperci zarządzania projektami agile odpowiadają na pytania dotyczące zarządzania projektami agile i scrum. Jednym z kluczowych poruszonych pytań jest różnica między tymi podejściami.  Omawiane są zagadnienia 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 ze 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 scrumowych lub kombinacji zespołów scrumowych i nie-scrumowych. Z technikami do radzenia sobie z planowaniem i koordynacją między zespołami agile, przywództwem z perspektyw wizji biznesowej, architektury rozwiązania i zarządzania projektami, nadzorem, ryzykiem i więcej - to zdecydowanie warto rozważyć w przypadku bardziej złożonych sytuacji projektowych.

W tym filmie Richard Pharro, CEO APMG International, i ja omawiamy 'AgilePM for Scrum.' Ten nowy framework łączy mocne strony dwóch wiodących frameworków Agile. Richard zadaje kluczowe pytania, mając na celu dostarczenie wglądów w framework, włączając jego zakres, uzasadnienie jego rozwoju oraz to, kto najbardziej skorzysta z tego frameworka. Dodatkowo badamy akredytowany program szkoleniowy i certyfikacyjny wspierający ten framework.

Scrum wytyczył znaczący szlak dla zwinności w rozwoju produktów programistycznych i jest bardzo popularnym i wszechstronnym podejściem nie bez powodu, będąc idealnym rozwiązaniem do dostarczania produktów, które zachwycają klientów w obliczu złożonych i rozwijających się wymagań. Wykorzystuje zalety zespołów międzyfunkcyjnych i współpracujących, aby dostarczać wartość szybciej i efektywniej niż ich mniej zwinne odpowiedniki.

Nie jest jednak pozbawiony wyzwań... Ken Schwaber i Jeff Sutherland stwierdzają w swoim Przewodniku Scrum 2020, że "Framework Scrum, jak przedstawiono tutaj, jest niezmienny. Chociaż możliwe jest wdrożenie tylko części Scrum, wynik 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 wielu różnych branżach, ale tylko wtedy, gdy używa się go w całości. Jeśli pominiesz jakikolwiek element Scrum, po prostu nie będzie działać prawidłowo. Scrum działa, ScrumBut grozi porażką. ScrumBut opisuje sytuację, w której "używamy Scrum, ale nie robimy tego".  Zamiast "nie robimy tego" można wstawić cokolwiek... "Nie robimy codziennego Scrum", "nie współpracujemy", "nie mamy Scrum Mastera, mamy menedżera", "nie mamy product backlog, mamy specyfikację", "nie definiujemy Sprint Goal" itp. Schwaber i Sutherland opracowali Scrum, nadzorowali jego stopniową i ostrożną ewolucję od połowy lat 90. – przyjmij ich mądrość i rób to właściwie.  

Jeśli zajmujesz się rozwojem produktów, to łatwo zauważyć, jak wprowadzenie zwinności do tej dziedziny poprzez stosowanie i ciągłe doskonalenie zastosowania Scrum może przynieść ogromne korzyści. Ale jeśli twoje zainteresowania wykraczają poza czysty rozwój produktów, to Scrum sam w sobie 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 certyfikacje dla kluczowych ról.

Ten kurs nauczy Cię jak wyróżniać się jako Scrum Master, usprawniając rozwój produktów i rozwiązań przy użyciu Scrum. Kluczowe zagadnienia obejmują wszechstronne zrozumienie Frameworka Scrum, zasad Scrum oraz roli Scrum Mastera. Nauczysz się również, jak budować skuteczne zespoły deweloperskie, pełnić rolę przywódcy-sługi, prowadzić wydarzenia Scrum, wspierać Product Ownerów w zarządzaniu backlogiem oraz napędzać wdrażanie Scrum.

Na tym kursie dowiesz się, jak zmaksymalizować wartość produktów dostarczanych przez zespoły Scrum. Zdobądź głębokie zrozumienie frameworka Scrum i roli Product Ownera w Scrum. Opanuj zasady Scrum oraz sposób budowania i priorytetyzacji backlogu produktu zorientowanego na wartość, rozkładając epiki i tematy na wykonalne historie użytkownika.

Pierwszy dzień zarówno kursu Scrum Master, jak i Product Owner jest identyczny – porozmawiaj ze swoim dostawcą szkoleń APMG na temat przeprowadzenia tego dnia jako samodzielnego kursu idealnego dla członków zespołu i interesariuszy. Obejmuje wszystko z Przewodnika Scrum – i muszą to wszystko wiedzieć.   

AgilePM for Scrum łączy Scrum z wiodącym na świecie podejściem do zwinnego zarządzania projektami (AgilePM), oferując jednolite ramy do dostarczania kompletnych rozwiązań biznesowych, gdzie wymagany jest rozwój iteracyjny i przyrostowy. Ta certyfikacja wyposaża Cię w umiejętności integracji Scrum z Agile Project Management. Kursy obejmują zasady i teorię leżące u podstaw frameworka Scrum – prowadzone przez akredytowanych dostawców APMG i Agile Business Consortium.

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